Arrive at 9:30, start out with 30 minutes at the coffee machine. They get mad if you discuss work at this point, or god forbid, talk about interesting algorithms or the like. They expect to be told exactly what to do, or they won't even sit down. If you don't give them an exact list of methods to implement in a class, nothing will happen. You can give them documents about the design, but they won't read them, let alone provide feedback. Not even after asking them 5 times. Similarly, when I started my recent project, I asked one of the customers for the canonical book on the subject and read (most) of it. I do not consider this special behaviour, but I'm definitely the only one to have done this. They treat this as normal, and if they make basic problem interpretation mistakes that would make you think a highschooler had mental problems, the reply is "it's in the design". Similarly classifying bugs correctly is impossible. A letter out of place in the UI they treat as equally serious as getting the wrong outcome in a financial calculation. If some programmer put "fucking" in some UI text (the one I talk about below), then we drop everything else, right ? They work to satisfy the exact wording of the policies, and never ask for (or tolerate in code reviews) exceptions. If you don't have 5 exceptions to the style guide and 5 things where they claim "sure, but the obvious unit test would be worthless, so I tested ...", chances are you don't understand the problem, don't understand the language well, or there is something wrong.
Of course, this is the "average" programmer at a place like a bank. I'm sure at Google or a few other places, it doesn't quite work like this. Being a 10x programmer is easy in a team filled with this kind of staffers.
I once had a guy that I'm totally unsure whether he was a fantastic programmer, or totally worthless. He'd be sitting behind his desk for the first week of the project. Almost without exception he wouldn't have his IDE open, but have an ipython notebook with some part of the problem open. Alarmingly often, he'd have hacker news, or dzone open and would be reading articles (I mean 50%+ of the time, not once or twice a day). Meanwhile his output in code was exactly zero for that week. Then, suddenly, in a little over a day (when he had claimed he could do it in an afternoon), he'd checked in the source for an entire module (that would have taken us probably a month to write, at least half a month). It wasn't 100% bug-free, but it was good enough to make the product functional. And while he took care of any bugs pointed out to him in minutes flat, for the rest of the week it was back to reading and experimenting (I think) mostly unrelated things. The problem is, this guy is not failure-free. He has these bursts of productivity, and sometimes he writes something beside the point (all programmers do), however it is really hard to ignore the week of wasted time when something he does gets rejected. We have a -sort of- working relationship, but it's not exactly smooth sailing. Any relatively independent and hard problem, he gets to do. And if something just needs to start working, we throw it his way. The result of that second part tends to infuriate other developers, but at the demo the UI works, with the project only half finished, which is something customers and managers appreciate. He tends to have his IDE open, modifying code, often while we're walking into the demo room, which doesn't inspire confidence to me. His reputation with the team is on a constant change. He's lazy, self-centered bordering on egoistic, can't follow instructions (granted, he generally makes good cases that the problem is with the instructions, not with him. But the frequency of him not following instructions is just so much higher than with the rest of the team it's not realistic). He ignores his coworkers, and of course they can't deal very well with the fact that there regularly are weeks with his productivity at zero. They don't feel to well about his productivity being off the scale for a few days either, by the way. Oh and once, he wrote 10 pages of code that implemented a complex algorithm, when we needed it, and all variable names were girl's names. Every single one. As in "for (int debby : kaithlin) {" type code. Why ? Because he had an argument with the architect.
So tell me, is this a good engineer ? Great ? Or a disaster ? He's not exactly a stabilizing force, that's for sure. There regularly are times when I wouldn't want to do without him, but most of the time, I'd like to make a hole in the window with his exact silhouette. More than one of his coworkers have mentioned something along the lines of "can't we fire him 4 weeks out of 5 ?".
