How to become a leading developer. Part 2

Continued translation of an article by John Allspaw about the personal qualities of leading developers.

Mature developers don't just complain

Instead, they reason based on observations and suggest solutions to the problem they have found. One experienced manager told me: “Never come to your boss with complaints unless you have a ready-made solution to the problem. And it’s better if there are several solutions. ” But even if you did not manage to find a single solution - this is better than complaining just like that.

Mature developers openly compromise in their decisions and judgments

They understand that any technical solutions are ambiguous - the world is not black and white. They can quickly determine in which case a successful solution will work, and in which not. They know that it is impossible to be productive and pedantic at the same time ( ETTO principle ), they know that you have to choose between quality of work and speed , and the problems that they have to solve had to be solved yesterday, or they had no final solution at all.

They know that not all of their work is perfect, but it suits them - they strive to clearly highlight the ideal and imperfect parts of the project. And then, after some time, when the original architecture rests on its ceiling of extensibility, they will not regretfully recall short-sighted decisions in the past, they will not angrily and dislike evaluate everything retroactively, rushing phrases like “These idiots did from the very beginning everything is wrong! ”, or“ They cheated! ”, or“ I SAYED TOLD them that this would not work! ”. Instead, they will say: “Until now, the old code has been working out its own. But we knew that sooner or later we would have to change everything, and it seems that this time has come. To work! ”

There are a lot of laconic statements about such compromises, and mature developers know that it is not always worth trusting these philosophical sayings (this also applies to my words):

• “Premature optimization is the root of all ills.” People abuse this principle, and I already wrote about it. The following follows from this principle (taken from here ): “The leading developer is distinguished from the novice by an understanding of what is premature and what is not . ”
• “For each task - its own tool” is another abused principle. The idea is clear: who wants to use the wrong tool? But this principle can become harmful if we take it literally. Despite the fact that a carpenter may encounter tasks that can be easily solved by any particular hammer, he will not arm himself with tools of all possible types and sizes, because keeping and carrying a bunch of hammers is expensive. The solution to this issue is also a compromise.

In short, on the trade-offs: everyone cuts corners, in any project [and in this translation :) I’m happy with any corrections!] . For immature developers, this is disgusting, and mature ones intentionally, at the very beginning of the project, designate such angles, allow them and consider this part of good design.

(To the same: Your code may be elegant, but mine, bitch, works )

Mature engineers do not fence themselves off

You have problems if someone does not want to understand that his code (or infrastructure) can affect other parts of the system or business, and justifies this by the fact that he clearly follows all the formalities. By covering your ass , you implicitly tell others that you are ready to sacrifice others (your team? Company? Society?) Under the sole pretext that there are no shortcomings in your work. Mature engineers do not go aside and take the responsibility assigned to them. If they understand that they do not have enough authority to be responsible for their work, they are looking for ways to fix it.

An example of self-extinction: “It’s not my fault that everything broke with them. They did something wrong. I have everything according to the specification, and if it had errors, I have nothing to do with it. "

Mature developers can empathize

As a rule, several people are responsible for complex projects at once. Everything in any project: designers, managers, maintenance engineers, developers and guys from the business development department are responsible for their tasks. And mature developers realize that these tasks, like the perception of the whole, can be different for everyone. This allows them to be effective in their affairs. The ability to empathize means the ability to put oneself in the place of another person in the project and take into account his point of view in his work.

In engineering, conflict situations cannot be avoided, and dissatisfaction with them, instead of accepting them as a component of success, is a sign of an immature developer.

Mature developers know about mental traps

No, you do not need to get a diploma in philosophy, but mental traps are something that at some point can slow down the development career of a developer. Most of the mature developers I’m familiar with may not understand the details of how traps arise, or how to deal with them, but they understand that, like all people, they can fall into them.

As a rule, developers have to process large volumes of new information daily. But, having fallen into one of the traps, we begin to interpret the data in such a way that our conclusions contradict the real state of things. This may unexpectedly affect all subsequent work and the final result.

Wikipedia has an extensive list of traps. Developers are mainly affected by the following:

• Distortion in my favor - if everything is fine - then I tried so hard. If it’s bad, then someone else screwed up.
• Distortion of authorship - if another person received a bad result, then the problem is in this person: he is stupid or awkward, maybe messy, etc. If I got a bad result, then the problem is in my environment: this is how the circumstances turned out.
• A retrospective distortion - (they say, this is the most studied phenomenon in modern psychology) if something unpleasant happened (a serious bug, for example), the person says "I knew it!". People tend to evaluate events of the past easier than they actually were. If you hear "... they should have ..." or "... how they didn’t take this into account, it’s obvious!", Know - this is a retrospective distortion.
• Deviation towards the result - if the result is destructive, then the actions that led to this are silly and thoughtless. The worse the result, the stricter the score.
• Planning error - this project will take me no more than a week!

In addition to these traps, there are many others, and all are so interesting that I can drown in their study. I strongly recommend that you read them in more detail if you are interested in increasing your effectiveness.

The Ten Commandments of Impersonal Programming

These commandments were described in the book Psychology of Computer Programming , written in 1971. Despite the age, the words are still relevant. I did not read the book itself, but found a post about it on Stephen Wyatt Bush’s blog . Before her death, his father advised her to Stephen. These commandments are:

1. Understand and get used to the fact that you will make mistakes. The bottom line is that they need to be found before they affect anything. Fortunately, errors in our industry can rarely lead to fatal results (this does not apply to those who work on rocket management software at the Jet Propulsion Laboratory ). We can (and should) learn, laugh at ourselves and move on.
2. Your code is not you. The whole point of inspections is in finding defects. And when they are found, do not take it to heart.
3. No matter how tricky tricks you know, there will always be someone cooler than you. And, if you ask, this person can teach you a couple of new tricks. Listen to others, even if it seems to you that it is not necessary.
4. Do not rewrite code without discussion. There is a fine line between correcting code and rewriting it. Understand the difference, do not change everything yourself, seek changes in the framework of code analysis.
5. Treat those who know less than you, with respect, patience and understanding. Almost all people from the non-technical circle who constantly interact with developers consider us, at best, complacent types. At worst, crybaby. Do not reinforce this stereotype with your anger and impatience.
6. Everything flows, everything changes. Be open to change, accept it with a smile. Take every change in requirements, a change in platform or tool, not as a significant inconvenience to deal with, but as a new test.
7. Real power does not come from ranks, but from knowledge. Knowledge generates power, and power generates respect - so if you want respect in an impersonal environment, develop your knowledge.
8. Fight for what you believe in, but worthily accept defeat. Understand, sometimes your ideals may be rejected. Even if you are right, do not try to take revenge and do not say "I warned you." Do not make a dead idea with your slogan.
9. Do not be a "programmer in the closet." Do not be a person who leaves his dark office just for soda. Such a programmer is out of sight, relationship and control. Such a person does not have a voice in an open environment. Take part in conversations, participate in the life of your office.
10. Criticize the code, not the person - be kind to the programmer, but not to the code. Let all your comments be positive and aimed at improving the code. Point out local standards, specifications, performance improvements, etc. in the comments.

From beginner to expert

I almost no longer follow research in the field of knowledge acquisition, but it’s difficult to get away from this topic in thinking about the development of the industry. One of the main works on this topic is the report of Stuart Dreyfus and Hubert Dreyfus “Five - level model of mental processes involved in the targeted acquisition of skills”, in which they described the characteristics of different levels of competence.

Newbie

• Adherence to the rules;
• narrow perception of the situation;
• lack of judgment (or their limitations).

Advanced beginner

• Interpretation of the rules as appropriate;
• limited perception of the situation.

Competent

• Conscious deliberate planning;
• standard, familiar actions.

Specialist

• Perception of the situation as a whole, and not as a set of separate aspects;
• awareness of deviations from the normal model;
• use of context-sensitive principles.

Expert

• Does not rely on rules;
• intuitive awareness of the situation;
• The analytical approach is used only in new situations.

The report says:

Beginners act on the basis of rules and knowledge. They think and analyze everything, so they work slowly, choose and make decisions.

(i.e. beginners are highly dependent on private laws)

Experts act intuitively based on a mature, holistic, proven understanding, without conscious thought. This is the whole point of experience. They do not consider problems and solutions separately. They act.

(that is, experts act according to circumstances)

I do not quite agree with such a clear separation of levels. It seems to me, in fact, everything is somewhat more blurry. But, nevertheless, even such a simplified classification can be useful.

From a translator: I can’t find on the Internet an interesting work by N. N. Nepeyvody “Levels of knowledge and skills”, if anyone finds it, please post in the comments.

Sensation: Mature developers are aware of the importance of human emotions. (Incredible!)

The attitude of people towards technologies and technical solutions is no less important than the details about these technologies. Mature developers know this and adjust accordingly. Empathy helps them to understand how their colleagues relate to technical solutions, even if it is not so easy for them to express their attitude.

People’s trust in programs, architectures, or patterns depends to a large extent on past experiences, which can lead to both positive and negative attitudes. If you had to work with an online store on mod_perl, which constantly fell in completely mysterious circumstances, it is not surprising that in another company you would not want to work with this technology even in completely different conditions. You just know that mod_perl has big problems and will avoid using it anyway.

Mature developers understand this when they opt for technology with similar, albeit absurd, baggage. Convincing a group to use tools and templates that do not suit them is not an easy task. The principle “for each task has its own instrument” must take into account this, not always quantitative, parameter.

As an example of how emotions make people make decisions, read some holivar about anything.

“It’s amazing what can be achieved if you don’t think about merit”

This quote is usually attributed to Harry Truman, but I have a feeling that these are the words of some Jesuit priest. One way or another, another sign that you are working with a mature engineer is if he values ​​the success of the project higher than the possible personal benefits that he can get for working on this project.

This idea will set us free, and as soon as everyone understands and assimilates it, the world of progress and advanced thinking flourishes, the engineers will not be concerned about equating their work with personal career success.

This is not the end

I am fortunate that I work with mature engineers at Etsy, which is very honorable for me. Our industry is still young, and despite the fact that we still have a lot to learn from engineers from other fields, I think we have some advantage. The Internet is inextricably linked with the dissemination of information, and if we want to grow into a real branch of knowledge, into discipline, we must constantly pay attention to what it means to be a “leading” and “mature” developer.

Thanks to Seryoga and Renate for their help in translating. Thanks to my mentors, Andrey and Sergey, who every day show me what it means to be a “leader” and how to be one.