On Managing Developers

> Testing is really important, but few developers like to write tests. That means it’s your job.

As a leader of an engineering team (and an engineer), I think the is this is entirely the wrong approach. It's a leader's job to get the team to understand why writing tests is important and have them write them. Sometimes an individual isn't a great fit on the team and you need to figure out how to handle it (i.e., they refuse to write tests but the rest of the team is).

There are few points in this article that resonate - but there are many that are complete off base such as

> Managers translate the project’s Big Picture into individual tasks for developers, with their details and interactions specified in minute detail

I agree that leaders/managers translate the big picture to developers (provide vision) - but the team should figure out the minute detail - otherwise you're removing autonomy, the ability to fail, and are yourself falling into the pit of micromanagement.

Good article.

> Few developers like to write documentation. That means it’s your job.

OMFG. Most traditionally-trained devs I've met in person are next to illiterate. Bizarrely incompetent at docs. Unsurprisingly their code quality stinks too.

They'd probably ridicule you for mentioning "programs must be written for people to read, and only incidentally for machines to execute". (Unless you say you're quoting "the Wizard Book", because they defer to argument from authority.) Read my sourcecode, they say, as if that doesn't mean "Go fuck yourself".

And they simply never want to proactively improve. That would require introspection and self-critique. Pulling teeth.

I agree with a lot of this. One thing I would add - it's your job to integrate development into the rest of the organisation. UX, design, marketing, sales. Failure to do so leads to animosity between development and the rest of the organisation. Animosity undermines the goals of the organisation. In my experience, the biggest issue to deal with when managing developers is that they feel like they're tasked with implementing stupid ideas created by idiots. its never that simple, and developers are generally rational people who, given all the facts, know when to digg I. And resist something, and when to swallow a bitter pill for the greater good.

Managing developers is easy. Managing the rest of the company so the developers can do their job is the hard part.

> Not a coder yourself? Learn enough to at least write tests.

No, please.

It is a good point that being a manager one would have more influence, but that's only true if you are technically and socially respected by your fellows/peers/workers. Sometimes this means you have to really do your homework and work maybe twice as hard as your developers so you don't just ask questions and assume they are right. You have to be a hard ass, keep asking, demand clarity, and always be a hard ass to get things done properly.

I came to the project only a few months ago. The project was "90% finished" but full of bugs too. We recently went live anyway. In the meanwhile, I have asked the manager/client for finding help with QA, because it is quite hard to maintain overall consistency in the system. The smallest changes create big bugs elsewhere. It is not enough that he or me do the testing. We never test enough anyway, and we still regularly hit the live servers with bad bugs that cost money. The system is meant to process money, actually. That is its core task. The problem is that my request for having QA people helping out, would cost resources, and that the recruitment process for QA profiles does not seem particularly easy either. Then, there's also the situation with the graphical designer who seems to hate programmers, and never shows up when he said he would. I think that a good manager will find a way to put the right people in the right place at the right time.

The problem with this kind of article is the author rarely considers/explains the context.

E.g. Managing a team of 10 developers at a company with 30% turnover is very different to managing a team of 3 developers at a company with 5% turnover. Approaches and techniques vary drastically based on context.

Let's try to use the classic analogy with painters.)

Suppose "your team" have to paint a cathedral for a king and you are the "manager". Of course you cannot paint yourself and hence holding an opinion that the paints and brushes are the most important things in this business.

Nevertheless, you have noticed, that some guys, like Leonardo, are much better at painting of the ceilings and in order not to disappoint the king you have to hire him and all the second best guys. Of course, you are sure that these guys are just lucky and overrated.

What you ougth to do, in order to not be beheaded by the king, is to be sure that Leonardo and the other painters has everything they need, of best possible quality and there is not a single obstacle on the horizon.

Now imagine that instead you have decided to hold daily meetings to discuss how to mix the paints properly, about responsibility to the whole team, and importance of writing daily reports about elements finished so far, together with detailed statistics of materials spent on each element.

To be sure that everything is going well, you have to climb to the ceiling few times a day and ask smart, psychological questions in orfer to avoid any possible lapse in productivity by exercising employee's morale and dedication to the project. For that reason you have short meetings in the morning.

Because you have no idea why the masterpieces of these guys are so highly acclaimed, you are constantly trying to improve their decisions by introducing new elements and changing colors, which are, you have been told, are industry standard best practices, and forcing them to use not the paints they used to, but guaranteed, safe, battle-tested priducts they used to paint the walls of the king's palace and stables.

Stop with the management already.

If you look at a company of say 100,000 employees, and a generous span of 1 manager to 10 subordinates, there are 33,333 managers - and as they usually are paid better than their subordinates, the cost is typically over 50% of salaries. And it's a rare industry that is not mostly salary as cost.

And we now have an amazing set of technologies and examples of new organisational forms (Linux?) that say "hey, you can eliminate a huge cost base and be more productive.

Wanna bet how the next decade is going to go for those called "managers"?

Is the dev-manager dynamic something like:

In school, most people don't get the project done unless there's a deadline imposed upon them by someone else. And in the professional world that someone else here is the manager..?

> Managers translate the project’s Big Picture into individual tasks for developers ... As any professional translator will tell you, this means you need to understand the work more intimately than the author.

Such manager doesn't exist in the current development biotope.