Feeding and caring for developers (or why we are so grumbling)
Note translator - In the original, the familiar term “software engineer” was used by everyone. Since its Russian analogue “software engineer” is rarely used in everyday speech, I had to use the word “developer” as the closest. Also, the profession “short-order cook”, with which the author compares the position of many developers in the industry, was translated as “errand boy” - it seems to me that it perfectly captures the essence of the problem of relationship to developers. Finally, I tried to use “develop” and “development” instead of the words “to code” and “programming” because of the negative meaning of the words “encode” and “programming” in Russian as primitive processes of translating requirements into machine instructions low or high level.
The author of the original article is Nickolas C. Zakas, a well-known frontend developer and JavaScript evangelist who worked for more than five years at Yahoo. This is a post from his blog , in which he talks about why it is so difficult to agree with the developers and what to do about it.
Not so long ago, Jenna Baylotta wrote a wonderful article, “How designers can get along with developers,” in which she describes the methods of working in a team that allow designers and developers to achieve better performance. I once worked with designers (and, working in the UI, and with developers) and faced with similar problems, so I understand its practical approach. During teamwork, it never hurts to respect the work of your colleagues and to understand their way of thinking.
')
One of the main thoughts of this article was that developers say “no” too quickly. This thought immediately entered my brain and for a long time refused to get out of it. I wanted to exclaim: “But wait, you do not understand why we say no!”. A million other defensive arguments appeared immediately. In fact, of course, she is right - we really say “no” too quickly, and not only to designers, but to everyone in general. This prompted me to reflect on the psychology of the developers and what constitutes our true essence.
Let's be honest with us, the developers, the reputation of such proud debaters with regular mood swings. We constantly say “no”, clarify the details to indecent pedantry and believe that we can do the work of any of our non-technical colleagues much better than themselves. And, what is already there, this stereotype largely corresponds to the truth - that is what we are doing day after day, in the intervals between writing code and reading Twitter from Hacker News.
(Note: Some of you will say that not all developers are such, and they will be right. There is a small percentage of developers who cannot be included in the above category. Do not rush to scroll down and write in comments that the author is an idiot, read on .)
Nobody gives out a reputation just like that, they earn it. What surprises me about this reputation is the fact that I personally know a bunch of developers, and, as a rule, they are benevolent, pleasant (if you don’t stubborn with them) and just funny guys. You can have a great time with them after work or on weekends. So why at work do they become completely different people?
I have a theory. It lies in the fact that developers see themselves quite differently from their colleagues. I came to this conclusion for more than ten years of work in large and small software development companies. Employees of such companies (product managers, designers, other managers) usually look at developers as simple builders. The product manager should come up with an original idea, the designer should express it in a beautiful form, and the developer should only bring these ideas to life. In fact, engineers are looked at as errand boys, doing exactly that and only what they were told.
My first manager warned me about this. When the first company in which I worked collapsed, we had a very frank conversation about my future career. Although we didn’t always get along, he gave me great advice then (further inaccurate quotation):
He was completely right. There are many companies that need errand boys, they need builders who will write code in a well-defined pattern without the right to take a step aside. I would even say that these are the majority of companies, both large and small. I have long lost count of how many founders of startups offered me a share in the company in exchange for the realization of their author's vision. All of them proceed from the assumption that they already have ideas, they only need someone who brings them to life.
And here the main root of the problem is buried - the developers are not really obedient builders. Developers - creators. You yourself, in a sense, are engaged in assembling each time you assemble furniture from Ikea. You have all the instructions in your hand, and if you follow them step by step, you will assemble that ridiculously small table that you wanted. Creativity is a completely different job, it is the creation of something without specific directions or instructions. You start with a blank canvas, and end with a work of art. Developers are so fond of programming, not because they want to execute someone's instructions, but because they understand that they can do various interesting things with it. We all fell in love with the development process, because once we wrote a modest but useful application, and we were hooked.
In the triumvirate of software development, consisting of product managers, designers and developers, only developers are required to turn off their creative mind and engage in regular production. But the developers are not stupid at all; they feel such an attitude very well, and discontent begins to show up in them. Developers want to be part of the overall creative process, and they are deprived of it. And now a completely normal developer turns into a chronic grumbler.
Product managers are usually exceptional people. Their ideas and ability to sense market trends are impressive. But they also have the ability to consider their ideas completely devoid of miscalculations, while in fact they have holes through which a whole train can pass. I say this with great affection, some product managers are my good friends, and, of course, I have repeatedly told them about this in person. I do not in any way criticize them, it is just their essence. They are engaged in creative work, and a rare idea is born ideal. And from this just the developers and become grumblers.
Both developers and product managers often incorrectly believe that the requirements or specification of a product are similar to the finished parts of Ikea furniture. In fact, these documents rarely contain enough information so that you can collect a complete product from them. As a rule, this is just a starting point - and this provides the developer with a unique problem to solve.
In order to understand this problem better, let's consider the task of building a house. Suppose someone decided to build a house on a certain plot of land. The house should have two floors and a garage. We even have a rough outline of the front of the house, drawn on a napkin. And here the client comes to you with all this information and a napkin and asks: “You need this to start construction, right?” And how is it enough for you?
If you talk logically, then proceed to the construction can not be. You do not know the footage, you do not have a floor plan, you can not even imagine what the city demands for the construction of new houses. You do not have enough information even to start digging the ground under the foundation. The only logical solution is to tell the client that he is crazy and must first decide exactly what he needs. Now imagine that you cannot do this, because someone has put a deadline, and you need to have time for it to bleed from the nose.
- Well ... - the client tells you, - let you start building until; and I will, as far as possible, provide you with new information. So we will not waste time.
You know for sure that there is not enough information to build, and further questioning of the client will not give you anything yet. But no one is going to cancel the deadline and you can’t afford to sit on your pants in the hope that the client will be generous with the details. And what is left for you? Make assumptions and assumptions.
The old saying goes: “when you assume, you make an ass of u and me ” (when you make assumptions, make us both idiots), and this is true. Assumptions are dangerous and very often false. And yet without the assumptions run the project will not work. So what are you doing. You start with an assumption, the truth of which you are sure about - that the house will have two floors and a garage. Immediately the question - the garage should be done as an extension or separately? And what size do you need it to do? We will not complicate, let us assume that the garage should be built separately and designed for one car. Now you can work on the garage as a separate building, and then, when the details about the house become known, it can be built next to the garage.
After a week of work on the garage, the client tells you the new details. It turns out that the house should have three floors (phew, it’s good that we haven’t started building the house yet) and eight bathrooms. Information on the garage yet, but the house should be painted in blue. You conclude that the garage should also be blue, and proceed to paint it.
After a few more days the garage is almost finished. You are satisfied with the quality of the result, because you had so little information! You are ready to start building a house when a customer reports new details - the garage should be designed for two cars and attached to the house. You have a tragedy - you have made such a cool garage, and now you have to demolish it in order to build the “right” one. Worse, you now have less time to complete the entire project - and now you start grumbling.
If this analogy seems insane to you, you have obviously never worked as a developer. We see this every first day. We are trying to keep projects afloat, using all our creative forces, but in the end it turns out that we could not read other people's thoughts and wrongly guessed what we were building. But, if we didn’t do this, we’d just wait, wasting time - and, as we know, the cascade design model doesn’t have so many fans.
In almost every industry where something needs to be built, it is expected that all requirements and wishes will be defined and approved before construction begins. But not in software development. When developing software, there is always “not enough time” to collect all the requirements in advance. Day after day, we are told that we need to move forward - that’s why developers have to move a project, learn to fill holes left by product managers. Do not forget that product managers are famous for their love to constantly change their mind, from which developers' assumptions often become wrong halfway.
And someone else is surprised that developers are so quickly "burn out" and change jobs?
The main enemy of any creator is a change of context. As soon as you enter the deep creative mode, the so-called “flow,” any external intervention immediately destroys the whole process. Yes, writing code is also a creative process, both creative and logical. We do not just write the code, we create it.
Among the people involved in the management of developer time, there is a perception that switching from one task to another for them is a trifling matter. They claim that working time is also working time in Africa. You just spend enough of it on the desired task, and, voila - this is the result. Of course it is not. If you are already sitting on the second task for the second day, and you have been transferred to another, then you will not be able to just return to the place where you finished. You will have to spend some time to get into context, such is the price for changing it. Even if another task takes only a couple of minutes, it will already break the “flow” and reduce the developer’s productivity.
This is one of the main problems from which grumble developers - the constant change of priorities. Today we have one main priority, tomorrow another - this leads to an inevitable change of context. Creative people do not like being torn off in the middle of a business, which is why many developers are ready to write with pleasure until the morning, only to complete their work. A change of context makes them less productive.
But the really important priorities never change, they are constant. The frequency with which people around us change their minds terribly enrages the developers. In general, we are constantly in a state of alert and just waiting for us to point to the enemy. But if today you demand from us to build a house, and tomorrow - to convert it into a car, do not be surprised if you feel growing discontent in the ranks.
Developers are constantly put in a difficult position, but at the same time we are not victims, even though the most hysterical of us strive to expose ourselves to them. Part of our grumpiness comes from within, this is due to the reason, wired deep inside most developers. We have a terrible flaw, and it lies in the fact that we overestimate our knowledge and capabilities.
This flaw manifests itself in different ways, but most often when estimating the time for a task. Almost all of my familiar developers chronically underestimate the time they need to spend on this or that task. Only the best of us are able to set a deadline for ourselves and meet it. Most people usually make mistakes twice or even more. This is due to the fact that, like any other creative people, developers often cannot foresee all the problems that they will have to face.
Even though many developers complain that product managers change their minds, almost none of them take this into account when estimating time for a task. No one takes into account the time for meetings, clarification of requirements and possible changes. Bugs? Yes, in our ideal code they cannot be, there is no need to worry here (and if all of a sudden, then testers will find everything, yes?). Are people important to the project going on vacation or getting sick? It's okay, someone will replace them.
All this is a direct path leading to a deadline, but nothing is so much delay the project, as the fact that developers do not take into account the time to study the problem area. This is directly related to our main drawback. We think that we already know everything we need to complete a task, although we often have to work with technologies that we see for the first time in our life. The terms that we define imply ideal knowledge with which we can write software as if according to Ikeev's instructions. In fact, many tasks require us to study in detail their details.
Developers who have graduated from a university in a specialty receive a false sense of security after its completion. They think they are experts in software and the entire development process, when in fact their knowledge is slightly higher than zero. When I went to my first job, I was also a proud graduate, pointing out their mistakes to everyone. Only years later, I realized that I really did not know anything.
Computer colleges do not prepare you for the challenges that await you in the industry. First of all, they give you conceptual knowledge on a wide range of topics so that you will not disgrace yourself when confronted with them during this work. You are taught variables, functions, and objects, since it is with them that you will work most of your time. You are taught databases and queries for them (although normal forms will be useless in practice). You spend abnormally most of the time on learning sorting algorithms and data structures that during professional development will be hidden from you under a layer of abstractions. In short, computer universities consider solving problems that you will never have to solve in practice. If I need to sort something, I'll just call the sort () method. If I need a queue or a related list, I use the native implementation of the language in which I write. All these problems have already been solved for me.
When we graduate from universities, we believe that we can do everything in the world, although in reality we can only do what has already been done before us, and even then only a tiny part of it. But at the same time, we behave like pompous know-it-alls and, considering our knowledge as ideal, we define too short development time, without thinking that we will have to learn something new.
Part of this problem arises because of our such fragile vanity. We are afraid that if we set too long a time frame, then people will question our competence. We are told that “good developers” should work quickly, and we unwillingly agree with this. I have always been amazed at the situations in which the developers initially determine the duration of the project, and then one of their leaders begins to complain that this is too much. Firstly, as I have already noted, the time limit is probably too small. Secondly, the developer should know better than the manager how long it will take to develop, right? And this leads to another problem.
Few words can so much bring the developer out of himself, as "I used to program too." Whoever says it, a product manager, designer, or someone from management, using it as evidence of his innocence leads only to contempt on the part of the developer. If I asked LeBron James (a famous basketball player) how long he practiced before the game, he would be very surprised if I started giving him advice just because I played basketball at school. Developers teach in this way constantly.
Here are just some examples of ignorance, uttered by managers in my presence:
Technically, any problem is solved by adding a couple of lines of code. It does not make it any easier.
Yes, because N already knows her problem area thoroughly. I don't know, I need time to study it.
The increase in the number of developers involved in a problem, as a rule, only aggravates it. The only way to do something faster is to start with smaller problems.
But the worst thing you can do is tell the developers that you once programmed too. Please note that this is not the same as being a professional developer in the past. The developer who became the manager, as a rule, retains some skills during the final period (as a rule, this is five years, then the technology is already completely changed). But for those who have never been involved in professional software development, it’s better to keep your hobby with you than to use it as a proof of your case.
(If in fairness, then designers also suffer from such ignorance. Everyone considers themselves to be design specialists, because everyone likes beautiful things. But this does not make you a professional designer.)
Developers are constantly faced with the problem of "seven nannies in a team." Since we constantly underestimate the real deadlines for completing tasks, most of the software comes out late. Regardless of whether we are talking about large companies or small companies, unknown startups or respected products, they all come out late. Constant lateness grieve managers who, as a rule, decide that the whole problem is a shortage of developers. “So let's select more people,” they say, “this will solve all our problems.”
Sometimes, no doubt, an increase in the number of developers can solve the problem. In most cases, their selection only leads to additional difficulties. Making creative people work in a team is not so easy, but the more they are in a team, the harder it is to do. Developers are not allowed to just sit around idle - as soon as managers decide that they have nothing to do, they immediately come up with a job.
It happened to me in a completely absurd way. We designed a new, from scratch, designed Yahoo homepage design by one small team. It was an ideal project, we designed the basic architecture of the page in a small group, and no one bothered us. We completed the design, and were ready to start developing a prototype, as we identified eight new developers. Moreover, we were instructed that these developers start programming a new page right away. What was that task, because the architecture in the final form did not exist yet! But developers should not be left idle, they were assigned to the project, so they need to be given a task. The classic problem about chicken and egg.
In an ideal situation, we would first finish the prototype architecture, and only later would get additional developers to implement it. In fact, we are stuck. As a result, I decided to use the ready-made architecture from another project, writing a simple interface for it, through which it was possible to access it as a new one. The developers were able to begin their work, and we were able to continue developing the architecture. This was a terrible solution to a terrible problem, which eventually stopped working when developers got to that part of the interface that was not yet implemented. As a result, I had to tell our manager that if we are not given time to finish the new architecture, then our neat house of cards will quickly fall apart.
Too many developers in a team can make a project very difficult. Of course, they can work on tasks that are independent of each other, but, as a rule, the number of such tasks in any project is not so large. The more developers are involved in the project, the more time is spent not on developing, but on planning and organizing teamwork. If you go back to the metaphor of building a house, you cannot build a second floor before you build the first. Most software development tasks are performed strictly in turn, so allocating an additional number of developers will not speed up the development process. As one of my former colleagues said, no matter how many women you have, you will not be able to give birth to a child before nine months (in fact, the famous quote from Fred Brooks’s Mythical Man-Month) .
So, every day we have to deal with a lack of information, changing requirements, a lack of understanding of the problem area and colleagues guessing our thoughts. As creative people, we put up with all of this only because the result of our work will be used by living people. Here is the main motivator of developers - the idea that the lives of people whom we do not even know will change thanks to our efforts, regardless of whether we are working on the site with a million visits per day or a sales system for a restaurant chain.
When the release is delayed because someone again changed his mind, we turn into creepy grumblers. Mad grumblers. Our dream, to bring the result of our efforts to the end user, again prevented to come true - there is no worse demotivator. Surprisingly, developers are rarely perfectionists. We agree that the best is the enemy of the good, and we are ready to lay out our work gradually, in order to later merge it into one big whole. Why?Because the only way to put our work on time to people.
No, we understand that delays are an integral part of the software development process. Developers are ready to work for the ten, just to be in time for their deadlines. We are ready to work twelve hours a day, let it only lead to a normal result.
Working as developers, we get used to the work mode that is radically different from the modes of other employees. When something breaks on the server or in the assembly, in the middle of the night they wake up not the designer with the manager, but the developer (although I am familiar with managers who demand that they also be woken up). Once I got a call right when I was going to go on a date with a girl. My couple sat and waited patiently for an hour, while I unsuccessfully tried to fix the problem. In the end, she left (I can not blame her), leaving me to suffer alone with work and colleagues in the IRC client.
In this case, few developers strongly complained about the long working day or the fact that he was woken at night because of the next bug. Our project is for us as a child, and we are ready to care for and care for him. If you need to feed him at two in the morning, there is no problem. If on the weekend he needs to be given time, we will always find him, while smiling, looking at how our creation grows.
Developers are especially pleased when they are given the opportunity to complete the task themselves. Nothing can compare for them with the pleasure of sending a letter that the task is completed and is ready to pass a review. But their joy disappears immediately, when 10 minutes after the commit, they begin to write down bugs on their newly created offspring.
Imagine yourself in their place. You spent the whole day (or week (or month)) on the task and coped with it. You are overwhelmed by a sense of pride in your work, which may have required knowledge from you that you didn’t have before. All you want is to sit back and admire your achievements. Even better, if someone praises you for the work done. And what do you get? Bug reports. It does not work, it does not work, etc. We have to get upset to work on the bugs.
Summarizing the above, let's highlight the main reasons why developers say no (or just grumble):
Keep in mind that each of these problems, with the exception of the first, is related to working conditions in a short time. We want to complete all tasks by deadline - and how to do this when they are constantly changing during our work? When this happens, there is no limit to our dissatisfaction (and grumbling), and “no” flies out before you finish the sentence.
So how can managers deal with this grumpiness in practice? Let's once again remember what drives the developers:
And now think what is not in this list. Of money. Increased cash rewards rarely satisfy developers. It sounds like a trite stamp, but for developers, it's really not about the money. Money gives them the opportunity to live in their own pleasure, but in the soul they are primarily interested in the development process itself. And most often, the main thing that they need is the opportunity to deal with them in normal working conditions.
So how to create a normal working environment for developers?
Developers are just as creative as product managers with designers, so care must be taken to incorporate them into the creative process. There are no equal developers during brainstorming and discussion meetings. Give developers the opportunity to meet with the project team and work directly with them (but not necessarily all at once). In other words, include developers in the creative process as early as possible. No one likes being thrown into it without explanations with documents with specifications.
Developers are logical to the limit, so their presence at early meetings will help them understand what the requirements are based on and solve many problems even before they appear. When developers are treated like builders, they constantly ask questions, and this slows down the development process. When developers are treated like colleagues in the creative department, they have fewer questions and the development moves faster.
It is also important that developers often know better what can and cannot be done. For example, front-end developers will learn about what can be implemented in the browser long before the rest. By sharing this knowledge with the rest, we can provoke the birth of new ideas on how to improve the product, based on our capabilities. Imagine that you are inventing a site for uploading photos and do not know that they can be thrown directly from the desktop to the browser? How would this affect its design?
So let developers participate in the creative process right from the start of the project. Listen to their opinion about the project and what is technically possible to implement. The less it seems to us that we are told what to do, the more we listen to the opinions of others and do our work better. The only way to achieve this is to let us participate in the creative work on the project.
Let's think of the developers as creators. Try to give us all the opportunities so that we show our creative abilities. Hakdey and hakotons are popular not by chance - they are popular because they allow developers to revive their love for code and development in creative ways. On hakotonah developers completely devote themselves to creativity, free from the limitations of their normal work.
One hakodeya once a quarter is enough to bring joy to developers. Want more?Arrange thematic Hakodey. Give out prizes to the most creative and practical solutions, etc. The main task is to give developers to create, so that they, returning to normal work, feel the strength to continue to develop and improve your projects.
Keep in mind that this applies not only to developers. From time to time, they want to do creative work. But in my experience, product managers and designers have more options for this. Various trainings and conferences are regularly arranged for managers and designers, and developers are often forgotten.
By the way, hakotons are not the only way to create a creative atmosphere, but as a first step it is the easiest to do. You can also wake up a creative streak from developers by sending them to conferences, allowing them to buy books at the company's expense, allowing them to share ideas about the projects they are working on. Everyone knows, for example, that Google gives developers 20% of their time to developing their own projects. All this can lead to the beginning of a long and long-lasting friendship with your developers.
Given the number of hours of mental effort that we regularly spend while working, it becomes clear that developers need to remember to take a break. Unfortunately, we rarely achieve much success in planning our time. It happens that we are so immersed in work that we forget about vacation. For the first five years of my career, I took in total, it seems, seven days of vacation. I do not know why, but we are poorly able to relieve our stress - and this is a big problem.
Burnout of developers is unique in the sense that we are used to working in this state. But it is worth the burnout to reach its peak, and we quit and go to look for another job. Moreover, almost no developer will ever tell you that they have no strength to endure; they have too much pride for that. In my last team, I told all the developers that they immediately came to me as soon as they felt that everything was enough for them. I did not want them to endure until the only way out for them was dismissal. I needed them to not quit and enjoy the work, and the only way to achieve this is to understand when they will start to burn out.
Encourage developers to take vacations. Your company provides a certain time for vacation - so make sure that developers take it at least once every 4-5 months. Best of all, if it takes the managers who follow the project schedule.
Regular vacation during the holidays gives developers the opportunity to restore their creative powers, saving them from constantly hanging deadlines. Yes, during the holidays we will probably also be engaged in development, but we will deal exclusively with our projects, and not with the workers. Such work will help us gain energy and prepare for new battles.
No matter how ironic it may sound, but many companies hire developers, and then do not let them develop. Instead, their days are filled with useless meetings that undermine productivity. In general, developers are most effective when they can sit on the code for at least four hours without being distracted.
Entering a good “stream” during programming is always difficult when you know that you need to be in a meeting in a couple of hours. For the development process, there is nothing more unproductive than the process during which you first write the code for an hour, then interrupt for an hour, then write the code again for an hour, interrupt for another hour, and so on. The developer’s brain takes some time to switch to the “correct” state for programming.
Try to make sure that developers have at least four hours a day for uninterrupted programming. This is the only way to speed up development. It is quite logical: if people work eight hours a day, then at least half of this time they should spend on their main tasks. For example, I found out that for me the most productive period is the time between one and five in the afternoon. If I could work at this time every day, I would easily cope with all my tasks. In the days when this time is interrupted by meetings, I understand that I will not be able to do much today.
And at least one day a week do absolutely no meetings, including daily fly-ins. Let the developers have one day in which they can independently distribute their time and deal with all matters. You will not believe how much you can do in a day, completely free from distractions. At one time, my manager even demanded that I work from home at least two days a week, because in the office I was constantly distracted. As a result, I worked at an incredible speed.
Something can be done right now, while achieving significant results. I already mentioned above about how furious when you just finished the task, and you already started to write bugs to it. Developers rarely have a chance to sit back in their chairs and admire the work done, not to mention the words of gratitude.
A small letter of thanks to a developer who has just completed a task can achieve incredible success, especially if the task was complex. Even if you just say: “Listen, thanks for the work, I’ll definitely look,” this will be enough to remove the sullen mood that arises when the first stream of bugs appears. Developers are very important to their work appreciated, because most of the feedback they receive are negative - bugs, problems, etc. A couple of kind words, and all this no longer seems so scary.
It will be great if you assign something like a reward that will be given out each quarter to a developer who has made the most efforts, implemented the most improvements, etc. The reward does not have to be something expensive and desirable like an iPad (although we gratefully accept it), it can be just a small gift and a letter recognizing the merits of the whole team or department.
And please, when you thank people for the work done, never forget about the developers. I attended countless project meetings, where everyone admired the work of managers or designers, while completely forgetting about the developers whose sweat, blood and tears brought the project to life. The success of each project depends on the efforts of each of the three groups; no group alone can fulfill it. Make sure your company recognizes the efforts of the whole team, and not one of its parts.
We, the developers, as a rule, are outstanding people. We are all definitely individuals, and we really want to achieve the best possible result possible. If you stop treating us like errand boys and start respecting us as part of the creative process, then you will achieve excellent results in a short time. In the teams in which I worked, there were always some friction caused by a lack of understanding of the way of thinking and motivation of developers. I sincerely hope that this article will help improve the interaction between developers and their colleagues. This is not so difficult - we just need to feel part of a common solution, and not an ordinary working bee.
The author of the original article is Nickolas C. Zakas, a well-known frontend developer and JavaScript evangelist who worked for more than five years at Yahoo. This is a post from his blog , in which he talks about why it is so difficult to agree with the developers and what to do about it.
Not so long ago, Jenna Baylotta wrote a wonderful article, “How designers can get along with developers,” in which she describes the methods of working in a team that allow designers and developers to achieve better performance. I once worked with designers (and, working in the UI, and with developers) and faced with similar problems, so I understand its practical approach. During teamwork, it never hurts to respect the work of your colleagues and to understand their way of thinking.
')
One of the main thoughts of this article was that developers say “no” too quickly. This thought immediately entered my brain and for a long time refused to get out of it. I wanted to exclaim: “But wait, you do not understand why we say no!”. A million other defensive arguments appeared immediately. In fact, of course, she is right - we really say “no” too quickly, and not only to designers, but to everyone in general. This prompted me to reflect on the psychology of the developers and what constitutes our true essence.
Our reputation
Let's be honest with us, the developers, the reputation of such proud debaters with regular mood swings. We constantly say “no”, clarify the details to indecent pedantry and believe that we can do the work of any of our non-technical colleagues much better than themselves. And, what is already there, this stereotype largely corresponds to the truth - that is what we are doing day after day, in the intervals between writing code and reading Twitter from Hacker News.
(Note: Some of you will say that not all developers are such, and they will be right. There is a small percentage of developers who cannot be included in the above category. Do not rush to scroll down and write in comments that the author is an idiot, read on .)
Nobody gives out a reputation just like that, they earn it. What surprises me about this reputation is the fact that I personally know a bunch of developers, and, as a rule, they are benevolent, pleasant (if you don’t stubborn with them) and just funny guys. You can have a great time with them after work or on weekends. So why at work do they become completely different people?
We are creators, not builders
I have a theory. It lies in the fact that developers see themselves quite differently from their colleagues. I came to this conclusion for more than ten years of work in large and small software development companies. Employees of such companies (product managers, designers, other managers) usually look at developers as simple builders. The product manager should come up with an original idea, the designer should express it in a beautiful form, and the developer should only bring these ideas to life. In fact, engineers are looked at as errand boys, doing exactly that and only what they were told.
My first manager warned me about this. When the first company in which I worked collapsed, we had a very frank conversation about my future career. Although we didn’t always get along, he gave me great advice then (further inaccurate quotation):
Nicholas, you are worth more than the code you write. Wherever you work further, never let anyone treat you like an errand boy. Do not agree to work if you were told exactly what needs to be done and how. You need to work where you appreciate not only the fact that you can make a product, but also how you can improve it.
He was completely right. There are many companies that need errand boys, they need builders who will write code in a well-defined pattern without the right to take a step aside. I would even say that these are the majority of companies, both large and small. I have long lost count of how many founders of startups offered me a share in the company in exchange for the realization of their author's vision. All of them proceed from the assumption that they already have ideas, they only need someone who brings them to life.
And here the main root of the problem is buried - the developers are not really obedient builders. Developers - creators. You yourself, in a sense, are engaged in assembling each time you assemble furniture from Ikea. You have all the instructions in your hand, and if you follow them step by step, you will assemble that ridiculously small table that you wanted. Creativity is a completely different job, it is the creation of something without specific directions or instructions. You start with a blank canvas, and end with a work of art. Developers are so fond of programming, not because they want to execute someone's instructions, but because they understand that they can do various interesting things with it. We all fell in love with the development process, because once we wrote a modest but useful application, and we were hooked.
In the triumvirate of software development, consisting of product managers, designers and developers, only developers are required to turn off their creative mind and engage in regular production. But the developers are not stupid at all; they feel such an attitude very well, and discontent begins to show up in them. Developers want to be part of the overall creative process, and they are deprived of it. And now a completely normal developer turns into a chronic grumbler.
Hey, what's the problem?
Product managers are usually exceptional people. Their ideas and ability to sense market trends are impressive. But they also have the ability to consider their ideas completely devoid of miscalculations, while in fact they have holes through which a whole train can pass. I say this with great affection, some product managers are my good friends, and, of course, I have repeatedly told them about this in person. I do not in any way criticize them, it is just their essence. They are engaged in creative work, and a rare idea is born ideal. And from this just the developers and become grumblers.
Both developers and product managers often incorrectly believe that the requirements or specification of a product are similar to the finished parts of Ikea furniture. In fact, these documents rarely contain enough information so that you can collect a complete product from them. As a rule, this is just a starting point - and this provides the developer with a unique problem to solve.
In order to understand this problem better, let's consider the task of building a house. Suppose someone decided to build a house on a certain plot of land. The house should have two floors and a garage. We even have a rough outline of the front of the house, drawn on a napkin. And here the client comes to you with all this information and a napkin and asks: “You need this to start construction, right?” And how is it enough for you?
If you talk logically, then proceed to the construction can not be. You do not know the footage, you do not have a floor plan, you can not even imagine what the city demands for the construction of new houses. You do not have enough information even to start digging the ground under the foundation. The only logical solution is to tell the client that he is crazy and must first decide exactly what he needs. Now imagine that you cannot do this, because someone has put a deadline, and you need to have time for it to bleed from the nose.
- Well ... - the client tells you, - let you start building until; and I will, as far as possible, provide you with new information. So we will not waste time.
You know for sure that there is not enough information to build, and further questioning of the client will not give you anything yet. But no one is going to cancel the deadline and you can’t afford to sit on your pants in the hope that the client will be generous with the details. And what is left for you? Make assumptions and assumptions.
The old saying goes: “when you assume, you make an ass of u and me ” (when you make assumptions, make us both idiots), and this is true. Assumptions are dangerous and very often false. And yet without the assumptions run the project will not work. So what are you doing. You start with an assumption, the truth of which you are sure about - that the house will have two floors and a garage. Immediately the question - the garage should be done as an extension or separately? And what size do you need it to do? We will not complicate, let us assume that the garage should be built separately and designed for one car. Now you can work on the garage as a separate building, and then, when the details about the house become known, it can be built next to the garage.
After a week of work on the garage, the client tells you the new details. It turns out that the house should have three floors (phew, it’s good that we haven’t started building the house yet) and eight bathrooms. Information on the garage yet, but the house should be painted in blue. You conclude that the garage should also be blue, and proceed to paint it.
After a few more days the garage is almost finished. You are satisfied with the quality of the result, because you had so little information! You are ready to start building a house when a customer reports new details - the garage should be designed for two cars and attached to the house. You have a tragedy - you have made such a cool garage, and now you have to demolish it in order to build the “right” one. Worse, you now have less time to complete the entire project - and now you start grumbling.
If this analogy seems insane to you, you have obviously never worked as a developer. We see this every first day. We are trying to keep projects afloat, using all our creative forces, but in the end it turns out that we could not read other people's thoughts and wrongly guessed what we were building. But, if we didn’t do this, we’d just wait, wasting time - and, as we know, the cascade design model doesn’t have so many fans.
In almost every industry where something needs to be built, it is expected that all requirements and wishes will be defined and approved before construction begins. But not in software development. When developing software, there is always “not enough time” to collect all the requirements in advance. Day after day, we are told that we need to move forward - that’s why developers have to move a project, learn to fill holes left by product managers. Do not forget that product managers are famous for their love to constantly change their mind, from which developers' assumptions often become wrong halfway.
And someone else is surprised that developers are so quickly "burn out" and change jobs?
Top Priorities
The main enemy of any creator is a change of context. As soon as you enter the deep creative mode, the so-called “flow,” any external intervention immediately destroys the whole process. Yes, writing code is also a creative process, both creative and logical. We do not just write the code, we create it.
Among the people involved in the management of developer time, there is a perception that switching from one task to another for them is a trifling matter. They claim that working time is also working time in Africa. You just spend enough of it on the desired task, and, voila - this is the result. Of course it is not. If you are already sitting on the second task for the second day, and you have been transferred to another, then you will not be able to just return to the place where you finished. You will have to spend some time to get into context, such is the price for changing it. Even if another task takes only a couple of minutes, it will already break the “flow” and reduce the developer’s productivity.
This is one of the main problems from which grumble developers - the constant change of priorities. Today we have one main priority, tomorrow another - this leads to an inevitable change of context. Creative people do not like being torn off in the middle of a business, which is why many developers are ready to write with pleasure until the morning, only to complete their work. A change of context makes them less productive.
But the really important priorities never change, they are constant. The frequency with which people around us change their minds terribly enrages the developers. In general, we are constantly in a state of alert and just waiting for us to point to the enemy. But if today you demand from us to build a house, and tomorrow - to convert it into a car, do not be surprised if you feel growing discontent in the ranks.
A terrible flaw developers
Developers are constantly put in a difficult position, but at the same time we are not victims, even though the most hysterical of us strive to expose ourselves to them. Part of our grumpiness comes from within, this is due to the reason, wired deep inside most developers. We have a terrible flaw, and it lies in the fact that we overestimate our knowledge and capabilities.
This flaw manifests itself in different ways, but most often when estimating the time for a task. Almost all of my familiar developers chronically underestimate the time they need to spend on this or that task. Only the best of us are able to set a deadline for ourselves and meet it. Most people usually make mistakes twice or even more. This is due to the fact that, like any other creative people, developers often cannot foresee all the problems that they will have to face.
Even though many developers complain that product managers change their minds, almost none of them take this into account when estimating time for a task. No one takes into account the time for meetings, clarification of requirements and possible changes. Bugs? Yes, in our ideal code they cannot be, there is no need to worry here (and if all of a sudden, then testers will find everything, yes?). Are people important to the project going on vacation or getting sick? It's okay, someone will replace them.
All this is a direct path leading to a deadline, but nothing is so much delay the project, as the fact that developers do not take into account the time to study the problem area. This is directly related to our main drawback. We think that we already know everything we need to complete a task, although we often have to work with technologies that we see for the first time in our life. The terms that we define imply ideal knowledge with which we can write software as if according to Ikeev's instructions. In fact, many tasks require us to study in detail their details.
Developers who have graduated from a university in a specialty receive a false sense of security after its completion. They think they are experts in software and the entire development process, when in fact their knowledge is slightly higher than zero. When I went to my first job, I was also a proud graduate, pointing out their mistakes to everyone. Only years later, I realized that I really did not know anything.
Computer colleges do not prepare you for the challenges that await you in the industry. First of all, they give you conceptual knowledge on a wide range of topics so that you will not disgrace yourself when confronted with them during this work. You are taught variables, functions, and objects, since it is with them that you will work most of your time. You are taught databases and queries for them (although normal forms will be useless in practice). You spend abnormally most of the time on learning sorting algorithms and data structures that during professional development will be hidden from you under a layer of abstractions. In short, computer universities consider solving problems that you will never have to solve in practice. If I need to sort something, I'll just call the sort () method. If I need a queue or a related list, I use the native implementation of the language in which I write. All these problems have already been solved for me.
When we graduate from universities, we believe that we can do everything in the world, although in reality we can only do what has already been done before us, and even then only a tiny part of it. But at the same time, we behave like pompous know-it-alls and, considering our knowledge as ideal, we define too short development time, without thinking that we will have to learn something new.
Part of this problem arises because of our such fragile vanity. We are afraid that if we set too long a time frame, then people will question our competence. We are told that “good developers” should work quickly, and we unwillingly agree with this. I have always been amazed at the situations in which the developers initially determine the duration of the project, and then one of their leaders begins to complain that this is too much. Firstly, as I have already noted, the time limit is probably too small. Secondly, the developer should know better than the manager how long it will take to develop, right? And this leads to another problem.
I used to program too
Few words can so much bring the developer out of himself, as "I used to program too." Whoever says it, a product manager, designer, or someone from management, using it as evidence of his innocence leads only to contempt on the part of the developer. If I asked LeBron James (a famous basketball player) how long he practiced before the game, he would be very surprised if I started giving him advice just because I played basketball at school. Developers teach in this way constantly.
Here are just some examples of ignorance, uttered by managers in my presence:
I do not understand, is it such a big problem? There’s just a couple of lines of code to add.
Technically, any problem is solved by adding a couple of lines of code. It does not make it any easier.
N says that a couple of days will be enough for this task.
Yes, because N already knows her problem area thoroughly. I don't know, I need time to study it.
What can we do to speed up the process? Select more developers?
The increase in the number of developers involved in a problem, as a rule, only aggravates it. The only way to do something faster is to start with smaller problems.
But the worst thing you can do is tell the developers that you once programmed too. Please note that this is not the same as being a professional developer in the past. The developer who became the manager, as a rule, retains some skills during the final period (as a rule, this is five years, then the technology is already completely changed). But for those who have never been involved in professional software development, it’s better to keep your hobby with you than to use it as a proof of your case.
(If in fairness, then designers also suffer from such ignorance. Everyone considers themselves to be design specialists, because everyone likes beautiful things. But this does not make you a professional designer.)
More nannies
Developers are constantly faced with the problem of "seven nannies in a team." Since we constantly underestimate the real deadlines for completing tasks, most of the software comes out late. Regardless of whether we are talking about large companies or small companies, unknown startups or respected products, they all come out late. Constant lateness grieve managers who, as a rule, decide that the whole problem is a shortage of developers. “So let's select more people,” they say, “this will solve all our problems.”
Sometimes, no doubt, an increase in the number of developers can solve the problem. In most cases, their selection only leads to additional difficulties. Making creative people work in a team is not so easy, but the more they are in a team, the harder it is to do. Developers are not allowed to just sit around idle - as soon as managers decide that they have nothing to do, they immediately come up with a job.
It happened to me in a completely absurd way. We designed a new, from scratch, designed Yahoo homepage design by one small team. It was an ideal project, we designed the basic architecture of the page in a small group, and no one bothered us. We completed the design, and were ready to start developing a prototype, as we identified eight new developers. Moreover, we were instructed that these developers start programming a new page right away. What was that task, because the architecture in the final form did not exist yet! But developers should not be left idle, they were assigned to the project, so they need to be given a task. The classic problem about chicken and egg.
In an ideal situation, we would first finish the prototype architecture, and only later would get additional developers to implement it. In fact, we are stuck. As a result, I decided to use the ready-made architecture from another project, writing a simple interface for it, through which it was possible to access it as a new one. The developers were able to begin their work, and we were able to continue developing the architecture. This was a terrible solution to a terrible problem, which eventually stopped working when developers got to that part of the interface that was not yet implemented. As a result, I had to tell our manager that if we are not given time to finish the new architecture, then our neat house of cards will quickly fall apart.
Too many developers in a team can make a project very difficult. Of course, they can work on tasks that are independent of each other, but, as a rule, the number of such tasks in any project is not so large. The more developers are involved in the project, the more time is spent not on developing, but on planning and organizing teamwork. If you go back to the metaphor of building a house, you cannot build a second floor before you build the first. Most software development tasks are performed strictly in turn, so allocating an additional number of developers will not speed up the development process. As one of my former colleagues said, no matter how many women you have, you will not be able to give birth to a child before nine months (in fact, the famous quote from Fred Brooks’s Mythical Man-Month) .
Big grunts
So, every day we have to deal with a lack of information, changing requirements, a lack of understanding of the problem area and colleagues guessing our thoughts. As creative people, we put up with all of this only because the result of our work will be used by living people. Here is the main motivator of developers - the idea that the lives of people whom we do not even know will change thanks to our efforts, regardless of whether we are working on the site with a million visits per day or a sales system for a restaurant chain.
I repeat once again - the developers "burn out" not because the work is hard, but because the instructions are constantly changing, and the release date is delayed.
When the release is delayed because someone again changed his mind, we turn into creepy grumblers. Mad grumblers. Our dream, to bring the result of our efforts to the end user, again prevented to come true - there is no worse demotivator. Surprisingly, developers are rarely perfectionists. We agree that the best is the enemy of the good, and we are ready to lay out our work gradually, in order to later merge it into one big whole. Why?Because the only way to put our work on time to people.
No, we understand that delays are an integral part of the software development process. Developers are ready to work for the ten, just to be in time for their deadlines. We are ready to work twelve hours a day, let it only lead to a normal result.
Say thanks? What more
Working as developers, we get used to the work mode that is radically different from the modes of other employees. When something breaks on the server or in the assembly, in the middle of the night they wake up not the designer with the manager, but the developer (although I am familiar with managers who demand that they also be woken up). Once I got a call right when I was going to go on a date with a girl. My couple sat and waited patiently for an hour, while I unsuccessfully tried to fix the problem. In the end, she left (I can not blame her), leaving me to suffer alone with work and colleagues in the IRC client.
In this case, few developers strongly complained about the long working day or the fact that he was woken at night because of the next bug. Our project is for us as a child, and we are ready to care for and care for him. If you need to feed him at two in the morning, there is no problem. If on the weekend he needs to be given time, we will always find him, while smiling, looking at how our creation grows.
Developers are especially pleased when they are given the opportunity to complete the task themselves. Nothing can compare for them with the pleasure of sending a letter that the task is completed and is ready to pass a review. But their joy disappears immediately, when 10 minutes after the commit, they begin to write down bugs on their newly created offspring.
Imagine yourself in their place. You spent the whole day (or week (or month)) on the task and coped with it. You are overwhelmed by a sense of pride in your work, which may have required knowledge from you that you didn’t have before. All you want is to sit back and admire your achievements. Even better, if someone praises you for the work done. And what do you get? Bug reports. It does not work, it does not work, etc. We have to get upset to work on the bugs.
Why do we say no.
Summarizing the above, let's highlight the main reasons why developers say no (or just grumble):
- A new requirement appeared at the very end of development, and there is no time to implement it at all;
- The new requirement contradicts the assumptions we made earlier in order not to slow down the project;
- The new requirement completely contradicts the previous one;
- A new requirement in another way increases the amount of work that needs to be done, meeting the deadlines;
- We are so tired that any new requirement seems incredibly difficult to implement, and we absolutely do not want to fulfill it.
Keep in mind that each of these problems, with the exception of the first, is related to working conditions in a short time. We want to complete all tasks by deadline - and how to do this when they are constantly changing during our work? When this happens, there is no limit to our dissatisfaction (and grumbling), and “no” flies out before you finish the sentence.
Feeding and care
So how can managers deal with this grumpiness in practice? Let's once again remember what drives the developers:
- Desire to create;
- The desire to solve problems;
- The desire to see the result of our work in business.
And now think what is not in this list. Of money. Increased cash rewards rarely satisfy developers. It sounds like a trite stamp, but for developers, it's really not about the money. Money gives them the opportunity to live in their own pleasure, but in the soul they are primarily interested in the development process itself. And most often, the main thing that they need is the opportunity to deal with them in normal working conditions.
So how to create a normal working environment for developers?
Work with them
Developers are just as creative as product managers with designers, so care must be taken to incorporate them into the creative process. There are no equal developers during brainstorming and discussion meetings. Give developers the opportunity to meet with the project team and work directly with them (but not necessarily all at once). In other words, include developers in the creative process as early as possible. No one likes being thrown into it without explanations with documents with specifications.
Developers are logical to the limit, so their presence at early meetings will help them understand what the requirements are based on and solve many problems even before they appear. When developers are treated like builders, they constantly ask questions, and this slows down the development process. When developers are treated like colleagues in the creative department, they have fewer questions and the development moves faster.
It is also important that developers often know better what can and cannot be done. For example, front-end developers will learn about what can be implemented in the browser long before the rest. By sharing this knowledge with the rest, we can provoke the birth of new ideas on how to improve the product, based on our capabilities. Imagine that you are inventing a site for uploading photos and do not know that they can be thrown directly from the desktop to the browser? How would this affect its design?
So let developers participate in the creative process right from the start of the project. Listen to their opinion about the project and what is technically possible to implement. The less it seems to us that we are told what to do, the more we listen to the opinions of others and do our work better. The only way to achieve this is to let us participate in the creative work on the project.
Create a creative atmosphere
Let's think of the developers as creators. Try to give us all the opportunities so that we show our creative abilities. Hakdey and hakotons are popular not by chance - they are popular because they allow developers to revive their love for code and development in creative ways. On hakotonah developers completely devote themselves to creativity, free from the limitations of their normal work.
One hakodeya once a quarter is enough to bring joy to developers. Want more?Arrange thematic Hakodey. Give out prizes to the most creative and practical solutions, etc. The main task is to give developers to create, so that they, returning to normal work, feel the strength to continue to develop and improve your projects.
Keep in mind that this applies not only to developers. From time to time, they want to do creative work. But in my experience, product managers and designers have more options for this. Various trainings and conferences are regularly arranged for managers and designers, and developers are often forgotten.
By the way, hakotons are not the only way to create a creative atmosphere, but as a first step it is the easiest to do. You can also wake up a creative streak from developers by sending them to conferences, allowing them to buy books at the company's expense, allowing them to share ideas about the projects they are working on. Everyone knows, for example, that Google gives developers 20% of their time to developing their own projects. All this can lead to the beginning of a long and long-lasting friendship with your developers.
Encourage rest
Given the number of hours of mental effort that we regularly spend while working, it becomes clear that developers need to remember to take a break. Unfortunately, we rarely achieve much success in planning our time. It happens that we are so immersed in work that we forget about vacation. For the first five years of my career, I took in total, it seems, seven days of vacation. I do not know why, but we are poorly able to relieve our stress - and this is a big problem.
Burnout of developers is unique in the sense that we are used to working in this state. But it is worth the burnout to reach its peak, and we quit and go to look for another job. Moreover, almost no developer will ever tell you that they have no strength to endure; they have too much pride for that. In my last team, I told all the developers that they immediately came to me as soon as they felt that everything was enough for them. I did not want them to endure until the only way out for them was dismissal. I needed them to not quit and enjoy the work, and the only way to achieve this is to understand when they will start to burn out.
Encourage developers to take vacations. Your company provides a certain time for vacation - so make sure that developers take it at least once every 4-5 months. Best of all, if it takes the managers who follow the project schedule.
Regular vacation during the holidays gives developers the opportunity to restore their creative powers, saving them from constantly hanging deadlines. Yes, during the holidays we will probably also be engaged in development, but we will deal exclusively with our projects, and not with the workers. Such work will help us gain energy and prepare for new battles.
Let them develop
No matter how ironic it may sound, but many companies hire developers, and then do not let them develop. Instead, their days are filled with useless meetings that undermine productivity. In general, developers are most effective when they can sit on the code for at least four hours without being distracted.
Entering a good “stream” during programming is always difficult when you know that you need to be in a meeting in a couple of hours. For the development process, there is nothing more unproductive than the process during which you first write the code for an hour, then interrupt for an hour, then write the code again for an hour, interrupt for another hour, and so on. The developer’s brain takes some time to switch to the “correct” state for programming.
Try to make sure that developers have at least four hours a day for uninterrupted programming. This is the only way to speed up development. It is quite logical: if people work eight hours a day, then at least half of this time they should spend on their main tasks. For example, I found out that for me the most productive period is the time between one and five in the afternoon. If I could work at this time every day, I would easily cope with all my tasks. In the days when this time is interrupted by meetings, I understand that I will not be able to do much today.
And at least one day a week do absolutely no meetings, including daily fly-ins. Let the developers have one day in which they can independently distribute their time and deal with all matters. You will not believe how much you can do in a day, completely free from distractions. At one time, my manager even demanded that I work from home at least two days a week, because in the office I was constantly distracted. As a result, I worked at an incredible speed.
Give thanks
Something can be done right now, while achieving significant results. I already mentioned above about how furious when you just finished the task, and you already started to write bugs to it. Developers rarely have a chance to sit back in their chairs and admire the work done, not to mention the words of gratitude.
A small letter of thanks to a developer who has just completed a task can achieve incredible success, especially if the task was complex. Even if you just say: “Listen, thanks for the work, I’ll definitely look,” this will be enough to remove the sullen mood that arises when the first stream of bugs appears. Developers are very important to their work appreciated, because most of the feedback they receive are negative - bugs, problems, etc. A couple of kind words, and all this no longer seems so scary.
It will be great if you assign something like a reward that will be given out each quarter to a developer who has made the most efforts, implemented the most improvements, etc. The reward does not have to be something expensive and desirable like an iPad (although we gratefully accept it), it can be just a small gift and a letter recognizing the merits of the whole team or department.
And please, when you thank people for the work done, never forget about the developers. I attended countless project meetings, where everyone admired the work of managers or designers, while completely forgetting about the developers whose sweat, blood and tears brought the project to life. The success of each project depends on the efforts of each of the three groups; no group alone can fulfill it. Make sure your company recognizes the efforts of the whole team, and not one of its parts.
Conclusion
We, the developers, as a rule, are outstanding people. We are all definitely individuals, and we really want to achieve the best possible result possible. If you stop treating us like errand boys and start respecting us as part of the creative process, then you will achieve excellent results in a short time. In the teams in which I worked, there were always some friction caused by a lack of understanding of the way of thinking and motivation of developers. I sincerely hope that this article will help improve the interaction between developers and their colleagues. This is not so difficult - we just need to feel part of a common solution, and not an ordinary working bee.
Source: https://habr.com/ru/post/146169/
All Articles