Geekly Articles each Day
⬆️ ⬇️

Problem personalities among developers





In the desert, skilled talents like water are demanded by software developers, let them be carried or insulted, but this is a fact. Without them, there will be no industry, and they themselves are well aware of it. This leads to such a fascinating sense of personal right, which is rarely seen in the history of mankind. As a result, a whole spectrum of very bright problem individuals appeared.



A good developer can be worth its weight in gold - literally . In the few professions such incomes are possible. Some of the richest people on the planet used to be programmers, so being a developer at the right time at the right place is one of the easiest and most direct ways to great wealth.

')

But with such opportunities there often comes a complete lack of respect for project participants from other professions. This lack of respect can be so deep that it creates in the developer’s mind a firm belief that he is not only the most valuable participant in a software project, but also necessary for the company as a whole. Unfortunately, although only a small number of developers are capable of accumulating anything resembling wealth, many behave as if they are following Mark Zuckerberg, Bill Gates or Steve Jobs; although it is very far from the truth. This leads to personal problems that are just as fascinating to watch from the side, as it is terrible to contemplate in yourself.



The following are problematic identities among software developers:





Diva



The developer is so convinced that he is indispensable that he becomes arrogant and impossible to lead.




Problem



At a certain level, to manage an employee, he must do what you say. A prima donna cannot be controlled, because in its essence it does not believe that it works for you. In his opinion, it is your privilege to work with him. He considers himself completely indispensable and right in any discussion.



Contrary to her own conviction, a prima donna is not necessarily a skilled developer (see type rock star ). His arrogance is based on the presentation of his place in the organization, and not on actual technical skills. As a result, prima donnas too often assess their skill level much higher than that of their colleagues, although in reality this is not the case . This usually leads to the fact that a diva is usually not loved by colleagues.



You can define a prima donna using typical phrases:





Diva rejects leadership. He regards any attempt at leadership as an insult, since he is superior to being responsible for his actions. Such a personal problem usually occurs among long-time developers who are deeply involved in the early success of companies. Now, years later, thanks to his longstanding relations with the company's founders, he considers his opinion above the opinion of a simple middle manager.



The prima donna does not represent a material danger for the project, as it usually does nothing, but only shakes its rights. However, it negatively affects the morale of the team, especially for newer, more productive developers. Therefore, it must be put in place so that the project runs smoothly.



Decision



The solution for the prima donna is to refute the basic belief: that it is irreplaceable and therefore can do whatever it wants . The most direct way to refute this belief is to hire a replacement for working closely with him. In order to adequately convey to the prima donna that this is indeed his replacement, two conditions must be met:





The faster the replacement gathers all the knowledge of the Legacy code that a prima donna can have (see the types of developers, the keeper of the Legacy code and the hostage taker ), the faster the prima donna will return under control. The effect can be dramatic: things can change in just a few days. The shape of the prima donna begins to perform an additional function to its replacement. Ultimately, he is no longer indispensable, and therefore no longer a prima donna, but simply a bad employee.



The only hope of a prima donna to maintain a sense of status is to get promoted to a managerial position (see a developer who is targeting managers ). The better his savvy, the earlier when a replacement appears, he will try to do it. However, the promotion is not recommended, since you are likely to see the dismissal of the developers for whom the prima donna is responsible. Therefore, when a request for a promotion is rejected, he has only two options left: to stand in one row with other developers or leave. In any case, your problem is solved.



Idealist



The developer is so obsessed with the achievement of architectural elegance and perfection of the code that he forgets that his work should benefit the business.




Problem



The profession of a software engineer requires a constant balance of two opposite tasks:



  1. The desire to benefit the business (and get paid).
  2. The desire to write great software (and be proud).


The idealist completely ignored the task of benefiting the business, and instead focused solely on writing excellent software.



The idealistic developer is usually very intelligent, experienced and professional. He really knows what he is talking about. He really knows how to write great software, and if given enough time, he can create the perfect system. The problem is that he believes that he has all the time in the world and complete freedom , although this is far from true.



Instead of finding a compromise, he focused on creating the perfect system. He thinks it's better for business. Do not confuse them with scientists who create something “absolute” or “classy”: idealists sincerely believe that their ideal system is best suited for the development of the company. It is because of the steadfastness of this faith that they are so difficult to correct.



Idealists are especially dangerous for a project, because they usually have power over other key developers, because they represent the ideal to which developers are striving, that is why they are so easy to assemble other programmers to their side, because all developers want to be proud of the software they write. Thus, they take hostage the entire team of developers , and you are now in their power. If you are lucky, they will begin to provide business value, but this will only be a random side effect in their quest to create great software. In fact, a business benefit will appear only at the end of the work, but they cannot give you a timeline or evaluate this benefit. In truth, they are not even interested in completing, because it is the process itself that gives satisfaction, not the goal.



Decision



We summarize the features of an idealist:





In many ways, this is a very good employee, and if you look at the most innovative companies in the world, they have many idealists in the research and development departments. However, the best companies have three things that others do not have:



  1. Management personnel are as competent as idealists, offering checks and balances for their technical solutions.
  2. The expectation that a certain number of projects will fail, which is the usual cost of doing business.
  3. Large budget to continue to finance projects that are unprofitable.


If your company has these three things, leave the idealist alone, let him do what he wants. But if you, like most companies, do not have these luxurious conditions, then there is a real problem, because almost everything you do will lead to a catastrophe:





To force an idealist to change behavior, you need to find someone who can convince him. This person must demonstrate to an idealist that he, too, can create a great system. This is important because a person without technical competence will simply be ignored as unable to understand the genius of ideal design.



If a person is found with such confidence, he will have to slowly and methodically deduce the idealist from his idealistic way of thinking. This requires that a highly intelligent, experienced professional be ready to do what he thinks is right. There is little chance of that, and therefore little chance of correcting the idealist.



Rock star



The developer is so talented, so productive, so important that if he leaves, the whole project will collapse.




Problem



In the software industry, the term "rock star" is often used by recruiters who are trying to attract developers, inflating their ego, that is, "we are looking for several rock star developers." These same rock stars are hard to find, since they are ideal programmers:





Unfortunately, once hired, they become indispensable in the project.



A rock star looks like a black hole: work accumulates around them and ultimately inevitably sucked inward to be done. It can even go so far that they take away work from slower developers in order to meet the deadline - to everyone's relief. If the project is in a difficult situation, they will save the situation. If something dramatic and unexpected happens, they will know what to do. They are really wonderful - and every recruit knows it.



Recruiters will call a rock star every day several times. Their reputation is ahead of them. Companies always want to lure away rock stars because they understand their value, and in many cases will do almost everything to get them. Therefore, the situation is that there is someone indispensable for your project, which every second company wants to lure. If they do, the project will fail. A classic case when too many eggs are put in one basket.



Decision



There is no “solution” for a rock star. In the end, only a fool would want to "fix" him, since he is your most productive developer to date. All you can do is mitigate the damage by creating a team around you that can function effectively if you leave. Most likely, you will need several developers to replace the performance of one rock star, but at least you can survive his departure.



To check how bad your situation is, pay close attention to developer productivity when a rock star goes on vacation. If at its weekly absence all development stops, then it is necessary to redouble efforts in bringing other developers to a level at which they can keep the development of the project in the absence of a rock star.



It can be difficult, if developers are used to the fact that he copes with difficult problems, they become lazy and complacent. There is a chance that with the sudden departure of a rock star, other developers will take action. But, most likely, they love him so much that they will follow him to a new company.



Tagging to managers



A developer who decided to avoid programming difficulties and become one of the managers.




Problem



Programming is hard to learn. It requires skill to quickly solve problems, a large amount of knowledge and even more real experience. Unlike comparable professional fields, this knowledge and experience become obsolete much faster (sometimes within months), which requires the constant mastering of new methods, technologies and tools. Throwing in managers wants to get rid of this fuss, and sees the way out in management .



As a rule, for development managers there are lower requirements for programming skills than for developers. Time is spent on meetings, sending e-mails or even walking and talking to other people. Managers also, as a rule, earn more than coders, and with status come powers. This is an obvious choice for developers who want to get rid of writing software.



The problem with the developer, who began to think about the career of a manager, is that he seeks to demonstrate his management skills in the hope of improvement, rather than thinking about programming . In order to practice management skills, the future manager tries to command fellow developers: assigns work, speaks at meetings, and usually seeks to participate in more strategic decisions. Therefore, they are equally disliked by both fellow developers and other managers who see their work as a threat.



Decision



It is impossible to solve the problem of the future manager, because he has already made a clear career choice. Once the decision is made, there is no going back. You cannot force him to write programs again. Even if you make, then soon you will find the reason why he began to think about the career of a manager: the guy is not very good at programming. Because of the complexity of this situation, so many programmers-managers get what they want: promotion to the manager position, if there is a vacancy.



As a rule, the developers in this position are not particularly harmful to the project, because their performance is too low, and they usually do not have the special confidence of either the developers or the managers. Often, these people throughout their careers hang out around the organization, and top management is struggling to find a use for them . In this capacity, they can become dangerous if they are assigned a critical task, but since this can be completely avoided, they can safely remain just a minor annoying factor.



Hostage taker



A developer who wrote a piece of critical software and does not let anyone work on it to maintain its indispensability.




Problem



Any person with financial obligations is important to ensure the safety of their workplace and salary. In addition, working with familiar code is much easier than with unfamiliar. From the combination of these two desires, the hostage invader is born - the developer who wrote and single-handedly owns the critical part of the software, refusing to work on something else .



As a rule, this is a bad software engineer, which ironically becomes an important advantage: its code is usually not clear to anyone else , so other developers are afraid to climb into such a swamp, for fear of causing more harm than good. Therefore, all new work on a critical system is transferred to the invader, thereby continuing the vicious circle.



The hostage taker usually takes a defensive and confrontational position, it is absolutely closed to criticism or cooperation with regard to its code base. If he is really cornered, he will threaten to leave, and since no one else wants to take on a poorly designed and written product, such a bluff is rarely punished. They can become a bottleneck in the project, since the entire fate of the project will depend on their desire and ability to issue a code.



Decision



No matter how dangerous the hostage taker is, the solution is simple: to hold two or more developers responsible for part of the invader system, transfer it to another part. For some time, the performance will be low until new developers try to understand and rework the code, but at the end of this period the invader is completely neutralized and will no longer present problems.



Elephant in a china shop



The developer is so focused on completing the work that completely abandons any concept of quality.




Problem



Developers are always under great pressure. “The Internet never sleeps” means that often developers don't sleep either. In order to bring back a balance between work and life, the elephant in the china shop wants to complete his task list as soon as possible and return home to his family.



Programmers of this type create project pressure. No matter how good the developer is, if the pressure rises to a certain degree, he will inevitably stop testing his own work and instead rely on the testing department (see prosecutor’s type of tester) as the only means to look for errors. In addition, for convenience, they will refuse to collectively check the code, automatic testing and refactoring, leaving the code in disrepair. This poorly designed software then causes new errors, and the code base quickly turns into a swamp of bugs that cannot be fixed completely.



The elephant in the china shop lives in constant stress due to the pressure of the authorities. He is the victim of a poorly planned project, but the developer is still considered a problem. In the case of elephants in the china shop, the phrase “burnout and replacement” is used, since the constant stress will eventually break them, and they will either leave or be fired because of their seeming incompetence.



Decision



Since the problem is not a person, the organization should take the following steps:



  1. Announce a break on the project to give some respite. This is usually done by a sharp reduction in the amount of work or a significant postponement.
  2. The quiet period contributes to a frank discussion, when the elephant in the china shop has the opportunity to express their grievances.
  3. Make an analysis of the root causes of errors and fix them. Do not rush it. Make sure everything is fixed before continuing the project.
  4. Deal with all cases of burnout among developers, get them to take extraordinary holidays. Organizations rarely do this, but it is very effective.
  5. When the team regroup, perform a comprehensive assessment of the project, establish new amounts of work and deadlines.


Although these steps allow you to clearly solve the problem, they are almost never taken. That is, management remains the cause of the problem, not the source of the solution. But if management recognizes its role in the appearance of elephants in the china shop, then after a few weeks the damage can be compensated, and the development of the project will return to normal.



Incompetent



A developer who lacks the intelligence or skills to write software.




Problem



Not everyone is able to become a professional athlete or an experienced musician, or a doctor. There are also people who are simply not created to be software developers. These incompetent developers often deny their incompetence and refuse to leave the profession due to high salaries and a large number of available vacancies.



It can be difficult for a manager without technical education to recognize an incompetent developer, but there are several signs:





The entire software industry suffers from the problem of incompetence. This is a simple example of supply and demand, when the labor market lacks qualified developers.



Decision



When a manager notices an incompetent developer, the natural feeling of empathy often pushes him to assign tasks easier. Unfortunately, just as it is impossible to be a semi-literate heart surgeon or partially competent pilot, no one can be only partially competent software developer. If you lack the competence to develop software, then you will not be able to perform well even simple tasks.



When simple tasks are too complex, the next step is usually to allocate a budget for training. The main problem here is that if an incompetent developer could learn, he would have done it already - as his more competent colleagues, since competent developers are learning themselves.



There is a thought that having a not very productive developer on the staff does no harm, but this is a big mistake. They have two very damaging effects:



  1. The destruction of the quality of the code base, the emergence of a new buggy code and the introduction of bugs in the working code (see also the elephant in the china shop )
  2. They repel competent developers who are tired of working with them.


Ultimately, if the project is dependent on an incompetent developer, then the project will not be completed . This leads to the sad conclusion that such workers need to leave the organization. If they do not agree (usually after all the more direct hints), then they should be dismissed.



Optimist



A developer who constantly underestimates the amount of time required to complete a task.




Problem



Underestimation of deadlines is such a common symptom in the software industry that many do not even consider this a problem. Everyone always underestimates the time frame, and in many cases it is accepted as part of the business. However, the optimistic developer takes the problem to a whole new level, as he almost always gives up work much later.



The optimist influences the predictability of the project: without good grades it is impossible to plan for the future. Software release is sometimes associated with contractual obligations with customers and / or partners, which makes predictability a business necessity. Of course, one can always expect a bit of unpredictability, since in reality the entire software industry is built around the fact that it is impossible to predict exactly how long software writing will take. The optimist abuses this tolerance for disrupting the deadlines, fulfilling his tasks for several weeks instead of the promised couple of days; or, even worse, in a few months instead of the promised couple of weeks.



An optimist fundamentally does not understand the negative impact of such delays on the overall success of a project. He may also consider that the evaluation itself is a useless practice, since nothing can ever be accurately assessed. Thus, he can impressively treat the assessment or give an arbitrary number without any analysis.



Decision



Fortunately, an optimist can be corrected by following a few rules:





When an optimist has gone through this process several times and fulfilled his obligations, you can start trusting him in estimating terms for new functions, as well as for code bases and technologies with which he is less familiar.



, :





, , , . , , , .





, , .




Problem



, , . , . , , .



. , , , -, . :





. , .



Decision



, . — , . , , :



  1. , .
  2. , .
  3. . , .


, . , .



Soldier



, , , , , .




Problem



, , , ? , , . , . , : , , .



: - . : , . , , .



:





, , .



Decision



, . — . , , . , , . .



, , . , . , . , , «», .



, , , . , , . , . .



, . , .





, , , .




Problem



. -, . .



- : , . , , -.



. , . , , . , , .



Decision



, . , . , , , .



, , , , , . , , . , .



-



, , .




Problem



, , . : , . , .



- : . , , -. :



  1. .
  2. — , , .


. , . , .



Decision



- , , . . , (. ).



, . : , . , .



, — (, , . .), . , . , .



See also:

Source: https://habr.com/ru/post/431534/

More articles:



All Articles