How to become a software architect
Yesterday, on the vJUG mailing list, Gilberto Santos asked the following question:
I’m working as Software Engineer and as intend to grow up to architect position, now on I was wondering how to best way to get there , should be :
I replied to him over the email, but it might be something more developers are struggling with, time for a blog post!
Architects should code
There are two types of software architect:
- The one that draws Visio® diagrams
- The one that develops/codes
The first type of architect likes to talk, have meetings, draw diagrams and give orders. This, to me, is not good.
Architects should write code, they should be part of a team. In fact, everybody that writes code is effectively an architect and should have basic knowledge about architecture principles. For example every programmer should know about the SOLID principles.
Simon Brown has some good presentations on this topic on his website coding the architecture.
The best advice I can give a developer that wants to grow into a senior/architect position is:
Make mistakes, lots of them.
If you want to become a better architect the most important skill to master is the art of making mistakes, noticing them, and not repeating them in the future. Most ‘enterprise’ architects I’ve worked with set up a project and leave before the thing they had designed starts to rot, smell and fall apart. They never experience the flipside of what they set up, you can make everything look good on paper.
As a programmer and architect you need to experience this ‘project rot’. To learn you need to feel the mistakes that are in every system. Once you start seeing problems, admit the things you’ve made aren’t perfect, and start changing them. Try to fix the mistakes.
Matt Damon would say: “I’m going to have to refactor the shit out of this.”
This experience is what makes you a real architect. The best architects I’ve worked with knew instantly what needed to change and which solutions would work better than others. They develop an instinct for this. In Dutch we have a saying ‘they know where the shoe pinches’. Which means: just by looking at it they have a ‘feel’ for what hurts and will cause problems (in the future).
This experience/instinct is what makes you a good architect and a good programmer. But sadly this doesn’t directly get you a better job or position within a company. Managers, recruiters and HR can’t easily test for this instinct. Sadly: the thing they look at most of the time is certifications.
For example, I’ve mentioned the SOLID principles, and they are very important. It takes a maximum of 5 minutes to learn the acronym and use it in job interviews or get a certification. To really understand it though you need to experience SOLID. You need to encounter situations where huge classes have a lot of responsibilities. This is the problem with most certifications: they encourage you to memorize rules and principles, not to understand them. I’d rather have someone in my team that naturely breaks up code into clean interfaces than someone who memorized that the ‘I’ in SOLID stands for the ‘Interface segregation principle’.
Once you developed this ‘architect instinct’, people will notice it. Colleagues will remember and this will help you get better jobs and positions in the future. You’ll need to prove yourself and grow your network. Try to get recommendations from people you’ve worked with and you will become a real senior programmer and architect.