While reading the great article On Being A Senior Engineer of John Allspaw, I felt a desire to make notes, and this current post is a way to turn those notes public.
First of all, instead of using the word “senior” to reference experienced engineers, John used the word “mature” because (as he said):
I expect a “senior” engineer to be a mature engineer.
To be a senior engineer is more to develop engineering skills than soft skills. On the other hand, to be a mature engineer is more to develop soft skills than engineering skills.
For me, engineering skills is easier to learn than soft skills because these last need time, patience and reflection from whom desire to have them. While engineering skills are just a matter of study.
John mentioned four questions which are asked by mature engineers to their peers:
- “What could I be missing?”
- “How will this not work?”
- “Will you please shoot as many holes as possible into my thinking on this?”
- “Even if it’s technically sound, is it understandable enough for the rest of the organization to operate, troubleshoot, and extend it?”
Mature engineers know that they are not the best and that good peer review is what makes better design decisions. They “beg for the bad news.” completed, John said.
Mature engineers are capable to make estimates and to make them better one after another. They don’t avoid commitment. They know what they are doing and if not, they find a way to know.
Mature engineers see problems coming. Rather than being taken by surprise, mature engineers present their views on likely problems as soon as they realize they might happen.
Work is work, even if it is bug fixing, a mature engineer always knows that is possible to deliver great results independently of what kind work they are doing.
The base code is something built and maintained by the entire team, not only by the most seniors. With that principle in mind, mature engineers always work looking for what they can do better but also what their peers can do better too.
Mature engineers understand the difference between mentorship and sponsorship, and develop a habit of the latter.
What members of underrepresented groups in tech often need most is opportunity and visibility, not advice.
Instead of advising, mature engineers give to each person on their group the opportunity and visibility bringing those who have less seniority of them to the same level.
“Premature optimization is the root of all evil.”
Understanding what is and isn’t “premature” is what separates senior engineers from junior engineers.’
Mature engineers stand up and accept the responsibility given to them. If they find they don’t have the requisite authority to be held accountable for their work, they seek out ways to rectify that.
Goal conflicts are inherent in all engineering work, and complaining about them (instead of embracing them as requirements for success) is a sign of a less mature engineer.
Instead, they express judgments based on empirical evidence and bring with those judgments options for solving the problem which they’ve identified.
Culturally, engineers work day-to-day in empirical evidence in research. Basically: show me the data. The issue with cognitive biases is that we can be blissfully unaware of when we are interpreting data with our own brains in ways that defy empirical data and can have a surprising effect on how we get work done and work on teams.
Mature engineers know they’re not just dealing with code. The code that a company produces is the end result of teamwork done by people (your team) for people (your customers). Learning to deal with the feelings of others is essential to being desirable to a company that depends on people to deliver software.
Source: DEV Community