Write code or step aside

Most IT careers start with a programming job: you write code in one of the popular programming languages as part of a team. As your experience grows you start to get bored with software: you’ve been working with more or less the same technology and tool set for a couple of years and you need something new to keep yourself going. That’s the point where you have several options like becoming a project manager, coach, analyst or middleware expert. This story is about another option: becoming an architect.

At first, being an architect is relatively easy. Using the skills you gained while becoming a successful developer you can easily help others in a team of developers to be successful as well. You know what works and what doesn’t because you’ve solved similar problems on a similar platform. Because you’re more experienced you can be the natural leader of the team, the interface to the business owner and other stakeholders. Managing the teams’ environment becomes your job because you can explain complex technology and team dynamics to non-technical people. You coast along and leave the drudgery of coding to other people.
Excellent.
Time goes by and you get involved in projects you didn’t write any code for. You look at the technology stack used and you realize they’re using this new fangled TechnologyX. You read the tutorial on the Internet and you think ‘OK, I understand, TechnologyX solves ProblemY, great’. Next time a customer asks you for a solution to ProblemY you tell them the story of this other project where they used TechnologyX. You’re no expert yourself, but you’ve got a colleague who knows all about it. Next problem, please!
In the mean time, in a parallel universe you know nothing about, people start using other technology that also solves ProblemY in radically different ways but since you didn’t stumble on these things you just don’t know. You’ve lost the ability to learn something radically new. You are stuck. Your waistline grows and you have become waste.
I strongly believe there is only one way to grow your professional skills and to keep increasing your value for your customers. You have to continue learning new technology. Not just by reading about it but by experiencing new technology and new techniques first hand.
The process goes like this:

1. Watch the presentation on InfoQ so you can sift out the obviously useless stuff.
2. Read more on technology that passes the filter above so you know to what kind of problems it might be applied.
3. Download the code for technology that might be useful for the problem you are working on or expect to be working on in the near future.
4. Use the new stuff to solve a problem you’ve solved before so you can focus on the technology instead of the business problem at hand (if you feel really un-inspired you can just build yet another PetStore).
5. Apply the new technology to a real life problem in a real project with real developers and a real deadline.
6. Repeat from step 1.

The crucial step in the list above is step 5: without real-life experience and especially without a deadline you will never find out if it works. In particular, you will never find out where technology hurts and where it facilitates. Architecture happens in development teams.
This only leaves one final step: share your knowledge with your peers in other projects so your organization learns. And never ever forget step 5.