Computers & Electronics

How to become a lead developer. Part 2

Spread the love

Continuation of the translation of John Allspaw ‘s article on 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 find. An experienced manager told me, “Never go to your boss with a complaint unless you have a solution to a problem. And it is better if there are several solutions. ” But even if you didn’t manage to find a single solution, it’s better than just complaining.

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 good solution will work and which 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 the quality of work and speed , and the problems they face had to be solved yesterday, or they have no final solution at all.

They know that not all of their work is perfect, but they are happy with it – they strive to clearly highlight the ideal and non-ideal parts of the project. And then, after a while, when the original architecture hits its ceiling of expandability, they will not regretfully remember the short-sighted decisions in the past, they will not evaluate everything with anger and dislike in hindsight, throwing phrases like “These idiots from the very beginning did it’s all wrong! ”or“ They faked! ”or“ I TOLD them it won’t work! ” Instead, they say, “So far, the old code has worked its way. But we knew that sooner or later we would have to change everything, and it seems that this time has come. Get to work! “

There are many laconic statements about such compromises, and mature developers know that it is not always worth trusting these phrases full of philosophy (this also applies to my words):

  • “Premature optimization is the root of all troubles.” People abuse this principle and I have already written about it. This principle implies the following (taken from here ): “The difference between the lead developer and the newbie is the understanding of what is ‘premature’ and what is not . 
  • “There is a tool for every task” is another principle that is abused. The idea is clear: who wants to use the wrong tool? But this principle can become harmful if taken literally. Despite the fact that a carpenter may be faced with tasks that can easily be solved with a particular hammer, he will not arm himself with tools of all kinds and sizes, because it is expensive to maintain and carry a bunch of hammers with him. The solution to this issue is also a compromise.

Briefly about the trade-offs: everyone cuts corners, in any project [and in this translation 🙂 I am glad for any corrections!] . For immature developers, this is disgusting, and mature ones deliberately, at the very beginning of the project, designate such angles, allow them and consider it part of good design.

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

Mature engineers don’t shield themselves

You have problems if someone does not want to understand that their code (or infrastructure) can affect other parts of the system or business, and the excuse is that they follow all the formalities. By covering your ass , you implicitly inform others that you are ready to sacrifice others (your team? Company? Society?) Under the pretext that there are no flaws in your work. Mature engineers do not step aside and take on the responsibility assigned to them. If they realize they don’t have enough authority to be accountable for their work, they look for ways to fix it.

An example of self-expression: “It’s not my fault 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 Have Empathy

As a rule, several people are responsible for complex projects at once. In any project, everyone: designers, managers, operations engineers, developers and the 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 business. The ability to empathize means the ability to put yourself in the place of another person in the project and take his point of view into account in your work.

Conflict situations cannot be avoided in engineering, 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 degree in philosophy, but mental traps are something that at a certain moment can slow down a developer’s career. Most mature developers I am familiar with may not understand the details of how traps arise or how to deal with them, but they do understand that, like all people, they can get caught in them.

Typically, developers have to process large amounts of new information every day. But, falling into one of the traps, we begin to interpret the data in such a way that our conclusions contradict the real state of affairs. This can unexpectedly affect all subsequent work and the final result.

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

  • A distortion in my favor – if everything is good, then I tried so hard. If it’s bad, then someone else has screwed up.
  • Distortion of authorship – if another person got a bad result, then the problem is in this person: he is stupid or awkward, maybe sloppy, etc. If I got a bad result, then the problem is in my environment: this is how the circumstances developed.
  • 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 in 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!”, You should know that this is a retrospective distortion.
  • Deviation towards the result – if the result is destructive, then the actions that led to this are stupid and rash. The worse the result, the stricter 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 familiarize yourself with 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 their age, the words are still relevant. I haven’t 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 used to the fact that you will make mistakes. The bottom line is that you need to find them before they affect anything. In our industry, fortunately, mistakes can rarely be fatal (this is not the case for those working 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 checks is to find bugs. And when they are found, do not take it personally.
  3. No matter how many tricky tricks you know, there is always someone cooler than you. And, if you ask, this person can teach you a couple of new tricks. Listen to others, even if you don’t think you need it.
  4. Don’t rewrite code without discussion. There is a fine line between fixing code and rewriting it. Understand the difference, do not change everything yourself, seek changes through code analysis.
  5. Treat those who know less than you with respect, patience and understanding. Almost all non-tech people who interact with developers on a daily basis consider us to be smug types at best. At worst, crybabies. Don’t reinforce this stereotype with your anger and impatience.
  6. Everything flows, everything changes. Be open to change, accept it with a smile. Think of every change in requirements, platform or tool, not as a significant inconvenience that needs to be dealt with, but as a new challenge.
  7. Real power does not come from titles, but from knowledge. Knowledge breeds power, and power breeds 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 take revenge and do not say “I warned you.” Don’t make an already dead idea your slogan.
  9. Don’t be a “closet programmer”. Don’t be the man who only leaves his dark office for soda. Such a programmer is out of sight, relationship and control. Such a person has no voice in an open environment. Get involved in conversations, get involved in your office life.
  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 hardly follow any research in the field of knowledge acquisition, but it’s hard to get away from this topic when thinking about the development of the industry. One of the major works on this topic – the report Stuart Dreyfus and Hubert Dreyfus’ five-level model of the mental processes involved in getting targeted skills “, in which they described the characteristics of the different levels of competence.

  • Strict adherence to the rules;
  • narrow perception of the situation;
  • lack of judgment (or limited judgment).
Advanced beginner
  • Interpretation of the rules according to the circumstances;
  • limited perception of the situation.
  • Conscious deliberate planning;
  • standard, familiar actions.
  • 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.
  • Doesn’t rely on 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 are slow to work, choose and make decisions.

(i.e. newbies are heavily dependent on private laws)

Experts operate intuitively from a mature, holistic, proven understanding, without conscious deliberation. This is the whole point of experience. They do not consider problems and solutions in isolation. They work.

(that is, experts act according to circumstances)

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

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

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

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

People’s trust in programs, architectures, or patterns is highly dependent on past experience, which can lead to both positive and negative attitudes. If you had to work with an online store based on mod_perl, which constantly crashed under completely mysterious circumstances, then 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 there are big problems with mod_perl and you will avoid using it anyway.

Mature developers understand this when they choose technology with similar, if absurd, baggage. Convincing the group to use tools and templates that they are not happy with is not an easy task. The principle “for each task – its own tool” should take into account this, not always quantitative, parameter.

For an example of how emotions drive people to make decisions, read a 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 it is 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 more than the possible personal benefit he could get from working on the project.

This idea will set us free, and once everyone understands and assimilates it, a world of progress and forward thinking flourishes – engineers will not be concerned with equating their work with personal career success.

This is not the end

I am fortunate to be working with mature engineers at Etsy, which is a great honor for me. Our industry is still young, and while we still have a lot to learn from engineers in other fields, I think we have some advantage. The Internet is inextricably linked to the dissemination of information, and if we want to grow into a true 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 Renata for their help in translation. Thanks to my mentors, Andrey and Sergey, who show me every day what it means to be a “leader” and how to be.

Spread the love
Leave a Reply

Your email address will not be published. Required fields are marked *

Adblock Detected!

Our website is made possible by displaying online advertisements to our visitors. Please consider supporting us by whitelisting our website.

Enable Notifications    OK No thanks