Coder or Architect?

camusflage queries: "I recently was transitioned into an architectural role by my employer. I had been splitting time with development and architecture, in that order. It appears my new duties put me as an architect first, and a coder second, with the coding being at my request. At not even 28 years old, I'm already a lead developer and have people with twenty years more experience looking to me for coding hints and tips. Over that past year with my employer, I've expended much effort on developing credible relationships with other groups in the organization, sure to carry me far as an architect. Since I've already resolved that management is not a track I want to get into, is architecture my most logical next step? What do I need to do to make sure my skills still remain sharp, as I'll be spending less time in the bits and bytes? Any tips from those who have made the transition from development to architecture (both successfully and unsuccessfully) are appreciated."

Comments

Can I come work for you?

[flockofseagulls]

I'm a 40-something programmer with over 20 years experience. My last job was a dot-com with free soda and stuff, and the one before that had a foosball table. I don't know why but one place is out of business and the other one has laid off from 100 down to 20 or so, and is probably not going to make it because of the September 11th thing.

What I really miss about those places is working with talented young architects. I used to get lots of cool Javascript tips and hints from the 22-year old CTO but now I have to read O'Reilly books (blah). My experience is mainly with lame old-fashioned stuff no one uses anymore, like SQL and C, so I need to work with Extreme XP younger architects so I can understand Java and patterns and other new stuff I didn't learn in my PL/I class back in the 1970s.

Someday I want to be an architect, but mainly I get stuck doing lame requirements and specification work, and writing code. I'm pretty good at finishing programs the younger programmers start on when they get pulled off to something even more rad, or when they get stuck with some stupid detail from the old days when old people like me designed everything wrong.

Now I work at a boring monolith place where all they think about is profit. I don't know how, because almost everyone is old like me, and they are using old-fashioned stuff. We are looking at Linux and PHP and MySQL for a new web site but without an architect to tell us what to do we have to do all this testing and stuff--I keep saying I KNOW it works because I read it on slashdot, but there are programmers and managers even older than me that want to see prototypes before they commit their business to new tools. No wonder they couldn't cut it at a bitchin' dot-com!

Anyway if you decide to be an architect please email me so I can apply for a job and learn some of those hints and tips--I really want to learn Java but I keep getting confused by the CLASSPATH concept.

Good luck dude!

Old guy

P.S. A few years ago I worked with some younger guys who knew lots of C++ tricks, and they had "Wizard" and "Scientist" in their title. Is that like an architect? And after the Rogaine starts to work what kind of haircut should I have (or should I just leave it bald)? What about a goatee or some kind of unusual beard? Will that help?

Re:a question for the young genius.

[camusflage]

Dude, do you what a vagina is?

I believe it's a custom part of the female model of homo sapiens. It serves two purposes, one being an input port, the other being an output port. It functions primarily as part of the reproductive process of the species. It was designed for maximum flexibility, yielding to objects both small (like your penis), and large, such as a baby. Typically, the output method of the vagina forces it to operate much closer to maximum spec than does the input method. Like all body parts, it requires regular care and maintenence. Although it is capable of sequential serial input from multiple devices, the controlling system generally prefers utilizing fewer input devices over a longer term. The input/output ratio is heavily weighted towards the input process, as the output process uses many more system resources, both short and long term.