Although Warren Buffett has an important refinement to consider:
"Somebody once said that in looking for people to hire, you look for three qualities: integrity, intelligence, and energy. And if they don't have the first, the other two will kill you. You think about it; it's true. If you hire somebody without the first, you really want them to be dumb and lazy."
-----
Personally, I think there are some key indicators of how good a place to work is, and they all come down to time:
(1) how long does it take to compile and run the code ... there is simply no substitute when testing for actually running the code, and you should be frequently testing your assumptions. Faster is better. There is a point at which if it takes too long you will be punted from "the zone", and even good programmers will produce either much lower quality code or a greatly reduced quantity (of features fulfilled, I am not so naive as to believe that lines of code measures are important)
I've seen some real horror stories, upwards of half an hour to compile and run... twitch
(2) how long does it take to get a new programmer set up. There are four key hurdles here:
(2a) physically getting them a computer and login
(2b) setting up a development environment
(2c) getting access to shared resources (e.g. CVS passwords) and environments (e.g. dev server login)
(2d) ... forgot what this one was ...
NB: one of the few "Agile practices" that is worth the hot air and spittle is keeping an internal wiki that contains everything the new dev needs. And of course, the first thing you get the new guy to do is to update the wiki
(3) How long does it take the organization to admit to a mistake and change course. If there is a wonky requirement, and it takes weeks or months to get permission to fix it and/or change the spec, they've got issues.
Excellent! :D If this was Reddit, each successive poster would quote N+1 rules for hiring people and/or running an organization. Since this isn't, I will just skip ahead to N = 14
I think the requirement to reward managers for having small (but effective) teams is particularly insightful. We know about Fred Brooks and the Mythical Man Month, and we explain to the managers of our projects that 9 women can't produce a baby in 1 month until we are blue in the face, but they never seem to 'get it'. Surely one of the core problems with them 'getting it', is that even if they really did 'get it', in most organizations the incentive is towards larger groups, not smaller groups.
Economists and psychologists have been telling us that incentives matter for a long time now, perhaps it is time to apply that to an organization structure in a genuinely scientific way.
"Smart and gets things done"
Although Warren Buffett has an important refinement to consider:
"Somebody once said that in looking for people to hire, you look for three qualities: integrity, intelligence, and energy. And if they don't have the first, the other two will kill you. You think about it; it's true. If you hire somebody without the first, you really want them to be dumb and lazy."
-----
Personally, I think there are some key indicators of how good a place to work is, and they all come down to time:
(1) how long does it take to compile and run the code ... there is simply no substitute when testing for actually running the code, and you should be frequently testing your assumptions. Faster is better. There is a point at which if it takes too long you will be punted from "the zone", and even good programmers will produce either much lower quality code or a greatly reduced quantity (of features fulfilled, I am not so naive as to believe that lines of code measures are important)
I've seen some real horror stories, upwards of half an hour to compile and run... twitch
(2) how long does it take to get a new programmer set up. There are four key hurdles here:
(2a) physically getting them a computer and login
(2b) setting up a development environment
(2c) getting access to shared resources (e.g. CVS passwords) and environments (e.g. dev server login)
(2d) ... forgot what this one was ...
NB: one of the few "Agile practices" that is worth the hot air and spittle is keeping an internal wiki that contains everything the new dev needs. And of course, the first thing you get the new guy to do is to update the wiki
(3) How long does it take the organization to admit to a mistake and change course. If there is a wonky requirement, and it takes weeks or months to get permission to fix it and/or change the spec, they've got issues.