Problem personalities among developers

Original author: Neil Green
  • Transfer


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 has been 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 of his indispensability 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 belief, a prima donna is not necessarily a skilled developer (see rock star type ). 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:

  • “It's stupid - I won't do it that way.”
  • “We have to do it like this”
  • “If you don’t like it, you can talk to my manager.”
  • "Well, we'll see."
  • “I'll go talk to your boss and see what he says.”

Diva rejects leadership. He regards any attempt at leadership as an insult, as he is above being responsible for his actions. This 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 higher than that of a simple middle manager.

The prima donna does not represent a material danger to the project, since it usually does nothing, but only shakes its rights. However, it adversely 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 decision 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 to work closely with him. In order to adequately convey to the prima donna that this is indeed its replacement, two conditions must be met:

  • Replacement should be more qualified.
  • It is necessary to make it clear to the prima donna that his replacement has no other job than to follow the shadow of the prima donna and be trained as his replacement.

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

The only hope to keep you feeling diva status - is to get promoted to a managerial position (see the developer type. Hopefuls managers). The better his savvy, the earlier he will try to do this when a replacement appears. However, the increase is not recommended, because you are likely to see the dismissal of developers, for which the prima donna is responsible. Therefore, when rejecting a request for a raise, 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.

  • May mutate into optimist or diva
  • Dangerous in combination with a technology fan.
  • Possibility of correction: no
  • Danger to the project: extremely high

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.

An 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 “cool”: 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 so easily gather other programmers to their side, because all developers want to be proud of the software they write. Thus, they take hostage the entire development team., 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 assess 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:

  • Very smart, experienced and professional.
  • He sincerely believes that his system is better for the company's future.

In many respects, he is a very good employee, and if you look at the most innovative companies on earth, 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 disaster:

  • If you immediately fire him, then loyal developers can soon follow him.
  • If you set strict rules, he can mentally disconnect from the project, which will leave you without technical guidance.
  • If you leave him alone, then the authorities eventually get tired of the lack of tangible progress.

To force an idealist to change behavior, you need to find someone who can convince him. This person must demonstrate to the 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 an idealist.

Rock star


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

  • May mutate into hostage taker and diva
  • Dangerous in combination with an optimist type manager
  • Possibility of correction: no
  • Danger to the project: extremely high

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:

  • There is no problem that they cannot solve (and quickly).
  • They work all night to make deadlines.
  • In their code there are practically no bugs or any bugs are quickly eliminated.
  • They take on the most difficult parts of the project.
  • They are usually very fond of colleagues.

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 go so far that they take away work from slower developers in order to meet the deadline - to the general relief. If the project is in a difficult position, 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. After all, 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 it leaves. 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 self-satisfied. 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 difficult to learn. It requires the skill of quickly solving 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 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 emails, 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, as a rule, 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 position of manager, if there is a vacancy.

As a rule, the developers in this position are not particularly harmful to the project, because their productivity is too low, and they usually do not have the special trust of either the developers or the managers. Often these people hang out around the organization throughout their careers, and top management is struggling to find an application 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 in order 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 individually 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 completely closed to criticism or cooperation regarding 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.

  • Can mutate into a soldier
  • Dangerous in conjunction with a tyrant type project manager and fire hose type tester
  • Possibility of correction: high
  • Project Hazard: Medium

Problem


Developers are always under great pressure. “The Internet never sleeps” means that developers often do not sleep either. In order to bring back the 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 increases to a certain extent, he will inevitably stop testing his own work and instead rely on the testing department (see the type of tester accuser) as the only means to search 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 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 human, the organization should take the following steps:

  1. Announce a break on the project to give some respite. This is usually done by drastically reducing 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 regrouping, 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 room, 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:

  • They blame the lack of corporate training for their low productivity.
  • They dispute the use of “too complex” technologies, tools and methods.
  • They strongly overestimate the deadlines for the work (see pessimist ), and then still do not pass it on time.
  • Issue functions that do not meet the specifications.
  • The implemented functions are full of errors.
  • Experienced developers avoid or refuse to work with them.
  • When asked about the progress of work, they are justified and often take a defensive position.
  • Apply for a management position (see labeling at managers ) to bring "more benefits."

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 one cannot 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, because competent developers are learning themselves.

There is a thought that having a not very productive developer on the staff is not harmful, 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 more and more direct hints), they should be dismissed.

Optimist


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

  • May mutate into a pessimist
  • Dangerous in combination with an optimistic project manager
  • Possibility of correction: high
  • Project Hazard: Medium

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 an assessment or give an arbitrary number without any analysis.

Decision


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

  • Ask them about the assessment only for the code with which they are well acquainted.
  • Ask for evaluation only for technologies with which they are well acquainted.
  • Never ask to evaluate the timing of the implementation of new functions, but only to improve existing ones.
  • Care must be taken to ensure that they fully understand all requirements - they cannot freely interpret requirements on the fly.
  • Ask the optimist to add TODO comments in areas where they will have to make edits. This will reinforce the relationship between software complexity and timing.
  • Make them accountable: show their ratings to a group that can challenge such deadlines.

When an optimist has gone through this process several times and fulfilled his commitments, 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.

During the optimist's rehabilitation process, pay close attention to how he observes his deadlines:

  • Whether the quality of work suffers from increased obligations (see the elephant in the room ). If so, suggest adding the required time for testing.
  • Do they work overtime to meet deadlines (see soldier )? In this case, suggest adding time to do work during business hours, and overtime should be left for unforeseen circumstances.

If an optimist is serious about his rehabilitation, he can grow into a highly trusted member of the team, as developers who issue an appropriate code of sufficient quality in an agreed time frame are trusted. As soon as they prove that they can consistently do this, they can be promoted or paid, which in itself can be offered as an incentive for their rehabilitation.

Pessimist


A developer who is so afraid of missing deadlines that he asks for the maximum possible time to complete a task.


Problem


If there is a choice, most project managers would prefer pessimists than optimists. Although they may work for a long time, they are at least predictable. A pessimist knows this very well and makes full use of this circumstance, requesting the maximum time for his task instead of considering realistic deadlines.

Pessimists are sometimes impossible to notice. They can be mistaken for mature and responsible, because, unlike their seemingly less experienced fellow developers, they never miss a deadline. But there are some signs:

  • Their fellow developers, with the same assessment, give significantly shorter deadlines.
  • If you assign them a deadline, they immediately agree, without any formal assessment.
  • When they quickly agreed, if you move the date a little to an earlier date, they will agree to that date. This means that between the two dates you really do not need additional time to complete the task.

A pessimist can reduce the competitiveness of a company. If you are involved in a race with a competitor, you will always be slower than him.

Decision


Pessimists are born through the fault of an organization that punishes deadlines. The natural response of people is to request as much time as possible to minimize the likelihood of punishment. It may seem easy to fix, but three things work against you:

  1. Work in the pessimistic mode is much less stressful than normal work.
  2. Pessimists are usually rewarded and raised much more often by those who miss important deadlines.
  3. Business must become more tolerant of being late. When a certain culture of development has been settled, most companies are not capable of it.

Therefore, the problem is fixable, but usually there is no will to correct it. By their nature, pessimists do not pose a threat to the project, but are potentially very dangerous for the future viability of the company.

Soldier


A developer who does exactly what they are told without question, regardless of whether it is right.


Problem


From a manager’s point of view, who can be better than a developer who does exactly what is said? Indeed, the key problem with the prima donna is that it does not follow orders. Of course, a fully compliant developer is a boon to the project. Unfortunately, the soldier has his drawback: he obediently jumps into the abyss, if they say so, dragging the entire project with him .

A soldier can be of any level of competence: from incompetent to a rock star . The key characteristic is his obedience: every time he will do exactly what you tell him. It is easy to make a mistake, considering it an effect of fantastic leadership, but excellent superiors are very rare.

Soldiers are born in several ways:

  • You have rejected their objections so many times that they just stopped complaining: they do not see the point. If the objections were justified, then you have lost a valuable source of information about what can be improved.
  • The soldier wants to do a minimum of work, and if you only do exactly what is asked of them, then this is by definition the minimum.
  • They know that you are asking to do the wrong things, and they want you to suffer the consequences.
  • They are so tired that they are looking for another job, and they just pull time until they find something.
  • They lack the knowledge and experience to see the mistakes, so the soldier blindly marches forward.
  • Fear of punishment for mistakes makes you think that the best way to avoid punishment is to do only what is asked for.
  • They have convinced themselves that complete submission is the path to career growth, which is very sad, since this is almost never true in the innovative field of software development.
  • This is really the former military, who brought with them a specific mentality.

As a result, no matter how pleasant it may seem to have a soldier in your submission, this is hardly good.

Decision


If you give the correct orders, the soldier will not cause any problems. In fact, with a strong leadership, the presence of a detachment of soldiers is a very effective weapon. But if you need feedback from developers to help co-lead the project, you won’t get that kind of collaboration. It leaves you in a situation of obscurity, when you do not even know that something is missing. A soldier will not tell.

If you can determine the reason why the soldier implicitly obeys you, then there is a chance to correct it. However, by nature he will not say openly why he has become so. As a rule, the soldier prefers to communicate on specific work topics. If you click and ask if there is a problem, the most likely answer is “No,” regardless of his true feelings.

You can only hope that his colleagues will tell about the soldier, but then they betray his confidence, which is unlikely to happen. Even if you identify a true problem, you will have to fix it, which can be difficult. Then, after eliminating the root cause, it remains to hope that the soldier will change his behavior. Only he himself can change himself.

In general, they are almost impossible to fix. Thus, they are usually good employees to support a strong leader.

Fan of technology


A developer who is so happy to try new technologies that will embed them in a project, is it appropriate or not.

  • May mutate into hostage taker
  • Dangerous in combination with an idealist.
  • Possibility of correction: high
  • Project Hazard: Low

Problem


To successfully launch a product, you must select a technology. This is a careful choice with attention to a specific set of business problems that need to be solved. A fan of technology just loves new toys.

All developers are to some extent in love with technology: they must be such as to maintain their skills. But when a developer confuses his professional responsibility and personal curiosity, you may end up with a technological stack that does not fit the business goals wildly.

The developer in love with technology is very easy to pick out from the crowd. He will often and publicly advocate the use of new technology, often with flimsy arguments. He also suddenly changes technology in the midst of his work, without telling anyone, taking others by surprise. In many cases, this may be a truly excellent technical solution to a specific problem, but since the technology has not been properly tested, it may be poorly suited for the project as a whole.

Decision


Fans of technology are corrected by themselves, if the company has installed a standard technological stack. Then you just need to make sure that the developers do not deviate from it. If you do not have an installed technology stack, it is strongly recommended that you define it in advance, as it will be inconvenient to enter it after a technology fan begins to active.

The news that you can’t use your new technology is likely to damage the morale of the technology lover, but you can quickly restore this morale by asking him to make a presentation about this new technology. This is an extremely healthy decision, because after the presentation, the team can jointly discuss whether it makes sense to expand the stack of corporate technologies. Most technology lovers will be satisfied with such a judgment, even if they do not like the final decision.

Legacy Code Keeper


The developer, whose only ability is maintenance of outdated software, and therefore he is not able to take on new work.

  • May mutate into hostage taker or soldier
  • Dangerous in combination with a creative designer.
  • Possibility of correction: no
  • Danger for the project: no

Problem


When a new developer comes to the company, he is usually full of fire and passion, trying to prove himself in every way. But over time, passion takes the place of complacency: the developer believes that the experience in the company gives him certain privileges. For himself, he recognizes the responsibility to maintain their systems, but not to take on the development of new parts.

The problem with the guardian of Legacy code is related to scaling: they simply do not belong to the pool of available resources for a new job. At this point, the question arises whether you can afford to keep them in the state, that is, whether other developers can take over their legacy code maintenance tasks. It is usually difficult to convince other developers to do this for two reasons:

  1. Ancient code is usually poorly written and difficult to work with.
  2. Support is a dead end career path, because you are not doing anything new or innovative for which you can be noted.

That is why old maintainers remain in the company for so long. Often they have been with the company since its inception and are the authors of the software on which the company is built. However, as the company grew, they did not advance in the service or did not try to acquire new skills or new parts of the system, as a result of which they became firmly attached to the only code they knew.

Decision


The keeper of Legacy code does not create problems if it is understood that it is not among the resources for working on new projects. At best, you can ask him to correct errors and implement small improvements in functions. The only problem arises if they prohibit others from familiarizing themselves with their part of the system (see hostage taker ).

The guardian cannot be corrected because he has no such desire. He has the mentality of a factory worker: turn the same nut every day throughout his career and then retire. Such an attitude cannot be changed, since it is the essence of man.

One of the options that can change this attitude is if a person survives significant events in life (wedding, birth of a child, buying a house, etc.), which will require additional income. In this case, he will understand that supporting outdated software will not lead to an increase. Unfortunately, you do not control this factor.

See also:

Only registered users can participate in the survey. Sign in , please.

Did you recognize yourself in one of the types?

365 users have voted. Abstained 60 users.
Tags:

Also popular now: