From software developer to a software architect
I stumbled upon a Reddit post in /r/softwarearchitecture asking for insight on moving from being a software engineer to a software architect. “What would you consider to be the essential things to become a software architect?”. My intention was to answer with short bulleted list, but then it escalated. This post is based on my answer on Reddit.
tldr; being able and know how to work on the big picture, and doing so by collaborating with other people (business and tech). Ideally based on experience.
I’ve worked as a hands-on software architect for a few years. Used to work as a full stack developer who was often involved in architectural stuff. Total experience around 10 years.
Another side question was about building a good app which is scalable and efficient. But in the end that is just the culmination of you knowing your stuff. Also it is dependent on so many things that it’s not answerable as is. So here’s a more general level answer of becoming a software architect. Few things I think are essential and appreciated traits in a software architect. Not so surprisingly, this is based on my experience.
- Experience. This is of course individual as people are different. But I’d say it would be good to have 5-8 years of experience working with variety of projects. You should know how tech things work in real life and also in general know how businesses work. After all you’ll usually be the piece between tech and business.
- Versatility. You should be able to work on all aspects of the system and its dependencies. Note, this does not mean you should already know everything about everything. Just being able to handle the big picture and work with it. This includes different techs and architectural patterns.
- Collaboration. You should be good at working with others. Business and tech. Otherwise it’s likely your plans and designs fall short.
- Passion to learn new things. Not to say you should jump into new flashy stuff all the time, but you should be aware what could be possible. This way you can be better at choosing the right tools for your scenario. This is not just for architects, but often they are the ones who have to make final decision and the base & plan.
Those are the first things I thought of. In my opinion the most essential is experience. Other things often grow on you while gaining that experience. If you want to specifically try to learn something, you probably should study architectural designs and patterns. It’s also a good thing if you know your coding stuff and can justify things you do on that level too. One thing which has helped me a lot is to always ask why I’m doing something.
Here’s a few books to read if you’re into that kind of stuff:
- A Philosophy of Software Design by John Ousterhout
- Clean Architecture: A Craftsman’s Guide to Software Structure and Design by Robert C. Martin
- Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin
- Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans
You should also note that some of the books are a little bit older and might include practices which are considered deprecated at present. Though, in my opinion, you should always process and think about the statements and content, whatever the book or data source is. No matter is it old or fresh.
What are your thoughts on this matter?
Let me know what you think of this article on twitter @niklas1e or leave a comment below!