On Software Engineering

A Few Words of Wisdom

I was browsing reddit today I stumbled across a post titled “I want to be a Software Architect”, where the author described his goal of improving his technical expertise and laid out a number of different topics, frameworks, and programming languages to study. The end goal behind this improvement, as the title of the post suggests, would be to help one day become a Software Architect or Principal Software Engineer.

I began reading the replies and I found what I believe to be one of the most valuable pieces of advice I have ever read on reddit. I am reposting it here in part to share it with others, but also to ensure that I can refer back to it as time goes on. The following reply to the aforementioned post comes from user /u/justanothersde:

Just a couple notes: In some companies the word “architect” is a dirty word. It implies a hands-off ivory tower fellow who needs other people to get things done. These days having skills to be an individual and independent builder is very important, even if you end up being a principal engineer in a large company where you spend all your time telling everyone else how they should write their code.

Another thing is that getting sharp engineering skills is only half of the equation to moving into a senior role. Only your first or second promotion is really about your mastery of all things tech, beyond that you are promoted more around other competencies like your ability to leverage yourself and get work done through other engineers. You do this by learning to first be right and say important things in public, and then to convince everyone around you that your design is correct. Many engineers never quite realize that they have to speak their ideas out loud, in public, under scrutiny from their peers and their management. Many engineers never learn how to write or articulate themselves in ways that naturally influence people. They use the wrong level of specificity, too many words, focus on the hard things without concisely conveying the big picture. They forget that they are writing for a specific audience and not just clones of themselves. They focus on calling out the hard or stupid aspects of the problem over bring attention to all the things that can be done easily and which have a lot of return of value. Many engineers never bother to understand the business or their customer. I’ve seen so many designs for beautiful or complex systems but as soon as I start asking questions about the flow of money and the business efficiencies realized by this or that tradeoff, some eyes just cloud over. Senior engineers need to be able to manage upwards, and help their management chain just as much as they write new beautiful code for some abstract purpose.

All the subjects in your list are great and should be fun to learn. You will get insight and wisdom learning and using these things. They will also all be irrelevant by the time you become a principal. Interviews for principal engineers usually include coding problems that can be solved in any language, and usually can be quickly knocked out by someone who has only read K&R “The C Programming Language”. The test for coding questions at this level has very little to do with the semantics of the language used or the power of this or that framework, but everything to do with the clarity of thinking and problem solving displayed while going through the motions. Abstract problem solving and the ability to quickly see problems and solutions is almost the only thing that is permanent, while everything else is transient and depends on the time and place and company and whatever other subject environment things that won’t exist in the job tomorrow. PEs are expected to be powerful tomorrow in situations heretofore undefined, and that just means that they are wise, adaptable, dynamic and potent.

As for getting there, don’t overthink it. It’s a long road, but you have nothing but time. Software engineering can be extremely fun, so focus on that and as time flies by you will suddenly realize that you have become a master. It turns out everyone else around you will as well, and they will recognize that with lofty titles that at the end of the day still don’t really quantify all of the problems you can solve and things that you can figure out how to build.