Becoming a software architect

So, yea, I’m a “software architect” — a principal engineer. I like my job. It’s challenging, it’s fun, and it scratches an itch. I’m also a little sad, because it is really hard for me to code as much as I would like to. I have to always fight to find time to just get in the code and build stuff.

I didn’t really plan to have this job. I just started working and over time discovered this role and discovered I liked it. So when younger engineers who are interested in advancing their career ask me what I did to get here I find myself a bit mystified. How did I get here?

Different strokes for different folks

Before I tell that story, I do want to emphasize that everybody’s path is different. What worked for me may not work for you. In fact what works for you could be quite different.

I have worked with a lot of principal engineers, and each of them brings a very different style and skills to bear. Some are really good at communicating, driving direction, coming up with high-level designs and strategies. Others have deep deep understanding in a very specialized field and are able to achieve miracles in that specific area. And some are great leaders and mentors. So, just because I followed a certain path to this role, doesn’t mean you need to follow the same path. I would say in general, find your passion and lean into that.

Another important aspect of that is, I’m privileged — I’m a white male who grew up middle class in the USA with educated parents. So I had advantages growing up, and I’ve had tailwinds in my career. When I am loud and speak up people don’t think I’m being “uppity” or “intrusive” or “annoying.” People generally give me the benefit of the doubt. I haven’t had to deal with institutional discrimination. If you’re in a minority position, I suspect it’s a totally different story and you probably need a very different strategy.

With all that said, here are some things I’m noticing I have done and continue to do, and perhaps that is part of what helped me land this role.

Looking for underlying themes and patterns

When I see myself or a team struggling with poor quality code or difficult processes, or things are just taking a lot longer to do than they should, I find myself asking why is that? How can we make this better? I am passionate about trying to understand the root cause. I have no patience for accepting it as just the way things are.

I have never really formally practiced the Five Whys technique, but that’s essentially what I do.

In the excellent book Thinking in Systems, Donella Meadows encourages us to move away from just noticing the series of events occurring to us to dig deeper and understand the underlying structure that is causing these events to happen. You have leverage when you understand the structure, rather than just reacting to the events. This blog post is a good summary of how to see structure in a series of events.

Reading

My reference to Ms. Meadows’ book takes me to my next point. We don’t live in isolation. There is so much wisdom out there if we can tap into it.

I have memories of particular books or articles that completely opened my eyes to a new way of thinking. I still remember reading Werner Vogels’ article on eventual consistency and how it unlocked how we can manage data at web scale. Or the realization that there is a clean, scalable, decoupled way to integrate data between system components when I read Jay Kreps’ seminal article on log-based architectures. Or when someone handed me Eric Evans’ book on Domain Driven Design and it crystalized a user-driving approach to domain modeling.

In my search for understanding the structure and patterns underneath behavior, the books and articles I have read have been key milestones on my journey. What I have learned and practiced from them have become crucial tools in my toolbox.

The school of hard knocks isn’t really a school unless you learn and change, and reading has made that possible for me.

So, how do you find these books and articles? What works for me is to listen to those who I respect, and trace links from them to source material. I primarily do this through curating a Twitter feed of people in the industry who I respect and trust. There is still a lot of noise, and Twitter has started “curating” my feed for me in annoying ways, but generally this works best for me. I check Twitter a few times a day and amidst all the rants and food pictures I get gems of great new information that keeps my knowledge moving forward.

Writing

Before I became a software engineer, I wanted to be a science writer. I have always loved writing. When I was growing up we travelled a lot and my parents and then my siblings and I would type up long letters to each other.

This love for writing has served me well in my software career, and I think has helped me be recognized and respected by both management and my coworkers. Many software developers are not writers — they like to make things work, not write about them. But at a certain level in your career, if you can’t write down and explain your thoughts and use that to communicate with others, it’s going to make it hard for you to advance.

Writing is not natural for everyone, and it has always come easy to me. So perhaps I’m not the best one to give advice. But having mentored others on this, I think the best thing to do is just do it. Find a way to set aside time to do some technical writing on a regular basis. Also, by the way, reading improves your writing, so see above.

Oh, and, when you write, use diagrams and images. People are so much better at ingesting and comprehending concepts visually that through straight writing. Lucidchart is your friend.

Teaching

Whenever I really want to learn something, I announce that I am going to give a talk on it. It works every time. Also, giving presentations on interesting subjects help make you and your thoughts visible to others, which is always useful.

As with writing, you get better by doing. It takes guts the first few times you do it, but as you do it more and more, it becomes comfortable and even fun.

Do the dirty work

All this thinking and reading and communicating is great, but you also have to back it up with action. Ultimately that’s what gives grounding and reality to all your ideas, and you earn respect, which is a key aspect of being a leader.

Take on a project or refactoring that nobody else wants to do. Take on the effort to organize a new practice with the team. Upgrade that library that nobody else wants to upgrade. Build that automation script to eliminate manual work in the team. Taking initiative and doing the dirty work shows commitment and gets noticed.

Good luck!

I think any kind of success is a combination of luck, hard work, setbacks and sudden advances. I know at some point I realized I liked the role of an architect, but I didn’t come in with a big plan. It evolved like anything else.

We all have our own journeys. May yours be full of transformation, learning, and fulfillment!