How to become a leading developer. Part 2

Continuation of the translation of the article by John Ollspou on the personal qualities of leading developers.

Mature developers don't just complain

Instead, they reason, based on observations, and offer solutions to the problem they found. An experienced manager told me: “Never come to your boss with complaints if you don’t have a ready-made solution. And it is 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 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 it will not. They know that it is impossible to be productive and pedantic at the same time ( ETTO principle ), they know that they have to choose between quality of work and speed , and the problems that they face have to be solved yesterday, or they have no definitive solution at all.

They know that not all their work is perfect, but they are satisfied with it - they tend to clearly highlight the ideal and imperfect parts of the project. And then, after some time, when the original architecture rests on its extensibility ceiling, they will not regretfully recall short-sighted decisions in the past, they will not hate everything with hate and hostility , rushing with phrases like "These idiots from the very beginning did everything is wrong! ”, or“ They fired! ”, or“ I told them that it would not work! ”. Instead, they will say: “Until now, the old code was working on its own. But we knew that sooner or later we will have to change everything, and it seems that this time has come. For the work! ”
')
Many laconic statements about such compromises are known, and mature developers know that it is not always worth trusting these complete philosophies of 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 beginner by the understanding of what is“ premature, ”and what is not .
• "For each task - its own tool" - another abused principle. The idea is clear: who wants to use the wrong tool? But this principle can become harmful if you take it literally. Despite the fact that the carpenter may face problems that are easily solved by a particular hammer, he will not arm himself with tools of all possible types and sizes, because it is expensive to carry and carry a lot of hammers with him. The solution to this question is also a compromise.

Briefly on compromises: everyone cuts corners, in any project [and in this translation :) I am glad for any corrections!] . For immature developers, this is disgusting, while mature ones intentionally, at the very beginning of the project, designate such angles, allow them and consider this to be part of good design.

(Here: Your code may be elegant, but mine, bitch, works )

Mature engineers do not block themselves

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. Covering your ass , you implicitly tell others that you are ready to sacrifice others (your team, company, society?) On the pretext that there are no flaws in your work. Mature engineers do not go to the side and take the responsibility entrusted to them. If they understand that they do not have enough authority to be responsible for their work, they look for ways to fix it.

An example of self-liberation: “I’m not guilty that everything is broken. They did something wrong. I have everything according to the specification, and if there were mistakes in it, I have nothing to do with it. ”

Mature developers can empathize

As a rule, several people are responsible for complex projects. In any project, everything: designers, managers, operating engineers, developers and guys from the business development department are responsible for their tasks. And mature developers are aware that these tasks, like the perception of the whole, may all be different. This allows them to be efficient in their affairs. The ability to empathize means the ability to put oneself in the place of another person in a project and to take his point of view into account 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, it is not necessary to get a diploma in philosophy, but mental traps are something that at some point can slow down the career growth of a developer. Most mature developers with whom I am familiar may not understand the details of how traps arise or how to deal with them, but they understand that, like all people, they can get caught in them.

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

Wikipedia has an extensive list of traps. Developers are mainly subject to the following:

• Distortion in their favor - if everything is good - it means that I tried so hard. If it is bad, it means that someone else has done it.
• Distortion of authorship - if another person got a bad result, then the problem is in this person: he is stupid or clumsy, can be sloppy, etc. If I got a bad result, then the problem is in my environment: this is how things happened.
• 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 that!". People tend to evaluate the events of the past easier than they actually were. If you hear "... they should have ..." or "... as they did not take it into account, it's obvious!", You know - this is a retrospective distortion.
• Deviation in the direction of the result - if the result is destructive, then the actions that led to this are stupid and rash. The worse the result, the more severe the assessment.
• 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.

Ten Commandments of Impersonal Programming

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

1. Understand and get over the fact that you will make mistakes. The bottom line is that they need to be found before they affect something. In our industry, fortunately, errors rarely lead to fatal results (this does not apply to those who work on missile control 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 checking - in the search for defects. And when they are found, do not take it to heart.
3. No matter how many clever tricks you know, there will always be someone better 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 this is not necessary.
4. Do not rewrite the code without discussion. There is a fine line between correcting the 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 non-technical people who constantly interact with developers consider us, at best, to be 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 them with a smile. Take every change in requirements, a change of platform or tool, not as a major inconvenience to be dealt with, but as a new ordeal.
7. Real power does not come from titles, 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 accept defeat with dignity. Understand, sometimes your ideals can be rejected. Even if you are right, do not try to revenge and do not say "I warned you." Do not make a dead idea with your slogan.
9. Do not be a "programmer in a garret". Do not be a man who comes out of 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. Comment on local standards, specifications, performance improvements, etc.

From beginner to expert

I almost do not follow the research in the field of knowledge acquisition, but it is 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 by Stuart Dreyfus and Hubert Dreyfus “A five - level model of mental processes involved in targeted acquisition of skills,” in which they described the characteristics of different levels of competence.

Newbie

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

Advanced beginner

• Interpretation of the rules according to circumstances;
• limited perception of the situation.

Competent

• Conscious thoughtful planning;
• standard, habitual actions.

Specialist

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

Expert

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

The report states:

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

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

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

(i.e., 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 an interesting work on the Internet by N. N. Nepejvoda “Levels of knowledge and skills”, if anyone finds it, put it in the comments, please.

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

The attitude of people to technology and technical solutions is no less important than the details about these technologies. Mature developers know this and adjust accordingly. The ability to empathize helps them 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 is largely dependent on past experience, 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 will not want to work with this technology even in completely different conditions. You just know that there are big problems with mod_perl, and you will avoid using it anyway.

Mature developers understand this when they make a choice in favor of technology with similar, albeit absurd, luggage. Convincing the group to use tools and patterns that do not suit them is not an easy task. The principle “for each task is its own tool” must take into account this parameter, which is not always quantitative.

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

“It’s amazing what you can achieve 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. Anyway, another sign that you are working with a mature engineer is if he appreciates the success of the project higher than the possible personal gain he can get for working on this project.

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

This is not the end

I’m lucky that I’m working with mature engineers at Etsy, for me it’s very honorable. Our industry is still young, and despite the fact that we still have a lot to learn from engineers from other areas, 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 a discipline, we must constantly pay attention to what it means to be a “leading” and “mature” developer.

Thanks to Seryoga and Renate for help with translation. Thanks to my mentors, Andrey and Sergey, who every day show me what it means to be "leading" and how to be.