This week my book club is reading a paper entitled "What Makes A Great Software Engineer?" by Paul Li, Amy Ko, and Jiamin Zu. In it they describe their study, which amounts to basically interviewing 59 engineers at Microsoft about the traits they deem necessary to be a "great" software engineer. They attempt bringing some specificity to an otherwise ambiguous question, namely:
- What do expert software engineers think are atttributes of great software engineers?
- Why are these attributes important for the engineering of software?
- How do these attributes relate to each other?
I find the results of their study fascinating and it left me with many great quotes from senior+ engineers. I would have liked (and they mention this near the end) an interdisciplinary approach that reconciled these attributes with the thoughts and opinions of other fields, not just from "big tech" engineers. They mention that this can be an additional area of research, which now I am wondering if that has been done. This paper dates back to 2015 so now almost 10 years (!) have passed. How time flies!
I cannot go over all of the traits they mention but there are a few that I think are worthy of discussing. I also find it interesting that many of these attributes align very closely with certain company values such as the Amazon Leadership Principles.
- Improving - not satisfied with the status quo
- Passionate - intrinsically interested in the area they are working in
- Open-minded - willing to judiciously let new information change how they think
- Data-driven - taking and evaluating measurements of their actions and of the software
- Knowledgeable about people and the organization - informed about the people around them: their responsibilities, their knowledge, and their tendencies
- Sees the forest and the trees - considering situations at multiple levels, including technical details, industry trends, company vision, customer/business needs
- Handles complexity - able to grasp and reason about complex and intertwining ideas
- Creates shared context - molding another person's understanding of the situation while tailoring the message to be relevant and comprehensible to the other person.
- Honest - truthful (i.e. no sugar coating or spinning the situation for their own benefit)
- Elegant - simple and intuitive software/designs that others can understand
- Creative - novel solutions based on understanding of the context, existing solutions, and the limitations of existing solutions
My favorite of these is Honest. I think most people are perceptive enough to realize these kinds of situations - when someone is covering up or placing blame on someone else for something that is their fault. I think the people who do that don't realize how easy it is to see past it to the vast majority of people. In a world of office politics this erodes your credibility and causes your team to lose trust in you. Even more than lying or covering up is the trust that is earned by simply showing up everyday and putting in your best effort. Here is a quote from the paper I resonate with:
Influence comes to someone else trusting you, part of that trust is that they go, ‘You know what? I know that this person always speaks the truth.’ As a result of that, when they say something is good, I will totally believe them because they are not trying to kind of misrepresent something or make them look better or whatever.
-Windows Services Principal Dev Manager
Another attribute of the so-called "great" engineer that I admire is elegance in code. I think this is part of the reason why I like LeetCode problems so much - they are miniature problems within a constrained environment. You cannot just brute force your way around, and I have been in many code bases where that has been the case. Not only does it cause confusion, destroying readability and maintainability, but it is repulsive to look at. We all have tight schedules and that is fine, understandable even. But when you see a really superlative piece of code it can be something to admire, like a sunset on the beach or looking over the grand canyon. It makes me want to refactor things that I know are not elegant or succinct. I think this also comes back to honesty and even Leadership Principles such as "insist on the highest standards". Honesty because it feels a bit like cheating yourself when you don't make a program concise in this way. And again with earning trust (another LP), committing code like this raises the bar (okay now I'm just getting carried away) for the whole team. It gives others the permission almost to bring high standards into their work. This reminds me of the Marianne Williamson quote (I initially heard this in the movie Coach Carter):
...And as we let our own light shine, we unconsciously give other people permission to do the same. As we are liberated from our own fear, our presence automatically liberates others.
So yeah, I really believe in this characteristic. And I believe it touches on many others. In fact I think a lot of these, just like the Amazon LPs, are intrinsically intertwined.
Improving and passionate are also traits that ring true to me as belonging to the "great software engineer". As said in the paper, you can quickly find yourself out of date if you are not constantly learning new things. More than that, there is just so much to learn even if you are only catching up. Of course, there are always going to be certain timeless fundamentals or first principles. The fact remains though that computer science and the software engineering industry has great depth and breadth. There is no royal road to science. Passion undoubtedly brings the energy here to compliment the first trait. There has to be some why greater than money, for example, that fuels the desire to improve. Otherwise it is very difficult. Anyone who has taken a class on a topic that they are not interested in can relate. It becomes drudge work. Perfecting a craft you love, on the other hand, can be magic.
Data driven seems a no-brainer, everyone should work off of real numbers and facts as opposed to gut feeling. It is sometimes hard to separate what you feel and what the numbers are telling you, but perhaps that is another post for another time.
Knowledgeable about people and the organization - to me this is an underrated trait that many people overlook. It helps to know the strengths and weaknesses of the people around you - the people you work with. If you are leading a project you are better able to delegate tasks, and if you are not you are better able to divvy up tasks on a team. In any context as a programmer you are able to clearly see who you can go to for help. This is a critical trait as well considering that another on the list is self-reliance. It is just as important to not always be bugging your manager for help as it is to remove roadblocks by leveraging the experts you already know. Asking for help is smart - banging your head against the wall is not so smart.
Anyway, I enjoyed this paper and I do aspire to realize these attributes in my own work. That, maybe, is a constant endeavor.
Comments