Your own project management: working with the developer, part 2
Posted on 13/03/2015
95% of executors’ mistakes are manager's fault.
Irina Petrovna,
the most severe teacher I’ve ever seen.
Hi, my latent reader, I and my cosmic cat Orion go on with the series of articles about IT management. We are very glad a lot of people read our materials and it strengthens and encourages us to write new ones. The recent months we were busy watching ourselves in order to understand some peculiarities of the programmer’s work (or the other worker with a technical sort of mind).
On the third course of the University I first heard the phrase "non-material methods of stimulation". I must confess this phrase gave no rest to me for a few years till I started taking psychology as a science equal to mathematics.
I was mistaken thinking all people work for money and similar assets that can be kept in a pocket.
The programmer's brain as any other IT person's one works in a very peculiar way, but there are some prominent features being aware about gives an opportunity to achieve an effective workflow in a team.
Puzzle as a vision of a work process.
The process of coding is considered by the most of humans to be the extremely boring process which is peculiar to the characters wearing big glasses and greasy T-shirts. Even the experienced developers become bored working everyday under one and the same things not realizing the part of a big way they are at.
I am a proponent of the approach where the executor should be informed without extra details why and where to the project moves on. The executor should see the work he performs is like gathering a puzzle. Every cell serves the common purpose which the executor draws with his own efforts. The cell should be small enough to be executable, but not so small to seem easily available. The manager should divide the large tasks into small ones before giving them to the executors.
Common coding standards
Most of the programmer secretly believes their code is better than the other ones. If you being a manager don't want your employees to waste their time to transform the code in a proper way (according to their own beliefs) I advise to introduce common coding standards. For example I like what colleagues from Kohana suggest for PHP projects (http://kohanaframework.org/3.3/guide/kohana/conventions).
If necessary include this request into the labour contract or to the technical assignment of the project. Why is it so important? The answer is easy: if several programmers work under one and the same code, being the followers of different code styles they will start rewriting each other’s code sooner or later and that will be the waste of time, you hardly need. Besides, they'll almost stop mentioning the difference between each other's code and will stop comparing themselves to the others.
Working Process Determinacy
The headline looks rather 'clever' but the things are indeed very simple.
A technician is a huge fan of an accuracy and definiteness.
The working process in a team should not be interrupted because, for example, the developer needs a test account in the payment system, or because it is not clear how to update the working system trying not to lose the updates having been done by the others.
Manager, remember: if you haven't thought over such working process details the workers (programmers) will do it for themselves but having spent some time.
Working instructions
If you think writing instructions is a complete bore and a waste of time then you hardly ever seen a really growing company.
When a magic moment comes and new people appear in your company you will be surprised after a while how the employees can be wrong about this or that process. The majority of the beginner's questions will be of the same kind and are likely to be repeated. Imagine you have a document (an article, a diagram or a pattern) answering all these questions. You don't need any time for the explanatory work; it will be enough to show where the solving-problem knowledge is.
Besides, the working instructions will be helpful in case of a high turnover.
The human face of management
I think it makes sense to finish my articles with something positive and liberal. For example, a wish to be human to your employees. A manager being an owner of some resources still remains to be a human who can make a mistake. The epigraph I have used is a reminder about the responsibility of managerial decisions. The manager gives a vector of moving the rest serves as the support arrangements of it.
Sergey Koshkarev, March 13, 2015