A lot has already been said about managing people as a whole (according to many, more than enough). About managing programmers, taking into account the specifics of their tasks, organization of work and internal relations in a team, is much less. Any attempt to summarize and analyze your experience from a person who has cooked in the IT environment and as a developer and as a manager is of particular value to those who are preparing to go the same way and puzzle how to apply general management theories to programmer's realities.
J. Hank Rainwater, an old-school programmer, is one of the people who know all the carrots in the role of technical leader in vain, because they themselves floated in them. His book â How to Graze Cats â captivates with its objectivity: it describes specific situations that are well-known to everyone, different components and working conditions of the team, and even authorâs technological solutions (unfortunately, already outdated). In a short series of articles, we plan to cover everything that seemed to us the most useful and relevant in the book - from the typology of employees to recommendations for communicating with other teams.
Start with a reasonable question: why, in fact, cats? The author himself, as an explanation, refers to a quote from Helen Alman, who draws this analogy in her book Close to the Machine:
âOne of my acquaintances in project managers once compared the process of managing programmers with cat grazing. He wanted to say that the dogs, faithfully looking into the eyes, we absolutely do not need. A good programmer needs to be appreciated along with all his oddities. On the other hand, all these good programmers need to be somehow made to move in one direction. â
First of all, programmers are related to cats by the fact that neither one nor the other has an innate tendency to go astray. They prefer to walk on their own, and the culture that has developed in the IT sphere has long encouraged this type of behavior (or, at least, did not prevent it). Accordingly, the technical manager faces a doubly difficult task: to organize single people into a more or less cohesive group without violating their individuality, most likely, you will have to hone your own skills in working with people.
The Rainwater defines its target audience as follows: newcomers to management (yesterday's developers who received a leadership position), leaders of small teams (up to ten people) working on several projects, from small or medium-sized businesses. For a larger scale, some techniques will no longer work, and more experienced technical leaders have probably already learned a lot for themselves. The book is designed to help the leader in the most acute transitional period and prepare for future changes.
If you look broadly, a novice manager faces two major problems: a new position fundamentally transforms the mechanisms of its interaction, firstly, with people, and secondly, with processes. We will talk about the second in detail later, but one common mistake should be mentioned right away.
Many people cannot accept the fact that they will have to give up part of their tasks related to writing code, and the stronger the programmer, the stronger this feeling of protest. The situation is aggravated by a new sense of responsibility for all the code that the team produces. As a result, instead of redistributing time and devoting hours to administrative work, the manager goes headlong into worries about the technical side of projects - he does all the reviews himself, meticulously checks the design, or even rewrites the unsuccessful fragments. The most stubborn neglect all other responsibilities not directly related to the code, and this ends in disaster. The more sober-minded ones turn into werewolves: during the day, the head, at night the programmer, and this ends in burnout.
For this reason, the first thing a technical leader has to do is to recognize and accept the inevitability of changes in the structure of work and tune in for a rather long period of âbreaking upâ. The author estimates the adaptation period to be approximately six months - only by this time the majority gets used to the new role and begins to feel comfortable in it. One can be comforted by the fact that the definition of âtechnicalâ is not an empty phrase: the one who leads the developers simply cannot afford to completely move away from working with technologies, so there is no need to fear that managerial activity will supplant it.
Now let's move on to the second source of change - working with people. In a leadership position, a programmer has to not only get along with team members, but, roughly speaking, use them as a resource - identify who is capable of what and direct these skills to where they are most needed. Thus, the task falls into two parts: you need to be able to understand people and be able to communicate with them.
To help the reader with the first paragraph, Rainwater offers a classification of the "breeds" of IT cats, which he built on the basis of his own experience and observations. His list of breeds summarizes regularly occurring types of developers with vivid distinguishing features, strengths and weaknesses. Like any other, this classification should not be taken as an absolute standard - in the wild, types often mix and cross, are more and less pronounced. However, this is a useful starting point for analyzing the intellectual and personal characteristics of their programmers.
The author divides the breeds into three groups: common (caught most often), rare (caught occasionally) and mongrels (in their original form carry less value than the total mass).
Common breeds
Architect
Favorite of most managers. It focuses on the general structure of the code, goes from analysis and abstract constructions to the implementation of specific solutions for them in the code. Strength - it generates good ideas, sometimes it can lead a project alone, from concept to the final form (although some individuals lose interest after the general structure is outlined and give the âcraftâ work to lower-level developers). Weakness - often it produces a confusing, obscure code with strange designs that only obeys the owner and is very difficult to give support from the outside.
Constructivist
He takes real pleasure from the programming process itself, strives for a good result. Strategic planning is usually indifferent, the code is written on a hunch, not thinking too much about the general logic. At short distances, this does not do much harm, and you can rely on the quality of the constructivist's work. When the project grows, the lack of internal logic usually begins to affect and âpatchâ decisions are used - we recall that the constructivist is very focused on the result. Works great in conjunction with an architect. It is reluctant to document (âeverything is clearâ), but with due perseverance of the leader, it is quite soundly.
Artist
I also knew the joy of writing code, but its element is the search for unexpected, elegant solutions for implementing the given requirements. As a rule, there are no problems with logic and organization. The main disadvantage is an excessive love of art and experimentation, which encourages to stretch simple tasks and disrupt deadlines. It has some similarities with both the architect and the constructivist, but usually stands out with its bright individual programming style.
Engineer
Considers software development as a virtual analogue of the hardware assembly with all the ensuing consequences. He very much likes to fit one to the other, to assemble disparate modules into a complex structure so that everything works, to find a place for solutions from third parties in the constructed system. Skills are certainly useful, but there is a way to let the engineer get carried away, complexity can turn into an end in itself for him. Excessive complexity and lack of product flexibility are two vulnerabilities of this breed.
Scientist
In contrast to artists, he considers programming as an exact science - he tries to follow fundamental principles in everything and to avoid the âgagâ. Very pedantic, striving to bring the code to perfection and achieve correct operation in any conditions, often to the detriment of practical considerations. Like an engineer, he is inclined to complicate everything unnecessarily. But when it comes to truly complex tasks requiring scrupulousness and knowledge, he has no price.
Lihach
It puts speed above all, including the quality of the code. Neglects trifles like commenting, correct design, following accepted rules. At first glance, it gives a good, quite working result, but in-depth testing reveals a lot of problems. Sadly, this breed is cultivated by the leaders themselves: scorchers are most often obtained from young programmers who are instilled with false priorities and who are afraid to not meet expectations.
Rare breeds
Wizard
In modern terminology, a wizard is usually called a rock star. Takes on the most difficult tasks and manages, finds revolutionary ways to solve problems, does everything on time and efficiently. Even with the maintenance of his code, special difficulties usually do not arise. In general, everything seems to be wonderful, but the technical leader needs to keep his eyes open in two respects. Firstly, one should not allow excessive dependence on the wizard - the whole team, including the leader, risks turning into a dance for one employee. Secondly, you need to be prepared for the fact that one day the wizard will disappoint you all the same - no one can consistently work miracles. Such an opportunity should be taken calmly and have a backup plan.
Minimalist
He writes surprisingly functional code of very modest amounts. Everything looks harmoniously, clearly built and unambiguously announces its appointment. This breed is very capricious in choosing tasks and projects; the minimalist will fight more than others for the right to establish the area of ââapplication of his abilities. Weak point - escort. He struggles with all his strength to make changes to his code (not to mention someone else's) - he is simply not interested in tinkering with particulars when the main thing is done.
Analogue
It differs in specific thinking, compensates for its difficulties with abstractions with a love of analogies. At meetings, itâs hard to catch his train of thought, but he quickly grasps the point. As a rule, they write good, easy-to-support code, but in some cases, a misunderstanding of an abstraction can slow it down. It also happens that analogies fail, especially if the analogist singles out one of the darlings from all that he is trying to pull on everything. You can balance the flaws of the analogist by putting him in tandem with the architect - they either kill each other, or create something outstanding.
Stuntman
He loves spectacular tricks and is constantly in pursuit of technological innovations that deliver them. In fact, there is no real return on this hobby: the stunt man does not know how to think pragmatically, the actual value of this or that technology for the final product and user remains hidden for him. This employee will need to constantly monitor and redirect his enthusiasm to the priority tasks.
Mutts
Rainwater singles out mongrels into a separate category as cats with some obvious flaws, the advantage of weaknesses relative to strengths. But he does not call to get rid of them without looking. Many of the mongrels are quite amenable to training and can gradually be retrained in other breeds. Below we provide forecasts and recommendations for different types.
Slobber
The main provider of sloppy, sloppy code. Often skips from style to style. Like a scorcher, he sacrifices the design and adherence to the agreements adopted by the team, but, unlike the scorcher, he cannot be justified even by the high speed of work. It is his code that sometimes has to be rewritten from scratch - so exhausting and resource-intensive to understand it.
Sloppiness is acute and chronic. If it attacked an employee suddenly, this may be due to personal problems. If this is a usual condition for him, it is worth considering whether it makes sense to spend time on retraining. The main criterion here is the desire and readiness of the sloven to make efforts. A slob, who generally enjoys his work, with due attention from the leader or mentor, may well be rehabilitated and learn more effective working methods.
Brake
For a long time he cannot take on the task, does not know where to start, chases the specifications in the desperate hope that they will bring some kind of clarity. As it is not difficult to guess, the indecision of the brake comes from self-doubt. It is necessary to act here based on where this uncertainty came from. If a developer has failed miserably in the past and is now panicky afraid of failures, let him have the opportunity to prove himself, even in small and uncomplicated tasks, so that this fear gradually disappears. If the matter is inexperience, then with time and the well-known support of the team, everything is likely to normalize by itself. If such indecision is simply a property of character, it is easiest to give the poor fellow a model that will help him choose a style and get to work.
Lover
The amateur does not have enough knowledge, but usually there is more than enough motivation. This species of mongrels is most likely to break into good developers. However, their progress needs to be closely monitored - to assess abilities, to record achievements that give reason to send them to more responsible tasks. One should not too overstate expectations: many are exhausted when faced with difficulties or an inevitable routine in the work of a programmer. Generally speaking, amateurs have their pluses - first of all, the notorious fresh, unashored look, although it can be tiring to wait until they step on all the rakes and comprehend common truths.
Profan
It seems simply dull. Usually, the new leader inherits these from the old one; the story of their placement in the team remains a mystery. To do something for such people is difficult - development requires constant self-improvement, which they simply will not pull. If a layman himself is aware of his level and is not distinguished by inadequate ambitions, you can try to attach him to the testing department - sometimes low abilities do not prevent people from finding bugs properly. Those who are not even aware of their nearness are better off not having to deal with.
Eclectic
A nuclear mixture of an engineer, a sloven and not too talented artist. The code he writes is indigestible vinaigrette from different styles and modules. Unlike products of sloppiness, this is a code with a claim to talent - in appearance it may seem that it even has something in it until you try to run it. The main question of the person reading the eclectic code is: âWhat did he mean?â In order to rectify the situation, you must first understand whether this confusion is really the result of some kind of search, or is there an attempt before you to slobbery over the tracks. Benign eclecticism is greatly benefited by systematic code reviews.
Finally, there is another breed that stands apart from the rest in every sense - this is a cowboy or a lone wolf. Feline habits reach him to the highest degree. In his craft, a cowboy, as a rule, is very good (otherwise he just can not stay in place), in team work - is absolutely hopeless. He is distinguished by his determination to play only by his own rules: to take on projects that interest him, and no other, to use the means he wants, to reckon exclusively with his plans, and so on. There is only one way with cowboys: once and for all to understand that they will not become part of the team, and decide whether you value them enough to put up with their peculiar habits. In general, cowboys are indispensable in two cases: critical, seemingly hopeless situations and isolated projects that will be accompanied by outside experts.
So, we have listed those breeds that the author has encountered most often. However, a few notes should be made to this classification:
- The leader should not consider himself an exception to the rule: he has programming experience, which means that he himself belongs to one of the breeds. This is an important circumstance - his individual approach to writing code will affect the culture of the team as a whole. For example, in a group, a minimalist leader may sag documentation because he never paid due attention to him even in his own work.
- We repeat once more: types are not always pure and unchanging, people often turn out to be more multifaceted than theoretical constructions. It is easiest to judge who belongs to which breed at those moments when individual features are most prominently displayed - with new beginnings and when approaching the deadline.
- If you have to form a team from scratch, keep in mind that the most winning ensemble is architects (strategic thinking), constructivists (elaboration of details) and artists (creative vein). But most likely, you will already have a staffed team, and this is completely normal - you can work together in any team.
- The three main qualities that are needed to work with most breeds are insight, patience and the ability to become a mentor.
With all the fun of this list, it may not be immediately obvious how to benefit from it in everyday work. The author offers a couple of examples with analysis of specific situations that often arise with certain breeds.
Example No. 1
Situation: you have a voluminous code that needs to be upgraded to the current needs of the company, and a minimalist developer who sees it for the first time in his life. The developer claims that the code needs to be rewritten from scratch - everything is too complicated, but you canât go for it: a lot of resources have already been spent on the product. What to do?
Solution: slightly change the task. A minimalist loves clarity, has a weakness for working with architecture - bribe him with several not too expensive and obviously flawed objects or functions, give freedom to reconstruct them at your discretion in the future. Ask to study and document the code, including for this purpose. As a result, the minimalist will be forced to do what he denied - to figure out the miraculous code in order to move on to a more interesting lesson.
Example No. 2
Situation: you disagree with the architect about the solution he implemented. It seems to you that some things are not done in the optimal way, he does not see any problems.
Solution: architects usually have their own vision of the structure - holistic and consistent, but not obvious to the outside observer. If you canât look at the matter through his eyes, do not lead speculative disputes, but rather organize a more substantive discussion. Suppose, ask the architect to describe in detail the mechanism of action, ideally a working prototype or a simple demo version. This will quickly reveal all the implementation flaws, if any, or show your wrongness. Similarly, if the code seems too cumbersome and monolithic to you, suggest breaking it down into components - if it doesnât affect the system, itâs all right.
This concludes the first part of the cycle. Further on, we will discuss topics such as the inevitable evil of technical meetings, according to which scenarios leaders usually go to failure or success, problems that will fall upon the new leader immediately and much more.