365
Cultural codes: what types of programmers are there and how to manage them
Eighty six million fourteen thousand four hundred ninety two
© Weston Doty
American programmers Hank Rainwater works in the profession for over thirty years. When he was promoted to Manager, he had to find a approach to colleagues and find out how to increase their effectiveness. In the end, he became so absorbed in the subject that he wrote the book "How to graze cats. Instruction for programmers, guiding other programmers."An excerpt about the most common types of encoders and what they should expect.
Architect
Most managers love this type of programmers — and, indeed, any such worker would be a valuable acquisition for your team. Basically, the architects focus on the overall structure of the code. They think, and their best friend — a sheet of white paper. Devoting themselves without reserve to the decision of business tasks, they build abstractions, analyze systems, and then move on to coding specific solutions. There are no words — these are all very important elements of programming, but for complex tasks they have not enough. Often highly intelligent architectural ideas embodied in such General and obscure code that people able to understand it and continue with the undertaking, simply is not. Individuals are able to generate a good idea in mind (preferably in Visio), and then perform full specification in code, becoming, thus, the only participants in the process are very rare. The lack of architects that their code frequently serves only one master, and to obey other people's commands flatly refuses. Some architects love to sketch out the structure of the code, in order to subsequently transfer it to the mercy of the programmers of more "low" skills. Sometimes code written by architects, some of them are quite strange design — for example, Windows reports the system interrupts due to errors that appear for the sole reason that the code was supposed to do in a DLL on the server.
Constructivists
Constructivists get pleasure from the process of writing code and its result. Strategic planning they bother not always, but the fact that they do write code quickly and in most cases errors are not detected even at the stage of alpha testing. Code constructivists writing on a whim, but because their logic is not always clear. Some constructivists all right, and with intuition, and strategic planning, so the code acts as a natural extension of the course of their thoughts. But you should ask the constructivist to make the documentation, it will answer that the code is self-documenting. However, if it a little push and make it clear that without documentation there is no escape, he will probably agree it to be — and do it efficiently.
The number of assemblies that constructivist issues of the day, envied by even Microsoft. Accordingly, their code usually is reliable. Yet as the swelling (and this process is inevitable) reliability disappears and the constructivist begins to frantically search for a new "patching" solution — after all, it is very important to see the results and be sure that he coped with the task. Constructivist in conjunction with the architect have the potential to become a great team. If you managed to find the constructivist and architect in one person, consider that the lion's share of staffing problems solved.
Artist
Actually, the art in writing code, not less than science, that's why universities often drive both directions in one structure and call it something like "faculty of liberal arts and Sciences." Don't be in the programming art aspect, maybe it would bring us much less moral satisfaction. The artist as a type of the programmer concentrated on the code generation process — transferring business requirements into program designs and skillful mixing of user interface objects into one graceful structure. Working with components without a visible interface, artists tend to correct and logical organization. The disadvantage of the artist that he often delays the coding, trying to figure out how many equals signs can be placed in one line, without violating the correctness of the result of the Boolean operator. On the other hand, if the programmer did not cultivate the artist, its results often deviate from reality, lose their "flavor". Should the artist take all his distinguishing qualities, and the result is a time bomb that will explode under your fingers users. Sharing some characteristics of constructivists and architects, artists actively claim their own style.
Engineer
Engineers you like. These guys tend to buy all the possible third-party tools, writing dozens of com objects and editing them together so that they work fine in version 1. Their inherent desire for complexity is manifested only when it comes to version 1.1. Programming is often equated to engineering software — and, indeed, many aspects of our profession are subject to this methodology. But give the engineers carte Blanche impossible. In the software engineering methods are built, there is nothing wrong — in the end, according to the classical definition, engineering is the scientific principles involved in solving programming tasks. We need programmers who are not afraid of difficulties, but those who like to complicate everything, pose a serious danger.
Don't get me wrong: I'm not going to throw a dig at engineers. In the end, I myself for many years worked on the hardware of computers. But the hardware orientation sometimes conflicts with those aspects of the software due to which it becomes programmed (i.e., a flexible and reusable). Every hardware device is usually a single, clearly defined purpose, and for the software, this approach is unacceptable.
Scientist
Scientists are boys and girls who consider themselves followers of Babbage and Turing. Never in my life they will not insert in the code, GoTo. Pushing the artistic component of programming in the background, they do everything in accordance with the fundamental principles of computer science. And this usually is a problem. While they are obsessed with the perfection of their work, your main concern as a Manager is to develop a benign product, and hand it in by the deadline. Programmers of this type is actually very useful, and when it comes to the particularly difficult task of encoding their ideas. You just have to ensure that their pedantry is not outweighed practical considerations. Engineers and scientists have one thing in common — they both love to complicate things. Sometimes it even seems that they all worship the God of complexity (and even sacrifices!).
Scorcher
Cabs — they are the friends who do everything quickly. Forgetting about comments, indentation and variable naming conventions, they nevertheless manage to achieve results very quickly — and, most wonderful, until the first uncaught error, their products work quite successfully.
Sometimes this behavior is typical for young programmers, eager to impress you, they rashly think that the efficiency in achieving the result fully meets your expectations. Admit it: we often build themselves they have such a false idea, and so we behave differently, no speeders would not be. Our own heads arrange meetings and set deadlines, and then misleading them to us. How are we gonna accomplish temporary tasks — it is our problem. Remember how often there is talk about the absurdity of setting deadlines for coding until all requirements! So, you will have to get used to it. Unfortunately, that is the reality of users and market considerations often force us first to make promises, and then start planning. That is why you are reading my book — you need advice about how to survive in a dynamic, violent and harsh world of software development.
How to deal with the representatives of the different breeds
Programmers are first and foremost people. So one person can be more or less expressed all of these characteristics. Some of them are as if mutually exclusive, but in fact it is not.
All people are made of contradictions, and your employees are no exception. From you as a person directing these wonders of nature, requires understanding, ability to motivate and, above all, the wisdom that is acquired only with experience. Opinions about the programmers have to be on those facets of their character that is brighter than the other sparkle in the light of new beginnings and blinding flashes of projects approaching delivery.
Suppose you have a great opportunity to recruit staff in your Department with a "clean slate". What breed mixes better? In my opinion, it is best to strike a balance between the architects and constructivists. These two breeds bring to the process of creating software products most in demand skills — think strategically first, the second are well-versed in the details. To this Alliance from time to time it makes sense to connect artists. Unfortunately, most likely, to pick up a group of ideal candidates will fail. You have to work with what we have. Because the success of your interactions with people, combining the aforementioned characteristics, depends on your insight, patience and skill to be a mentor for subordinates — that is, from the three universal qualities of leadership.
There is another type of person, you should pay special attention. I mean programmers cowboys. This type does not agree with the listed species, and to describe it better in line with the view that cowboy about yourself forms. So, the programmer-cowboy usually fluent in their craft, but to manage them is virtually impossible. The cowboys are deeply convinced that can work only on those projects that want to do it on your own terms, agreeing only with their own plans and referring only to appropriate in their view means. A programmer is a kind of a lone wolf (or, to adhere to the terminology of this book, the cat who walks by himself). Depending on what you need, and your willingness to tolerate the uniqueness of their personality, the cowboys can do either wonders or stuff. Cowboys need to keep your eyes open: they under no circumstances do not become part of your team. To use their services is either in desperate situations or if the project should be radically different from all others, and he will be accompanied by third-party experts.
Why the programmers and combines all these extremely entertaining personality? I think this is due to the fact that the nature of the activities of the software developer attracts people of a very definite kind. In his classic work "The Mythical Man-Mouth" by Frederick Brooks (Frederick Brooks) argues that our craft brings pleasure to people five types:
— The joy of creation.
— The joy of creation is useful for other people's products.
— The attractiveness of the process of organizing different objects, consisting of interrelated dynamic elements.
— Joy from the constant acquisition of new knowledge and solutions to non-standard tasks.
— Interest in working with products created exclusively by the application of intelligent human effort, which, however, exist, develop and do absolutely incredible things.
All these factors seem to be the people that you lead, is extremely attractive. Understand their motivations (and his, too), you will be able to strengthen its position as a leader.
Source: theoryandpractice.ru
© Weston Doty
American programmers Hank Rainwater works in the profession for over thirty years. When he was promoted to Manager, he had to find a approach to colleagues and find out how to increase their effectiveness. In the end, he became so absorbed in the subject that he wrote the book "How to graze cats. Instruction for programmers, guiding other programmers."An excerpt about the most common types of encoders and what they should expect.
Architect
Most managers love this type of programmers — and, indeed, any such worker would be a valuable acquisition for your team. Basically, the architects focus on the overall structure of the code. They think, and their best friend — a sheet of white paper. Devoting themselves without reserve to the decision of business tasks, they build abstractions, analyze systems, and then move on to coding specific solutions. There are no words — these are all very important elements of programming, but for complex tasks they have not enough. Often highly intelligent architectural ideas embodied in such General and obscure code that people able to understand it and continue with the undertaking, simply is not. Individuals are able to generate a good idea in mind (preferably in Visio), and then perform full specification in code, becoming, thus, the only participants in the process are very rare. The lack of architects that their code frequently serves only one master, and to obey other people's commands flatly refuses. Some architects love to sketch out the structure of the code, in order to subsequently transfer it to the mercy of the programmers of more "low" skills. Sometimes code written by architects, some of them are quite strange design — for example, Windows reports the system interrupts due to errors that appear for the sole reason that the code was supposed to do in a DLL on the server.
Constructivists
Constructivists get pleasure from the process of writing code and its result. Strategic planning they bother not always, but the fact that they do write code quickly and in most cases errors are not detected even at the stage of alpha testing. Code constructivists writing on a whim, but because their logic is not always clear. Some constructivists all right, and with intuition, and strategic planning, so the code acts as a natural extension of the course of their thoughts. But you should ask the constructivist to make the documentation, it will answer that the code is self-documenting. However, if it a little push and make it clear that without documentation there is no escape, he will probably agree it to be — and do it efficiently.
The number of assemblies that constructivist issues of the day, envied by even Microsoft. Accordingly, their code usually is reliable. Yet as the swelling (and this process is inevitable) reliability disappears and the constructivist begins to frantically search for a new "patching" solution — after all, it is very important to see the results and be sure that he coped with the task. Constructivist in conjunction with the architect have the potential to become a great team. If you managed to find the constructivist and architect in one person, consider that the lion's share of staffing problems solved.
Artist
Actually, the art in writing code, not less than science, that's why universities often drive both directions in one structure and call it something like "faculty of liberal arts and Sciences." Don't be in the programming art aspect, maybe it would bring us much less moral satisfaction. The artist as a type of the programmer concentrated on the code generation process — transferring business requirements into program designs and skillful mixing of user interface objects into one graceful structure. Working with components without a visible interface, artists tend to correct and logical organization. The disadvantage of the artist that he often delays the coding, trying to figure out how many equals signs can be placed in one line, without violating the correctness of the result of the Boolean operator. On the other hand, if the programmer did not cultivate the artist, its results often deviate from reality, lose their "flavor". Should the artist take all his distinguishing qualities, and the result is a time bomb that will explode under your fingers users. Sharing some characteristics of constructivists and architects, artists actively claim their own style.
Engineer
Engineers you like. These guys tend to buy all the possible third-party tools, writing dozens of com objects and editing them together so that they work fine in version 1. Their inherent desire for complexity is manifested only when it comes to version 1.1. Programming is often equated to engineering software — and, indeed, many aspects of our profession are subject to this methodology. But give the engineers carte Blanche impossible. In the software engineering methods are built, there is nothing wrong — in the end, according to the classical definition, engineering is the scientific principles involved in solving programming tasks. We need programmers who are not afraid of difficulties, but those who like to complicate everything, pose a serious danger.
Don't get me wrong: I'm not going to throw a dig at engineers. In the end, I myself for many years worked on the hardware of computers. But the hardware orientation sometimes conflicts with those aspects of the software due to which it becomes programmed (i.e., a flexible and reusable). Every hardware device is usually a single, clearly defined purpose, and for the software, this approach is unacceptable.
Scientist
Scientists are boys and girls who consider themselves followers of Babbage and Turing. Never in my life they will not insert in the code, GoTo. Pushing the artistic component of programming in the background, they do everything in accordance with the fundamental principles of computer science. And this usually is a problem. While they are obsessed with the perfection of their work, your main concern as a Manager is to develop a benign product, and hand it in by the deadline. Programmers of this type is actually very useful, and when it comes to the particularly difficult task of encoding their ideas. You just have to ensure that their pedantry is not outweighed practical considerations. Engineers and scientists have one thing in common — they both love to complicate things. Sometimes it even seems that they all worship the God of complexity (and even sacrifices!).
Scorcher
Cabs — they are the friends who do everything quickly. Forgetting about comments, indentation and variable naming conventions, they nevertheless manage to achieve results very quickly — and, most wonderful, until the first uncaught error, their products work quite successfully.
Sometimes this behavior is typical for young programmers, eager to impress you, they rashly think that the efficiency in achieving the result fully meets your expectations. Admit it: we often build themselves they have such a false idea, and so we behave differently, no speeders would not be. Our own heads arrange meetings and set deadlines, and then misleading them to us. How are we gonna accomplish temporary tasks — it is our problem. Remember how often there is talk about the absurdity of setting deadlines for coding until all requirements! So, you will have to get used to it. Unfortunately, that is the reality of users and market considerations often force us first to make promises, and then start planning. That is why you are reading my book — you need advice about how to survive in a dynamic, violent and harsh world of software development.
How to deal with the representatives of the different breeds
Programmers are first and foremost people. So one person can be more or less expressed all of these characteristics. Some of them are as if mutually exclusive, but in fact it is not.
All people are made of contradictions, and your employees are no exception. From you as a person directing these wonders of nature, requires understanding, ability to motivate and, above all, the wisdom that is acquired only with experience. Opinions about the programmers have to be on those facets of their character that is brighter than the other sparkle in the light of new beginnings and blinding flashes of projects approaching delivery.
Suppose you have a great opportunity to recruit staff in your Department with a "clean slate". What breed mixes better? In my opinion, it is best to strike a balance between the architects and constructivists. These two breeds bring to the process of creating software products most in demand skills — think strategically first, the second are well-versed in the details. To this Alliance from time to time it makes sense to connect artists. Unfortunately, most likely, to pick up a group of ideal candidates will fail. You have to work with what we have. Because the success of your interactions with people, combining the aforementioned characteristics, depends on your insight, patience and skill to be a mentor for subordinates — that is, from the three universal qualities of leadership.
There is another type of person, you should pay special attention. I mean programmers cowboys. This type does not agree with the listed species, and to describe it better in line with the view that cowboy about yourself forms. So, the programmer-cowboy usually fluent in their craft, but to manage them is virtually impossible. The cowboys are deeply convinced that can work only on those projects that want to do it on your own terms, agreeing only with their own plans and referring only to appropriate in their view means. A programmer is a kind of a lone wolf (or, to adhere to the terminology of this book, the cat who walks by himself). Depending on what you need, and your willingness to tolerate the uniqueness of their personality, the cowboys can do either wonders or stuff. Cowboys need to keep your eyes open: they under no circumstances do not become part of your team. To use their services is either in desperate situations or if the project should be radically different from all others, and he will be accompanied by third-party experts.
Why the programmers and combines all these extremely entertaining personality? I think this is due to the fact that the nature of the activities of the software developer attracts people of a very definite kind. In his classic work "The Mythical Man-Mouth" by Frederick Brooks (Frederick Brooks) argues that our craft brings pleasure to people five types:
— The joy of creation.
— The joy of creation is useful for other people's products.
— The attractiveness of the process of organizing different objects, consisting of interrelated dynamic elements.
— Joy from the constant acquisition of new knowledge and solutions to non-standard tasks.
— Interest in working with products created exclusively by the application of intelligent human effort, which, however, exist, develop and do absolutely incredible things.
All these factors seem to be the people that you lead, is extremely attractive. Understand their motivations (and his, too), you will be able to strengthen its position as a leader.
Source: theoryandpractice.ru
