Those Who Can, Write Code; Those Who Can't, Architect
I love to write code! It's true! Yes, the title on my business card has been "Software Architect", or something similar, for many years now, but I really do love to write code! In fact, I love it so much that I spend at least 20% of my time actively implementing production code, I also write code for personal projects at night and on weekends. If I'm bored and looking for something fun to do, I often write code.
Ok, it's obvious that I'm really a coder at heart, so what I am doing in this Architect role? Some days I ask myself that very question. The honest answer is, I love solving technical problems. Not just any problems, but seemingly impossible to solve technical problems that people have worked on for weeks, months, or even years without a successful solution. Give me a problem like that and I am thrilled to death! The fact is, there are more seemingly impossible to solve problems presented to an Architect, so I'm an Architect. I don't really care what my title is, just as long you present me with the most difficult technical problems to solve.
On a related note, if you're an Architect and you don't spend at least 10% of your time writing code of some sort, start writing code today. Don't wait another day. If you can't successfully implement your own designs, you need to take a break and rebuild those coding skills. I think you will be happier if you can code your way out of problem equally as well as you can talk your way through a design.
I met "Ron" (not his real name) in 1999. Ron was a brilliant guy and the Architect for a rather complex VB application. Ron had a really cool design that worked pretty well, but he also had a rather junior 6 person development team doing the implementation. After the production release, the application would occasionally lose all of it's data. All of it, completely gone without a trace. Ron and the team struggled to find a solution, but after months of debugging and attempted fixes, and several production releases, the defect was still hanging around.
I was asked to lead a team (of two) that took over all of the development from Ron, et al. We spent two weeks with Ron doing a code review and talking about the design/ architecture. My coworker and I immediately identified the problem. Ron could not implement his own design in VB.
Ron's inability to successfully implement his design using VB meant that he could not provide his team the technical leadership that was critically important to the successful implementation of his design. In the end, the issue was fundamental flaw in the error handing approach, but Ron could not see the flaw because he did not have the technical chops in VB. The flaw in the error handling would be a flaw in any programming language (they were trying to terminate the application at the bottom of the call stack without signaling failure to the caller), and if Ron had spent any significant amount of time implementing some portion of the application, I am confidant he would have easily discovered and corrected the defect.
Ron helped me understand how important it is to keep up with your technical skill and have the ability to successfully implement your own designs. Unfortunately, I am reminded of this lesson from time-to-time.