How to become a leading developer. Part 1

This is a translation of an article written by John Allpaw , who is currently the senior vice president of engineering at Etsy .

Continuing translation here

In our field of activity, we have access to huge amounts of knowledge, especially those that allow the developer to become effective. But for some reason, despite the existence of many books on specific tasks and responsibilities of managers in non-technical areas, I hardly see new books or articles on how to become a good lead developer. The remarkable exception, of course, are the articles of Kate Matsudaira [from the translator: in the photo, by the way, it was she] who wrote a lot about the cultural components of engineering.
')
But at the same time, all my friends, successful developers remember their mentors, who taught them what it means to be "leading . "

I totally agree on the definition of the “lead” with my friend Theo. In his chapter in the Web Operations book of O'Reilly, he writes:

Generation X (and even more so Generation Y ) is a culture of immediate satisfaction. I have worked with an astounding number of engineers who expect that their “career path” to the highest engineering positions will take no more than five years just because they are smart. But it is simply impossible. Too many of them. Not everyone can be leading. Surely, if you lead in five years, 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 after five years? „Superfood engineer“. I think the problem lies in the youth of our industry. In fact, very few people have been involved in 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 is right, the scope of web administration is still very young. And therefore, it is not surprising that people with the title of “presenters” demonstrate immature behavior, both from a technical and a human point of view. If you have not read the entire chapter of Theo, I recommend that you do it.

But still, what does it mean for us to be "leading"? I have to hire, support and help developers who are considered "leading", and I certainly have an opinion on this issue. The idea that there is a certain threshold in career development is good, but I will add that this threshold is blurred - this is not a simple list of tasks. One morning you won’t be “leading” just because of the new name of your post after the promotion. Lead developers can not know everything. Their technical knowledge is not flawless, but they don’t worry about it.

To avoid confusion between titles and vague expectations, I will talk about engineering maturity .

I assume that the “lead” engineer is a mature engineer.

I’ll leave out the part where you could list technical areas that a mature engineer should somehow own or understand (for example, networks, file systems, 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 features (other than technical skills and experience) that are inherent in the best managers of technical departments? ". Having answered the question, I realized that I myself constantly strive 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 features as leading engineers in other fields (in mechanics, electrics, chemistry, etc.), for which the “ Unwritten laws of engineering ” are applicable. Again, if you have not read this book, I recommend to do it. It was published in 1944 by the American Society of Mechanical Engineers . An excerpt from the book can be read here .

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 and responsibilities and the internal workings of the technical organization regarding how managers and mature engineers should act.

Mandatory qualities of mature engineers

All articles with attempts to describe the necessary qualities will be overwhelmed with items in their enumerations: in engineering there is something to talk about. I will describe only some of the qualities: I reached some of them myself, some I took from different sources, many from the “Unwritten Laws” mentioned above.

Mature developers welcome constructive criticism of their ideas.

All successful engineers whom I met, after completing the development and planning of the project, constantly ask colleagues such questions:

• What could I miss?
• Why might it not work?
• What can I be wrong?
• If even from a technical point of view, it sounds right, will the whole organization understand this enough to manage, support and expand it?

They know that nothing they have done will remain only in their hands, and a good check from colleagues is what will make their product better. As it was said somewhere, they are “happy for the bad news.”

Mature developers are aware of how they are perceived personally

It is not enough to write in a dream a Bloom filter on Erlang or a multithreaded program in C. It doesn’t matter if nobody wants to work with you. A mature engineer knows that completeness, elegance and superiority of his ideas mean nothing if no one wants to work with him because he is a jerk . Condescension, underestimation, self-admiration and self-advertisement repel other engineers from you (only in the subconscious mind). But the joy of development, in a sense, lies precisely in enjoying the company of people with whom you design and create something new. An engineer who easily calls another a moron is doomed to a halt in his development.

Therefore, mature developers ponder how they interact with others. Yes, not all mature engineers are able to easily communicate with people, but everyone knows what they can become better at, and constantly ask their colleagues and managers to meticulously check what they do and how. It is important for them to be assertive in spreading their ideas, but not passive or aggressive.

I have already said , but it is worth emphasizing it again: the extent to which other people want to work with you directly indicates 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 to offend someone. There is a difference between calling someone a moron and pointing out the flaws in his 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 acquire thick skin and learn to perceive criticism from the point of view that precludes a focus on the individual.

Dukes have been and will always be, and they should beware. But we have to get rid of the attitude towards someone else's code, like his child. The code does not feel anything, it does not have complexes, and it, naturally, will not manifest the most important quality (the ability to multiply), embedded in your genes.

With this, I think, is connected a passage from the “Unwritten Laws” (my emphasis):

Carefully follow those you mark as recipients of letters, notes and other documents in which the interests of other departments may be affected.

Much harm was caused by young workers who distributed documents containing harmful or inconvenient information . Yes, it is not easy for a newcomer to recognize a “bomb” in such a document, but, in general, it is clear that problems may arise if the note oppresses someone’s interests or reveals other people's shortcomings. You'd better consult with your boss if the document is widespread or if it discusses problems of production or customers, and if you are not completely sure that you are right.

This quote underlines the considerable age of the book, but I believe that the essence of these words is still relevant now. Nothing speaks of short-sightedness and ignorance like a badly thought-out, unconstructive, tweet throwing poisonous attacks. Beginners make the mistake of driving over 140 characters on complex technologies.

I always pay attention to this kind of public statements when I come across them, and if such a person comes to an interview with us at Etsy, I’ll have a good think before taking him to work (Christopher Brown spoke about this in his report on Velocity London ).

Mature developers do not avoid forecasts, but constantly improve them.

From the "Unwritten Laws" :

Promises, schedules and forecasts are necessary and important tools of a well-organized business. Many engineers do not understand this and dodge the annoying responsibility for their obligations. You must make promises based on your predictions for the part of the work you are responsible for and the predictions of the departments with which you are associated. No one should delay the work with this wording: "I can not promise anything, my work is connected with a large number of uncertain factors."

Shirking responsibility for forecasts is the same as saying: “I am not ready to be trusted to write important parts of the infrastructure.” All cases depend on forecasts, and all developers involved in the project are engaged in joint activities , which means that everyone should be responsible for their predictability . In general, mature engineers can safely work with a certain non-zero level of uncertainty and risk.

Mature developers have developed intuition, even if they do not know about it.

This code looks good, I'm proud of myself. I asked other people to check it out and recorded all the reviews. And how long will it take me to rewrite and correct? How will my code affect the server when it gets there? How and how much will CPU / memory / disk / network usage change? Will others understand this code? Is my code simple enough so that others can penetrate and expand it?

Mature developers understand that not every project will have stars from heaven

No matter how meaningless or insignificant your first assignments seem, make every effort to them.

The ability to bring things to the end, means to do what you are not interested. No matter how attractive the project is, there will still be boring and tedious tasks, tasks that newcomers are considered to be below their dignity or position. My friend, Kellan Elliot-McCree (CTO in Etsy), says the following about it:

Sometimes salvation can be found in the simplicity of boring tasks. Maturity says that such tasks need to be done quickly and move on. Sometimes boring tasks require extreme discipline and concentration. Strangely enough, the most boring tasks that are performed only by leading engineers can be at the same time the most unusual.

Mature developers pump the skills and qualifications of others

They realize that at some point their individual contribution will no longer correspond to the possible speed of development of the project. They realize that no one person can do everything at once, and that the world's greatest feats were performed by teams , not outstanding singles. Tom Limoncelli convincingly proves this in his blog.

In Etsy, we call it “the bounty of the mind.” The generosity of the mind is one of our most important engineering values, but, in addition, it is the primary responsibility of our engineering staff. These people invest their time in training younger and new developers, so that as many employees as possible not only understand what they are doing, but why . The ability to “learn to fish” at this level is obligatory, and this requires both patience and far-sighted investment of the entire organization.

Therefore, instead of saying, “So, move, let me do it,” we say, “Clearly, let's deal with it. I will show you how to write / debug / etc. And then you will do the same so that I can make sure that you understand how and why we do it this way. ”

This completes the first part of the translation. I will be glad to constructive criticism and advice. I tried, but maybe I understood something and translated it incorrectly or clumsily - offer your options. Accepted pull requests on github.

The second part of