This is a translation of an article by John Allspaw, who is currently the senior vice president of engineering at Etsy.
In our field of activity, we have access to a huge amount of knowledge, especially those that allow a developer to become effective. But somehow, despite the fact that there are many books on the specific tasks and responsibilities of managers in non-technical areas, I see almost no new books or articles on how to become a good lead developer. The notable exception, of course, is the articlesKate Matsudaira
But at the same time, all the successful developers I know remember their mentors, who taught them what it means to be âthe leaderâ .
I totally agree with my friend Theo in defining the meaning of “leading”. In its chapter in the bookO’Reilly’s Web Operations, he writes:
Generation X (and even more soGeneration Y ) is a culture of immediate gratification. I have worked with an astounding number of engineers who expect their “career path” to top engineering positions to take no more than five years just because they are smart. But this is simply not possible. Too many of them. Not everyone can be a leader. Really, if in five years you are the presenter, then you are at the peak of your development? In five more years, won’t you get even more valuable experience? What then? Super Engineer? And in another five years? “Super Duper Engineer”. I think the problem lies in the youth of our industry. Indeed, few people have done web administration (web operations ) for fifteen years. Given the dynamics of the industry, many prefer management positions or the risk of an entrepreneurial race.
He’s right, the field of web administration is still very young. And so it shouldn’t come as a surprise when people with the title of âleadingâ exhibit immature behavior, both from a technical and human point of view. If you haven’t read Theo’s entire chapter, I recommend that you do so.
But still, what does it mean to us to be âthe leaderâ? I have to hire, support and help developers who are considered to be âleadingâ, and I certainly have an opinion on this matter. The idea that there is a threshold in career development is good, but I will add that this threshold is blurred – this is not just a list of tasks. You will not become the âleaderâ one morning just because your new title after your promotion suggests it. Leading developers can’t know everything. Their technical knowledge is not perfect, but they do not worry about it.
To avoid confusion between titles and vague expectations, I’ll talk about engineering maturity .
I assume that the âleadâ engineer is a mature engineer.
I will omit the part where it would be possible to list the technical areas that a mature engineer must somehow master or understand (for example, networks, filesystems, algorithms, etc.), and, instead, highlight those personal qualities that tell me that a person can positively influence the technical side of an organization or business.
I was asked a question on Quora: âWhat are the distinguishing traits (other than technical skill and experience) of the best technical managers? “. After answering the question, I realized that I myself am constantly striving to possess the qualities mentioned in the answer. This post is similar to that answer.
It is worth saying that leading engineers in web development and administration have the same traits as leading engineers in other areas (mechanics, electrical, chemistry, etc.) for which they are applicable “The Unwritten Laws of Engineering â. Again, if you haven’t read this book, I recommend doing so. It was published in 1944American Society of Mechanical Engineers . An excerpt from the book can be readhere .
Despite the fact that the structure of the book and the syllable are outdated ( “… refrain from using foul language at the workplace …” or “… men should pay some attention to shaving and trimming beards and mustaches” ), it gives a good description of non-technical expectations, responsibilities and the internal workings of the technical organization in relation to how managers and mature engineers should act.
Required Qualities of Mature Engineers
All articles attempting to describe the required qualities will be overflowing with points in their enumerations: there is something to talk about in engineering. I will describe only some of the qualities: I reached some myself, some I took from different sources, many from the “Unwritten Laws” mentioned above.
Mature developers welcome constructive criticism of their ideas
All the successful engineers I have met, at the end of the development and planning of the project, constantly ask their colleagues these questions:
- What could I be missing?
- Why might this not work?
- What could I be wrong about?
- Even if this sounds true from a technical standpoint, would it be clear enough for the entire organization to manage, maintain, and expand it?
They know that nothing they do will remain in their hands, and a good peer review is what will make their product better. As it was said somewhere, they are “happy about bad news.”
Mature developers are aware of how they are perceived personally
Skill to write in a dream is not enough filter Bloom in Erlang or a multithreaded C program. It doesn’t matter if no one wants to work with you. A mature engineer knows that the completeness, elegance, and excellence of his ideas mean nothing if no one wants to work with him because hemoron . Condescension, underestimation, self-admiration and self-promotion push other engineers away from you (maybe only on the subconscious). But the joy of development, in a sense, lies precisely in the enjoyment of the company of people with whom you design and create something new. An engineer who easily calls another a moron is doomed to stop in his development.
Therefore, mature developers think about how they interact with others. Yes, not all mature engineers know how to communicate with people easily, but everyone knows where they can become better, and constantly ask their colleagues and managers to meticulously check what and how they do. It is important for them to be assertive in spreading their ideas, but not passive or aggressive.
I’m already said , but it’s worth emphasizing this again: the degree to which other people want to work with you directly speaks of how successful you will be in your development career. Be the person everyone wants to work with.
This does not mean that you should not constructively criticize the work (or listen to criticism) done by another person (but not his personality), fearing of offending someone. There is a difference between calling someone a moron and pointing out flaws in their code or product. In our conversation, Theo noted another area in which we can change for the better:
We, as an industry, should not criticize each other’s character or appearance, but we should criticize the results of our work. We need to get thick skin and learn to perceive criticism from a point of view that excludes focus on the individual.
Nerds were and always will be, and they should beware. But we must get rid of treating someone else’s code as their child. The code does not feel anything, it has no complexes, and it, naturally, will not show the most important quality (ability to reproduce) inherent in your genes.
With this, I think, is connected an excerpt from the “Unwritten Laws” (emphasis mine):
Keep a close eye on who you mark as recipients of letters, notes, and other documents that may affect the interests of other departments.
Much harm was done by young workers who distributed documents containing harmful or inconvenient information . Yes, it is not easy for a beginner to recognize a “bomb” in such a document, but, in general, it is clear that problems can arise if someone’s interests are oppressed in a note or other people’s shortcomings are revealed. You’d better consult with your boss if the document is going to be widely circulated, or if it discusses production or customer issues, and if you are not completely sure you are right.
This quote emphasizes the considerable age of the book, but I believe that the essence of these words is still relevant now. Nothing says shortsightedness and ignorance like a poorly thought-out, unconstructive, venomous tweet. Beginners make the mistake of running over complex technologies in 140 characters.
I always pay attention to these kinds of public statements when I come across them, and if such a person comes for an interview with us on Etsy, I’ll think carefully before hiring him (Christopher Brown talked about the same in his talk at Velocity London).
Mature developers do not shy away from predictions, but constantly improve in them
From The Unwritten Laws :
Promises, schedules and forecasts are essential and essential tools for a well-run business. Many engineers do not understand this and shirk the annoying responsibility for their obligations. You must make promises based on your predictions about the part of the work you are responsible for and the predictions of the departments you are associated with. No one should delay work with this wording: “I can not promise anything, my work is associated with a lot of uncertain factors.”
Shirking responsibility for making predictions is like saying, “I’m not ready to be trusted to write important pieces of infrastructure.” All cases depend on forecasts, and all developers involved in the project are busyjoint activities , which means that everyone should be responsible for their own predictability . In general, mature engineers can safely work with some non-zero level of uncertainty and risk.
Mature developers have strong intuition, even if they don’t know about it
This code looks pretty good, I’m proud of myself. I asked other people to check it out and wrote down all the reviews. How long will it take me to rewrite and correct now? How will my code affect the server when it gets there? How and how much will CPU / memory / disk / network usage change? Will others be able to understand this code? Is my code simple enough for others to dig into and expand on?
Mature developers understand that not every project will have enough stars from the sky
No matter how meaningless or insignificant your first assignments may seem, do your best to them.
The ability to bring things to the end means doing what you are not interested in. No matter how attractive the project is, there will still be boring and tedious tasks, tasks that are considered below their dignity or position by newcomers. My buddy Kellan Elliot-McCree (CTO at Etsy) has this to say about this:
Sometimes the salvation can be found in the simplicity of boring tasks. Maturity tells you to get things done quickly and move on. Sometimes boring tasks require utmost discipline and concentration. Oddly enough, the most boring tasks that are performed only by leading engineers can be at the same time the most unusual.
Mature developers upgrade the skills and qualifications of others
They realize that at some point their individual contribution will no longer match the possible speed of the project’s development. They realize that no one person can do everything at once, and that the world’s greatest feats were accomplished by teams , not extraordinary individuals. Tom Limoncelli convincinglyproves it on his blog.
At Etsy, we call this “bounty of mind.” Generosity is one of our most important engineering values, but it is also the primary responsibility of our engineering staff. These people invest their time in training junior and new developers, so that as many employees as possible not only understand what they are doing, but also why . The ability to âteach to fishâ at this level is imperative, and it requires both patience and forward-looking investment from the entire organization.
Therefore, instead of saying, “Now, move over, let me do it,” we say, “I see, let’s figure this out. I’ll show you how to write / debug / etc. Then you will do the same, so that I make sure that you understand how and why we do it this way. “
This completes the first part of the translation. I would be glad to receive constructive criticism and advice. I tried, but maybe I understood something and translated it incorrectly or clumsily – suggest your options. Pull requests are accepted for GitHub .