Summary about Architect Visit

Our Architect visited China recently. I had a 1-1 with him and several meetings. 

Gains from Architect:
1. Algorithm: it would be good to keep doing some practice regularly for example Project Euler, but it's fine to not put effort on it on intention. A fact is: It's always important in Interviews BUT not that important for daily work. Don't feel bad about this.
2. Project experience: every project can excersie your basic programming skills while getting into new project would require domain knowledge which looks like a BIG obstacle to overcome. Domain knowledge is much easier than computer science, so take it easy to learn domain knowledge reguarly without pressure.. Feature Dev VS Application Dev.
3. Study plan: it would be good to have one year by year BUT don't need to push yourself too much.
4. Leadership definition: His summary is very practical and really comfort me about what I have done when I was translator tech lead. And the summary is also good reference for writing project experience.
5. Code review is hardest work as it requires fairly strong understanding to the code almost like the author...
6. Tech lead, Architect, Local Tech lead role definition by Jeff: it's in practice summary so very valuable to help me feel comfortable in executing like its role work partition.
    --Tech lead: 50% project coordination + 20% Answer project questions + 30% SW development/design/code+design review.
    --Architect: in early stage of project, major work is SW design; later in executing, just similar like a Tech lead.
7. After early stage initial product design, planning, the key work in whole dev stage is to make sure its execution with a lot of coordination, communication, recursive product design (spec) review/changes..
8. Strict Spec writing is somehow harmful to development efficiency. The more efficient way can be especially for a feature/command: PD gives out draft spec and Dev works on it and supplies more details and keep communicating with PD to reach agreement about modifications to finally lead to a complete project design...
9. Domain kownledge
    -parametric modeling and direct modeling, both are good in diff conditions.
    -domain knowledge is much easier to learn than computer science.
    -solid modeling VS surface modeling
        --solid: needs to be accurate, aim to model real world objects.
        --surface: don't need to be accurate, aim to model look-like real world objects.
   







原文地址:https://www.cnblogs.com/taoxu0903/p/2030391.html