Wednesday, August 29, 2007

Joel on "Productivity in software developers"

There's ... enormous variation in different people in software development. Sometimes one person may be able to accomplish something in three weeks that somebody else would take a year doing. But that other person might be able to do a different thing in three weeks that the first person would have taken a year to do.

Not only are there enormous differences in productivity, but there are enormous differences in personal skill sets and in personal aptitude for certain things. And the work we're doing is just very weird and not easily controlled in an experiment. To do controlled experiments is almost impossible.

There's not a whole lot of data out there. The only evidence there seems to be is that it's very easy to find orders of 10 differences in productivity, and nobody knows why, and being faster or slower doesn't necessarily mean you do a better or worse job.

-- From "A Conversation with Joel Spolsky" in ACM Queue.

Joel on "Things that developers need in an effective manager"

BF What are the things that developers need in someone to manage them effectively?

JS That's a good question. I always think of it as more of a support role - like moving furniture out of the way so they can get things done - than an actual leadership role. Some of the support that developers may need is, for example: "We need to resolve the text of this error message." This is not something that computer programmers are necessarily good at, so just give them the error message and let them move on to the next thing.

To the extent that managers can actually make decisions for programmers, they are very low-level, mundane decisions that allow the programmer to move on to the next task. In terms of decisions about algorithms, about the big picture, structure, code, it's probably a very bad idea for management to make those decisions. I see two roles for a manager of developers: number one, keeping a useful and assorted queue of things for the developers to be working on, so that they can pick things off the top of the queue and do them next; and, second, basically being there to answer developers' questions.

-- From "A Conversation with Joel Spolsky" in ACM Queue.