How to Keep Crappy Programmers
codeanthem.com
codeanthem.com
It is easy to say, "I'm only going to hire self-motivated people and if they can't get the work done they're fired." But the reality is most people aren't like that. And it's a hassle to have to fire people if they can be productive with more management.
So I'm not sure what the best way to handle this is, but I think HN would be better served by an actual discussion of practical solutions rather than rants by disaffected programmers howling with rage at being asked to keep regular hours. On the employee side, I still believe doing really good work solves pretty much all of your problems if you can effectively communicate what you're doing to the manager (and put in the required time). On the employer side, giving people a bit of slack (30 minutes), a fair degree of autonomy and coming down on them hard if/when they miss their deadlines is the best I've been able to come up with. I'd welcome a better discussion of this since as a manager I don't want to have to waste my time micromanaging this stuff either.
Make it clear that it is a privilege which can be revoked. This lets your alpha programmers who like to work odd hours excel and keeps your mediocre programmers who might be tempted to mail it in from even trying it (because there's nothing mediocre devs loath more than heightened scrutiny).
"Thanks to Bob working to 3am this morning we are all set to give the demo to XYZ"
Do that before Bob comes in at lunchtime an he get treated like a hero rather than being resented. If Bob is always working funny hours then after a while people accept it and assume that he has always been doing something heroic when he comes in at lunchtime.
Of course, being the manager of such folks you actually do have to be able to know that all this is actually worth it from a business perspective.
This illustrates one of the attitudes I believe the OP is satirizing: that butt-in-seat time is equal to work time.
Programming[1] isn't a profession where one stops being productive just because the keyboard isn't under the fingers. Even if it were, the office is far from being the only place a keyboard is located.
[1] and perhaps all creative endeavors
Personally, I think the poster is wrong to complain about not being allowed to work 30 hours a week when he has a fulltime job, but that's his issue with his employer. In my experience, if you want to rock the boat, you've got to be able to manage the communication and signaling problems that creates in the workplace. This guy is offloading that problem to his manager and doesn't seem to understand the issues he might be creating. So it isn't that I don't understand his point. It's that I don't think his sarcasm offers any practical advice for the people he's complaining about other than "let me do it my way".
I didn't find him to be complaining about anything per se, nor mentioning "fulltime job":
Never mind that a good programmer can produce more valuable work in a 30-hour workweek from home than a crappy programmer can toiling 60 hours in the office.
Rather, he's pointing out a contrast between two extreme, but plausible, situations.
This guy is offloading that problem to his manager
What's the manager's job if not, as you put it, to manage the communication and signaling problems that creates in the workplace? Still, I come back to the impression that you're thinking about this out of context:
doesn't seem to understand the problems he might be creating.
Again, I allege that's not the programmer's job. The programmer's job is to create, and the manager's job is to maximize the creativity while minimizing problems.
It's that I don't think his sarcasm offers any practical advice.
I agree that the practical advice may be masked by the tone or form.
This is the advice as I interpret it:
If you want to maximize the productivity of your programmers and ensure the most talented and most producive ones stay, avoid the listed behaviors, even if there are some negative consequences. If your business is software, I have a hard time believing that "general productivity" among the others in the office would improve enough to offset getting rid of someone working on the core competency.
On the other hand, I could easily imagine a situation, however, where this is not the desired outcome, such as in a company where software is only a minor component. In that case, your firmer hand on scheduling seems far more beneficial.
The problem I think people will have with this article is that he doesn't acknowledge this point.
If I understand you correctly, you're saying that you allow the team to use an individual as a scapegoat and not take responsibility for their own actions.
Could you elaborate on this? Why do you think this is the best course of action rather than dealing with the people that are not being responsible for their own work? If you let people get away with not taking responsibility once, won't they continue to do it in the future?
Despite disagreeing in principle with the OC, I don't think this is at all what he was suggesting.
Rather, he was presenting a "view from the top," where if he were to perceive a negative influence (whether or not the influenced parties were, themselves, aware), he would eliminate it.
Perceptive point by mmt - I do most of the programming work myself. I don't know if I'd feel the same way if a critical employee doing coding for a major system behaved this way.
I wouldn't knowingly hire someone like that though, and unless someone was truly critical, I'd rather send them on their way than have them create a situation in which their behavior negatively affected office norms, yes. My business is quite small and doesn't have professional managers, so mmt's expectation that there is a level there to deal with this stuff is wrong. Problems are just more work on my plate and distract from the things that people pay us for.
That's the problem with articles like these that they treat all programming equally. What's appropriate in one setting or for a particular developer is not appropriate for everyone.
That being said, if you can't allow your developers some flexibility and rely on them to behave like responsible individuals (re: internet access or time keeping) then the problem is with your staff and no amount of strict policies will fix that.
I still laughed at the article though.
In my experience, a lot of business people don't really know what is possible so their solutions aren't always that good.
Example: "I need to know if I own more than 3% of a company. Give me a report that tells me what percent I own of each company. " "How about a big flashing light or warning if you own more than 3% (or set it at 2% so you know when you are getting close) so that you don't need to spend time each day looking at the report."
You still want to interact with the customer whenever possible, but not so much so that you can't get anything done!
It is often the only way to find out what type of "employee" you want to be. (environments, coworkers, projects, schedule etc.)
Or, it will motivate you to become self-employed or launch your startup and do things differently :-)
What about the programmer who comes across as being a prima-donna about introducing some flavour-of-the-month practise, but who isn’t able to justify it in terms of measurable impact on the bottom line to (say) a small business owner. Often they’ll be right, but frequently they’ll be wrong too. I’ve often been guilty of this as a programmer–I want to change some code to make the design more elegant, add more tests etc, but if pressed it’s hard for me to say whether the improvement adds any value for the business. Sometimes it will, sometimes it won’t. Sometimes despite its value the opportunity cost may be too high. Either way as a ‘good programmer’ I will feel strongly about the matter, and it’s my boss’s job to try and temper that programmer “I only want to work with good code!” gut feel with a bit of business-oriented practicality.
So yes, the extent to which you indulge the 'great programmer' is always going to be a tricky call, especially for the non-technical, or even the technical-but-non-specialist. On the one hand you don’t want to piss off the talent–and let’s face it, some (not all!) of this stuff really is just that, in the same way a hollywood producer lays on whatever perks the best actors demand. On the other hand you need to have confidence that there’s real business value in activities that are being proposed. Or if not immediately demonstrable value, a way to measure reasonably objectively over time what impact they’re having. For example, Google (from what I hear) have an amazing system to measure (in some reasonably useful sense) the value of every test that gets written.
On top of that, sad truth is that a lot of companies don’t actually need great programmers. Sure, all else held equal they’d like them, but they’re expensive, they often want to spend your money bringing you into line with the latest and greatest–and sometimes it really is sufficient just to keep some old ball of code ticking along. I wouldn’t really want to work for one of these places, and doubtless neither would you, but it’s an acceptable deal for some programmers and some companies, and there’s a more nuanced perspective available than just to patronise them.
The other thing with great programmers is that if you don’t give us a sufficiently interesting problem to work on, we’ll often go and invent our own (whether consciously or not).
That might be a plus for someone like Google, or sometimes for some kinds of start-ups, but not so much for some more pedestrian smaller businesses.
Or perhaps behaving like this makes one not a great programmer, depending how you define it. It's not a one-dimensional quality I suppose.
If you actually like programming (as oppose to pursuing it for the money), you should only seek to work at places where you, as a technologist within your particular field will make a difference.
Problem is that it's tricky to tell such places apart from the rest. Everyone calls themselves a "technology company". Mission of the company isn't a good heuristic: there are e-commerce retailers that are run like "IT shops" and there is Amazon (a true technology company). Nonetheless, from this message I can tell that something is different here and better here:
http://groups.google.com/group/mi.jobs/msg/d81b6c1fa8f361fc?...
In most other cases it isn't so clear; you have to read between the lines. Job descriptions only asking for years of experience with specific technologies, non-technical interview questions or interview questions that only involve language syntax and APIs but don't touch on algorithms and data-structures, inflexible working hours, mandated technology stacks (with no exceptions for new projects or experimental code) are a way for an employer to signal "hackers not wanted". Fortunately these are very easy to spot and avoid, but I've been surprised when people (who have other options) choose to work at companies that require them in their seat at 8:30 and clearly under-use their talent.
On the other hand, I am afraid excessive commitment to methodology (e.g., daily stand-ups, inability to write any code without meetings + permission of the "scrum master" + index cards, pair programming, mandated test coverage percentages and "always write tests first") is another such sign, but unfortunately I am in minority.
Send us your resume in raw text format. Word resumes will be discarded.
Experience with an OO language (Java, C++, etc) is required.
In your cover letter, tell us about a non-mainstream technology you love.(Just to clarify, I'm not saying punctuality is unimportant. Something that isn't in on time to be useful should not be considered high-quality work. That that's different from requiring a specific set of ass-in-chair time.)
This should be such a no brainer but it's far and away the most common complaint I hear.
$900 on a workstation every 2 years -> happier, more productive devs.
Luckily he got the hell out of there. I'd fear for his sanity.
I would also occasionally notice him standing behind me looking at my monitor over my shoulder (he was a 'hands on' kind of manager).
He was really surprised when i quit after a few months.
Another example:
one day he told me I shouldn't leave windows (on the computer, not physical windows) open when I go home at the evenings because it looks like I left work in the middle of doing something.
After that I made sure I minimized all the windows before leaving.
I managed about 7 months in that job before getting a research job. However, I did learn a lot about the politics of workplaces in that time.
Wow, outright lying?
Luckily my friend is a good dev, so he didn't have a problem finding more work.
You also have to look at how many conversations you can bring up testing in. If you can do it for at least 90% of your conversations you're doing pretty good. It's probably not worth it to cover 100% of conversations though.
How not to write a good blog post: Don't permit your readers to decipher the article without unwinding 4 levels of double negatives.
Crappy programmers are well-known for choosing money over career development, intellectual challenge and cultural fit.