Four types of programmers

Hey.

I am writing for the first time in a stream about management and recruitment. It’s about one way to classify your future or current programmers. My main thesis: all developers, roughly speaking, are divided into 4 large types and each of these types has its own scope. Attempting to direct the wrong type to solve inappropriate tasks leads to failure (inefficient work, or the employee leaves the team). Want to know why, welcome under cat. Get ready, a lot of text.

Once, for fun and good use, I worked part time at one good recruitment agency — I interviewed incoming programmers for knowledge of C # /. NET. My responsibilities did not include a full technical interview - rather, the initial screening of candidates in order to understand who is who, filter out completely terrified, and if something happens, give advice on what to read and how to improve skills. And that recruitment agency had an interesting client. He is well known to everyone, but then they said little to me about him - I just realized that he seemed to be looking for rock stars - highly skilled developers, regardless of the technologies used. After I recommended several people for them, the deputy gene contacted me. Director and invited to the meeting, because my recommendations are not quite satisfied with the customer. So I met the founder. There I was told a very interesting story about why they need rock stars and how it all works together. It turned out that not at all rock stars needed. We need, as the manager has made me understand - people with strong fundamental knowledge (algorithms, design, operating systems, network technologies) who will be ready for growth and development. And so they take them and develop them, and then send them to implement quite complex outsourcing projects. At the same time they told me what problems the company was having in this regard. I left in thought and spent quite a while in my head this business model, as well as the thoughts about the Russian IT industry in general and the policy of working with the staff in particular.

In the end, after a few years, I finally exhausted all the information I had in my head and put it into a model that was consistent with the surrounding reality. This gave an answer to the question why the personnel pipeline of the company mentioned above ideologically cannot work, and at the same time a lot of other interesting incidental information. So was born my classification of developers for types.

It is important to understand that there are no "bad" types. If any of the types you think is bad, then you just do not know how to cook it. Remember: each task is a suitable tool. I will talk about all 4 types in the form of cards, giving a brief description, indicating the background, goals and motivation, as well as talking about strengths and weaknesses. Especially it is necessary to pay attention to the background, as in a particular type people grow out of their background. We begin with something easier.

Linear programmer

Salt industry IT-shnoy. On such people, they say, the world holds. He's a hamster. He is also a “rower on the gallery”, but I prefer to avoid such shortcuts, so simply “linear programmer”. He does not have enough stars from the sky, does not write his compilers and DBMS. Well, the maximum - will make a couple of tools to make life easier for themselves, otherwise - it just solves working tasks. Rarely changes jobs. Is persistent Work is treated like work, without much enthusiasm. Moderately lazy. Disciplined (but there are exceptions), however, without proper management, it is quickly "loosened" and loses focus. You can manage such people by standard methods - described for example in the book of J. Rainwater - How to graze cats . Qualifications can vary and are determined solely by experience and the number of projects in which the linear programmer has participated. Sometimes qualified linear programmers fall into minimal managerial positions - they are named by the team lead, and here the above book comes in handy. But the most important feature of a linear programmer is a very frequent lack of desire to develop and experiment. He will perfectly solve even the very tedious task that you will offer him if she is not too complicated. He will choose the quickest and most straightforward tool he knows. Development for these people is sporadic in nature and basically goes "wide": to explore a new framework or a new tool that will help to better solve everyday work tasks. Or "the customer came, who uses just such a thing - well, let alone, we will understand." It is noteworthy that the knowledge gained as a result of the sporadic development of individual linear programmers is precisely the experience of an outsourcing company. However, moving the mountains and exploring the surrounding world "inwards" on their own to a linear programmer most often simply does not pull. For example, he is simply not interested in learning a new, HYIP programming language. Only if the new language helps in solving everyday tasks. And even more so to develop your own language - thank you. And this is normal. Worst of all, linear programmers "turn to stone" when they sit in one place for a long time. That is, if you have a person who has been consistently engaged in conceptually the same projects for 3-5 years, then it is very unlikely that he will change the type and will develop "inwards". But before this empirical term, everything is possible and depends on the background.

Background: different. In the "linear programmers" there may be people who have completed online courses, university graduates, some olympiads, former technical scientists, and even people from conceptually different professions (there are cases when truck drivers became PHP developers). It is important to understand that a linear programmer is in itself a background and a ground for jumping into another type. But! Whether a person jumps or not depends primarily on his personal desires, and not on his skills. The presence of one or another background determines only the direction of a potential jump, and not its probability! But the likelihood of a jump over time drops sharply. However, if you need a faithful employee for a long-term contract - learn to identify those who want to "jump" in advance. Run away from the project - it will be unpleasant.

Appreciates: stability, average, but 2-times-a-month-stable wages, peace and personal relationships in a team, normalized working day, office buns such as a billiard room, fruit on weekends, travel expenses or the gym, honey. insurance and (perhaps tedious, but) hard work.

Strengths: perseverance, responsibility, interpersonal skills (once in a while), complete controllability, calm behavior in stressful situations for a project

Weaknesses: complex and / or non-standard tasks, abstractions, behavior in stressful situations for a company, again

Interview: should pay attention to psychology: perseverance, discipline, communication skills, aspirations, that's all. It also makes sense to talk about previous experience and look at the summary. To write a standard test task a la "write a chat on web sockets", look at the deadlines, "lined" tasks and the adequacy of the selected tools. Good are technical questions on the knowledge of languages, protocols, patterns and standard libraries. A plus would be if the applicant already has experience specifically with your set of frameworks, but if not, it doesn't matter. If everything else is in order - will understand. Its' his job.

What you should n’t ask : don’t ask why round hatches (don’t ask anybody at all), don’t ask him to deploy a red-ebony marker on the board, estimate the complexity of the algorithm, perform topological sorting or design a high-load system. From this linear programmer is not good, I want to cut you in the pumpkin and run away.

Rock star (Software Scientist)

Concentrated researcher. Such more like classical scientists, but only from IT. They are interested in algorithms, theoretical studies, conceptually new directions in the industry, but above all - they are interested in experimenting. For the sake of these experiments they are hired, in fact. They are willing to spend hours digging through complex things and solving problems that other people don’t even understand. They are experts in complex issues. They know exactly when q-sort should be replaced with heap sort and how they differ, or maybe what clustering algorithms are suitable for analyzing the flow of stock quotes, and others know what optimizations are used inside g ++ and how they help to live. The backbone of such people, for example, is able to develop a new programming language and compiler for it. Or significantly improve any existing system. They are also often predisposed to functional programming. I do not hint at anything - just a statistical regularity. By the way, govnododit rock stars can (especially at the stage of prototyping ideas), but for the most part do not allow bad code to the final versions of things developed by them, try to do everything nicely, with comments and convenient software interfaces.

But.

As always, there is a "but" which spoils everything. It is important to understand that under no circumstances will these people solve your tasks. That is, yes - rock stars will solve those problems that are interesting to them . For your money. And with that - for big money. And with that - not the fact that there will be some kind of result. The fact that your tasks coincided with the tasks that are interesting rock star - very, very big luck and a happy coincidence, no more. But if tomorrow’s a rock star, it’s going to head up for GHC instead of improving your build of MySQL, then you will have a limited amount of time to quickly and decisively fire it. When you try to force it to return to your tasks, you will receive, depending on your temperament and your soft skills, or conflicts or quiet deadlines. Well, it’s good to have people so thoroughly deployed - this happens rarely and happens gradually, yes. But the opposite situation - if you transfer a rock star from improving your build of MySQL to improving GHC against his will - it happens quite often. And, as it is easy to notice, it leads to similar consequences. And this circumstance makes the rock star totally unacceptable for outsourcing.

That is why rock stars feel best in grocery companies (for example, JetBrains), where they are given complete freedom in a single product and completely rule out a sudden change of tasks (except through dismissal). People get the opportunity to engage in those tasks that are interesting to them, self-actualize, unfold, and at the same time nobody pulls them. It turns out a good thing - ok, goes to release. Not? Well, to hell with it. In such conditions, rock stars take root, live a very long time (up to a dozen years) and they feel good.

On the part of the management, light and unobtrusive control is required here - so that the rock star does not disperse and does not “slip” them into unpromising experiments. Well, just as softly to inform that this or that interesting development to him is irrelevant.

There is another great example of working with rock stars - this is Google, in which the rock star has the opportunity to do what he wants. Google feeds them, waters them, clothes them and protects them from external threats. In return, everything that rock star is inventing will be owned and promoted by Google, turning into its products. Fair enough. Such seed investment in a single company.

Background: lyceum or another good school, higher education in a good university on IT-specialty or mathematics. Round (at least oval), excellent student. Probably involved in serious research activities (scientific publications as a plus) and / or Olympiad programming right from school.

Appreciates: peace (while solving the problem), free irregular schedule with the possibility of remote work, adequacy of management, opportunity to work with other rock stars, complex, interesting and non-standard tasks, stable financing. He either takes office buns for granted or ignores them completely, but on the whole he does not feel special respect for them.

Strengths: challenges, research activities, often design.

Weaknesses: there are often problems in communication, there is no stress tolerance, instability in a company or a project easily flushes away rock stars, rigidly set deadlines turn into stress, the inability to switch over subject areas only if you wish. In spite of all creativity, it is not independent outside of its tasks.

Interview: algorithms and data structures, complexity assessment, Olympiad tasks are your reliable friends. You can force to expand the tree on the board (but why?) - but it is much better to give a simple math problem. The main thing is not to hurry and do not rush: let the person think as much as he needs. Creative tasks, mental tasks (well, just not about the hatches!) And design problems in the format of "let's argue" and "propose a solution" are also quite good. Look at education and publications in summary. Ask about participation in competitions, scientific conferences, take an interest in the topic of the thesis. If he tells with burning eyes, you have found what you need. It is also worth making sure that the applicant knows perfectly any programming language (any), otherwise it is not very clear how he will implement his experiments.

What you should not ask : do not ask stupid questions. Stupid questions include: details of the implementation of something a la "what does the Content-Length HTTP header do?", Questions about communication skills and other psychology (yes, rock stars may have an absolutely ugly character - but what can you do, such is the price for them), and even more so do not stutter and do not even think to check stress resistance. Punctuality check only at the level of "does not disappear for a week and all right."

Dealer (Software Engineer)

Rare beast in our area. It is sometimes called "result oriented", "every whim for your money." A kind of linear programmer who unexpectedly (and in fact - predictably) got autonomy, self-motivated and started to grow where he sees fit. This is not a rock star, because he is not interested in deep and abstract tasks. He is interested in working tools that bring concrete, tangible benefits that you can touch here and now (often - in the form of crisp bills in your pocket, but more on that later). If there is no working tool, the businessman makes it for himself. He is very fond of specifics in setting tasks, in technology and - most importantly - in communication. They are also said to be "strict but fair". Communication skills are good. Politically correct, friendly, not heavy, although it can be rude and prone to boring formalities. The businessman is not from the good life, because the rude reality of the businessman quickly puts rude and silent people into place. You will be rude - you threaten your reputation. You will be silent - you will not receive orders. You will not avoid and resolve conflicts, climb on the rampage - you will remain without money. Materialist. Works with the tasks that objective reality sets for him. If he does not understand something, he asks and seeks a concrete answer. His bread is a carefully selected or self-developed toolkit, experience, ability to understand every nasty thing in an acceptable time frame and work on speed and quality. The toolkit picks up itself or after consulting with other businessmen - and God forbid you give him advice at this moment. Responsible. A good businessman does not break deadlines and provides a working and supported product. To govnododa refers as one of the tools. It may take a technical debt, if it is appropriate and useful in a particular situation, given the specifics of the project. Knowledgeable in management. He often understands him more than his immediate superior. Based on this, ad-hoc management solutions may be recommended. Of the professional flaws, it is worth noting the inattention to trifles, but this is also treated by good businessmen.

Cool description - is not it? What is the catch? The trick here is two. The first is that the businessman does not tolerate any superiors, especially if he is less qualified than the businessman himself. This is largely due to the very awareness of management methods. Well, also by the fact that the businessman himself perfectly understands how money is made in the IT industry. As a result - the businessman does not obey orders. Dealer cooperates under contracts. Any attempt to force a businessman to do something outside the contract (if not formally signed - at least orally agreed) - leads to a polite refusal at best or to the termination of the contract at worst. If the businessman did not subscribe to send you daily reports - he will not do this. If you didn’t sign up to spend 8 hours a day on you (if there is a deadline for the completion of the assignment), then he will not do this. If you did not subscribe to edits to the project - well, you understand. However, if you buy in bulk some number of working hours of a businessman (without specific deadlines and specific tasks), he will be happy to listen to your moaning, vague requirements, to give and take part in any corporate campaign - but what? Flattened the same. Every whim for your money.

The second catch lies in the very attitude of the businessman to money. The businessman is not subject to intangible motivation. On your "company will pay you a gym, lunches and cats on Fridays" is likely to answer, "let's better money." And the businessman loves a lot of money. And not just a lot, but a lot. Yes, he is loyal to the instability of payments, to processing and to pay for the result, but this payment must be large.

Long-term contracts for small monthly amounts do not lure him. Only for large ones - buy out wholesale time, yes. As a result, the businessman often changes his place of work (to the extent that this concept exists for him). Sit down - you will become a linear programmer. As a result, he is qualified to solve a fairly wide range of tasks. Remember - a good businessman is always worth the money. And if you don’t give him enough money, the businessman will try to requisition the levers of control. In many ways - from the arrogance of the customer and the team (if he has such powers) to an honest heart-to-heart talk. If this fails, he will leave you quickly and decisively, because why? Good dealers finish opening their own companies, but, as mentioned above, in our country there are few dealers in principle.

Background: often self-taught. Engaged in programming because it is interesting. Higher education is there, but it is worth looking at the reputation of the school. If the school is serious - then troechnik. For how it works from the first course. And in general, the study of any science prefers to get to real work as soon as possible. Very often freelance. Some businessmen have problems with fundamental knowledge. However, if this is definitely a businessman, then these problems are easily solved.

Appreciates: high payment for their services (in this wording), compliance with agreements, high-quality solutions to problems. Schedule and buns - by agreement, but usually prefers a free schedule, not tied to the place of work with fixed goals, and buns - but give better money.

Strengths: broad and moderately profound qualifications, autonomy, responsibility, result orientation, tolerance for instability in a company (as long as its contracts are respected), tolerance for short-term contracts and their sudden cancellations (not violations, but cancellations I said!), Elephants stress resistance.

Weaknesses: high cost (2 times higher than that of linear programmers and this is only the beginning), can themselves violate the obligations of the contract (this is if the business is bad and good for nothing - or just a beginner), uncontrollability in the “I am boss” mode you are a fool "(if not consolidated), short-term plans, non-punctuality unless otherwise provided by the contract.

Interview: it is difficult to find a good businessman. Your friend is reputation. Look at the resume, do not be lazy to contact the person who collaborated with the applicant earlier. If it is a question of remote work - look that at the applicant with availability. How quickly he responds to mail and messages, phone calls. If personally - how punctual at appointments. Then ask about the knowledge of the required technology. But the only way - without fanaticism. Of course, it’s nice if the businessman knows exactly what address in memory of the connection closure function in the proprietary library you are using - but believe me, this is not something to ask. It would be nice to ask for examples of projects that the businessman has already implemented on your stack / using your technology. A good businessman will always have something to show and tell. Tasks on designing and “how to solve this problem with a given technology” go bang, especially if they are seasoned with project details (for example, to solve a problem under conditions when the customer requires a release every week, etc.).

What you should not ask: algorithmic questions, mathematics, problems of attentiveness and other nonsense, which is asked from the rock stars. Is that only at the level of concept. Well, that is, a businessman can know in general what is, say, a bicubic interpolation, but do not force it to implement it on paper or on a computer without the Internet - you will be fairly (but politely) sent. A separate item should mention the test task. Do not give the standard test tasks: a good businessman of such tasks for the whole life he redid so much that you never dreamed of and one more thing he doesn’t need at all. Further. Get over the fact that the test task is a waste of business hours of a businessman. Get ready for what it will be paid. Offer to conclude an NDA, a temporary contract and make, for example, a commit with a fixed bug for some of your products or any system with the condition of payment for implementation and specified quality requirements. This is the most effective method. Do not forget to tell how to configure the environment. A good businessman it does not take much time, but there are incidents.

Passenger (business bullshitter)

This type has a lot of "gentle" names among the people. The least qualified colleagues obey him, the more qualified ones do not like him. The leaders of these adore and then I will explain why. In short: the passenger is charismatic. Everything. He speaks a lot and beautifully, but does little catastrophically (or poorly). Increased communication skills - his bread and often the passenger gets to managerial positions, because he doesn’t know how to do it himself, but he has enough oratorical talent to make someone work for himself, and - moreover - to convince the boss that he should be in charge of the project. In all, he demonstrates seriousness, zeal and self-confidence, seeks to resolve any problem, organize a meeting and discuss, always taking into account the opinion of the team. From the side it may seem that he had an awl in a certain place. He is almost always in touch, everyone responds to letters, revealingly polite ( so that sometimes you want to embed sorry escaped) and can find an approach even to the very devil. Only one minus is technical qualification. In truth, he doesn’t like programming very much (even disgust), but he really likes to command. Therefore, a weak technical qualification (or its complete absence) he often "covers up" with beautiful words, ostentatious participation, interest, friendliness and sociability. One of the worst mistakes is to put such people in middle management positions in teams. As soon as you did it - everything. You will no longer receive reliable data about what is happening within the team from a technical point of view. You will have a beautifully presented brief on what is happening, but those places that the passenger does not understand at the technical level will be excluded from it. And this is in 90% of cases - hidden problems and a variety of detonators.

However, a well-chosen passenger can help the team communicate with the customer. For example, it costs nothing for a passenger to convince the customer to postpone the release date - and the latter will also think that this is the best solution. Using passengers as diplomats for customers is a pleasure. However, remember: charismatic passengers are like a broad-spectrum toxic anesthetic. It makes sense to periodically spray them with customers, but the leakage of anesthetic barrels within the team leads to very disastrous consequences.

Background: "class leader", "alpha male" at the university (it is a pity that you can not check it in any way). Mr Charm. Education may be different. However, keep in mind that assessments could also be obtained through an oratorical skill. I could start programming because it's interesting, but with such charm he had things in life and more importantly. web- . .

: , , .

: , , , -,

: . . , . — .

: . — — . . , , . . , . . , , — " ", . . , — — . - , . — SCRUM, PMBOK — . .

: — ( ). , — : - , . … . , , , . . — . — .

findings

, . - rock star, rock star . - , UpWork. ! , .

. rock stars, — . — . . — rock star " ". , rock stars , — , — . , — . - . So I see.

. , , .

Thanks for attention! !