
On Managing Developers - isalmon
http://techcrunch.com/2015/06/06/on-managing-developers/
======
mbernstein
> 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.

~~~
developer1
> few developers like to write tests

I like how this statement completely skips the reason why developers don't
like to write tests. The majority of managers refuse to allocate any time to
write any tests. Hell, when we come up with a 6-week estimate for a project,
they then tell us we must do it in 4. At 4 weeks, the complaints and blame
game begins over why the project isn't completed. Why? Because it was a 6 week
project, morons.

I've only had one company with management that wanted unit tests written for
code. Yet there was no official time dedicated to this process. That 6-week
project that would be estimated without unit tests? Still 4 weeks. Huh? What
magical world do you live in?

Quality requires time. That 6 week project now needs 8-9 weeks. Not 4. Not 5.
Find me management that understands this and actually cares about quality
instead of impossible deadlines that fit their fantasy plan for the current
quarter, and we'll talk.

To be clear, I love writing tests. I would always have them if the decisions
for project deadlines were left to me. Such decisions are out of my control,
so the company gets what they are willing to pay for.

~~~
vinceguidry
That's not the only reason. Writing tests is _hard_.

Writing tests that are not highly coupled to implementation is hard. That
means that every time you change the system, you have one or many test changes
to make too.

How do you know what to test and what not to test? How many tests do you
write? One line of code can, if you think about it exhaustively, require 3 or
even more tests.

A lot of time you'll write code that facilitates testing. Do you test this
code? What happens if the code silently fails and now you don't have proper
test coverage of all the code paths said code is supporting? This is
particularly true if you are mocking objects.

Learning how to test, properly, is almost as hard as learning how to code. My
advice is, if what you're doing is boring, like most Rails apps, lean on the
library as much as possible, break up anything that goes against the grain
into unitary features, and test them each in turn. You don't need to test that
ActiveRecord.belongs_to works.

It doesn't surprise me that there's developer reticence towards testing. I
tried powering through that reticence, believing there's some "magical world"
as you put it, where testing actually helps you code faster and more
accurately, but I found even myself a TDD apostate, I don't even do it for my
own projects anymore.

~~~
developer1
Technically these issues are solved with what I indicated is always missing:
time. What you outlined is accurate: proper testing also requires proper
_planning_ for tests. For more complicate projects, you don't just start
writing them without mapping out everything that needs to be done - and how to
go about it. And yes, when code changes, more time must be invested into
refactoring the tests.

This disastrous ecosystem exists with QA too (which is again, a form of
testing). A lot of companies - usually the smaller ones - don't invest any
resources at all for QA. Others just do point-and-click smokescreen tests
that'll discover bugs that are blatantly obvious (also typically the ones the
developer should never have committed to begin with). Real, proper QA? That
requires investing serious time into test cases - completely figuring out
every possible interaction and scenario that can take place. All before a
single actual test is run. And similar to unit/functional tests, QA test cases
need to be reviewed whenever the smallest bit of functionality changes.

The reality is that most employers who "want test cases" want there to be a
magical solution that gives all the benefits, without any effort.

------
calibraxis
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.

~~~
vinceguidry
You have to work within people's limitations, that is, if you can't pick the
people you work with. A team is only as good as it's most competent member's
willingness to pull everything together and inspire the less-motivated to
perform at a higher level. That's leadership, and there's precious little of
it anywhere, even (especially!) in the products we use every day.

If there's no real leadership, then you're stuck in the backwaters of being
managed. My advice is if you find yourself in this situation, either use it as
an opportunity to work on your leadership skills or check out and throw your
passion into side projects.

~~~
calibraxis
Excellent points! Maybe anyone who decides to "check out" should consider
getting physically away from the team, if possible. Find those who proactively
help others and apply healthy self-critical thinking.

Kathy Sierra in "Badass: Making Users Awesome" said: _" An important,
unconscious way to develop expertise is being around high-quality, high-
quantity examples of expertise."_ The flipside is apparently true: exposure to
mediocre examples begets mediocrity.

------
tomelders
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.

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

~~~
borski
Then you've never managed developers. Speaking as one, developers are not
always right, and as human beings they are subject to emotion. Emotions make
people hard to manage. Period.

~~~
MaulingMonkey
Seeing the difference between effective and ineffective management, and the
frequency of the latter, I'm not convinced it's easy either.

Some developers aren't great at gathering requirements, estimating costs,
triaging requests, saying no, or any number of other things... if only because
they'd rather be coding. And that's not even getting into what they can mess
up when it comes to the actual development portion.

A good technical manager can help cover for their shortcomings, and let them
focus on their interests - what they're good at. They're not just an ablative
meat shield.

~~~
dlitz
> Some developers aren't great at gathering requirements, estimating costs,
> triaging requests, saying no, or any number of other things...

To be fair, nobody is great at those first two.

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

No, please.

~~~
robotkilla
Not a doctor yourself? Learn enough to at least diagnose.

~~~
alexqgb
For a hospital manager, that's actually not bad advice.

~~~
taeric
Is it? I'd be interested in any numbers surrounding the idea.

~~~
alexqgb
You shouldn't need numbers to evaluate a proposition with a premise that is
self-evident.

I mean, correct diagnosis is one of the first and most fundamental things a
hospital does when admitting patients. Failure at this stage cascades through
every step that follows, possibly with fatal consequence.

If you're "managing" a place that handles this work without a working
understanding of the process involved, there's a very good chance that
failures can be traced - in large part - back to your desk.

~~~
taeric
I have grown to not believe in anything as self evident, anymore.

Directly to this premise. Correct diagnosis is a _difficult_ and often _error
prone_ things that a hospital can do. To think you can train someone to be a
manager and be good at diagnosis is putting a lot of trust on someone.

Should they be able to help? Certainly. But, at some level, I would expect the
manager to be better at knowing which doctor to get you in touch with moreso
than how to do the diagnosis themselves.

~~~
alexqgb
I think there's an important difference between knowing how to do something
well (i.e., on a professional basis), and having a basic working understanding
of what the process involves; its inputs and outputs, the most significant
enablers of success, the most pernicious sources of failure.

When it comes to the people I manage, I don't need to be able to do their job,
but I do need to be able to speak their language and understand their concerns
well enough to see the task from their perspective.

I should add that this has always been self-evident to me. And it's always
worked very well. But I should also note that it's not the norm, and when
people I work with discover how much I know about what they actually do,
they're almost always pleasantly surprised. "Oh", they say "you really get
it."

Nearly everything about management gets easier if you're starting from there.

~~~
taeric
Ok, so the misunderstanding was that I took your statement to mean they should
be able to diagnose.

So, yes, we are in agreement. :)

------
yeukhon
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.

------
gizi
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.

------
sheepmullet
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.

------
dschiptsov
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.

------
lifeisstillgood
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"?

~~~
carrotleads
I have never understood why managers need to be paid higher than the people
they manage..

That is the single reason for many orgs screwing up their system as this
forces excellant developers/workers to abandon their core skills and move into
management..

~~~
neverartful
It does not force techies into management unless it's an 'up-or-out' kind of
organization. It provides a financial incentive (and often a status symbol).

~~~
marcus_holmes
the manager's salary becomes a ceiling for the staff they manage, if managers
are always paid more than the staff they manage (and I've heard some managers
seriously suggest that they would not be able to manage people who got paid
more than them).

It becomes a problem when tech salaries are on the rise, because at some point
the company either has to start paying coders more than managers, or has to
implement pay rises throughout the management hierarchy in order to retain
good technical staff.

At this point its really tempting to promote good coders into management to
keep them.

~~~
curun1r
> I've heard some managers seriously suggest that they would not be able to
> manage people who got paid more than them

This is just greed/pride. As a manager, the only person who knows that an
engineer makes more than you is you. And it's pretty common these days for
companies to have an engineering track that has a VP-equivalent top position,
so it's pretty common that the most senior engineers will make more than most
of the managers at the company.

------
uptownfunk
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..?

~~~
taeric
School is unique in that most of the questions/projects you will be faced with
have a pretty solid answer. Often times a definitive one. Work... not so much.

------
ExpiredLink
> _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.

~~~
hkarthik
Nor should it.

As a manager, I try to let the team and the PM work out the individual tasks,
and ensure there is consensus and follow through by individuals. Handling
external pressures, clearing roadblocks, and resolving team conflicts are
where I feel that my time is best utilized.

~~~
Moru
Yes exactly. Developer and Manager is two completely different jobs. Developer
to manager promoting is a brain drain. A good developer does not have to be a
good manager. A good manager does not have to be a good developer.

