to remove two-column,resize your browser window to narrow

[09]implementation skill ] a leadDeveloper/softwareArch

Update — compared to 2009, I am now much less confident because I see many mismatches in my profile vs arch job requirement, such as

presentation and persuasion – eg Mac

code reading in a large codebase

debugging opaque systems

Hi XR,
(another blog)

I might do well in interviews, but still need know-how to be a senior architect. (Senior developer fine. Junior architect fine. Team lead perhaps ok.) As i confessed to you in our recent call, there are too many (dozens of times a week) practical problem-solving situations [2] i will encounter, research and try various wrong solutions, overcome, and then internalize.

I feel this vast amount of know-how is a must-have for a software architect in large project, but probably not needed by an EnterpriseSystemArchitect — see other posts.

[2] See post on [[## result-oriented lead developer skills]] for some of the problem-solving situations.

I guess your spring/hibernate performance problem was one of those encounters. We need to encounter problems to learn. Whenever i go through a project without implementation[1] difficulties, i feel like time wasted. Therefore, it’s not how many years that count. For example, I improved my SQL skill only in GS, not the other 2-3 years of SQL experience before.

[1] I don’t want to say “design” difficulties. If I face a difficult design issue, i don’t always learn. Most of my tech learning takes place after overcoming implementation challenges.

All the architects I know keep their skills up to date by doing hands-on coding.

* my GS team lead
* my GS mentor, a 40-something senior manager in charge of a 10-people team
* Lab49 team lead and the java developer
* Guo Qiao
* Xiao An

These individuals do hands-on work on a weekly basis — sometimes daily, but seldom go without coding for 3 months. That means

– their code is in CVS and they can’t afford to produce poor code
– they set coding standard for others, by example
– they force themselves to stay productive and churn out code fast. A hands-off architect tends to be a slow coder, i would imagine
– As Guo Qiao said, if you don’t code, gradually you lose your voice in tech discussions. I feel that’s true in high-level discussions just as in implementation discussions.
– i feel a hands-on architect can estimate man-day effort better than a PM.