"Managing developers is like herding cats."

I had a huge amount of luck in my first job to have a manager who was perfectly able to "herd cats". He created a, let's say, protected environment in which we "cats" could work undisturbed from corporate politics and management games. He was the interface between us developers and the rest of the company, talking "management speak" to other managers and talking "developer speak" to us. As a developer, he was not more than average, but excellent as a developer manager.

These conditions allowed good team work in a very competitive company environment. On the day he left, we hacked the intranet, his mental child, to show a black ribbon on the logo.

I left a few years after him, got a few other jobs, the previous and worst one lead by a perfect example for the Peter principle: An old guy at the dead end of his career, lacking both development and management capabilities, who got his management position simply by the fact that he "founded" the IT depeartment in his younger years. His main work principle was to start extinguishing the largest fire first, whatever that may be. As soon as that fire is reduced, the now largest fire has to be extinguished. Feel free to imagine how software looks and works after three decades in this environment. You won't even come close to the sad reality.

In my current job, my manager is one of two company owners, the other owner just gives his name and title. We are a very small team, creating high quality hardware and software for environments where bugs can hurt or sometimes kill users of our devices. We work in a very familiar atmosphere, and this is intentional. New interns and job candidates are choosen not only by qualification, but also by how good they fit into the "family". If you are the perfect developer, creating perfect, error free software in no time, but behave like an asshole, you won't be hired.

We split the software into parts during the design phase, and only one developer is responsible for implementing one part. Peer-reviews are part of the development phase. Bug fixing is often done by the responsible developer, but any developer with some free time fixes bugs in any part of the software.

During development and debugging, we discuss problems quite often, so that each developer has at least a good idea of how other parts of the software work. "Pair programming" happens only spontaneously, mainly during debugging. The fact that both developers know how the software should work, but only one knows the exact implementation at that time, is helpful. It naturally makes the other developer ask for implementation details, and forces the first developer to rethink how his code works. My manager also works as a developer, and so his work is subject to peer review and pair debugging as any other work.

Management of developers feels like it does not happen. We have a lot of freedom, and we are very aware that this freedom is not standard. At the same time, we are very aware of the fact that bugs could kill. We take a lot of responsibility. And I think this is part of how to manage developers.

You can't do a good job as a developer in a team where management does a bad job. Micromanagement is as worse as ignoring the problems of the developers. A manager who thinks is job description is "drill sergeant" won't be able to manage a team of developers. Developers are at least as individual as cats can be.

So, in one sentence, to work as a developer or programmer in a team, you need a good manager.

Alexander