Live data from Hacker News

10x Engineer

medium.com

101–110 of 186 posts

Re: 10x Engineer

#101

While the article correctly highlights the lack of rigorous scientific studies on 10x engineers, it also generalizes a bit too much from anecdote to make the argument that they are mythical creatures. A more reasonable argument is that the hypothetical existence of 10x engineers explains little about the productivity of most organizations. Personally, in the couple decades I have been in this business working in coun…

[deleted]

Re: 10x Engineer

#102
post #86

Earlier quoted context omitted.

I feel obliged to toss in Joel's commentary... http://www.joelonsoftware.com/articles/HighNotes.html His commentary about "hitting the high notes" was new to me. It isn't just that 10x people are faster and make less mistakes, they also can do things that others can't. This doesn't mean that you have to ignore culture, and tolerate bad behavior. But it does mean that in software it is worth the effort and cost to cha…

This resonated with me. If the programming tasks are somewhat mechanical/procedural, I am not sure that an exceptional engineer can create 10x as much value as a quite good one. I've never seen it. What I've seen several times are engineers that are able to tackle problems that require so much creativity or skill that giving them to a less qualified engineer would most likely be a waste of everyone's time. In instanc…

I've worked at a lot of places and I clearly see it. It isn't very hard being a "10x" engineer if you look at the average programmer profile :

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

Re: 10x Engineer

#103
I work with a '10x engineer'. He works from 8 AM to 11 PM, like clockwork, every weekday. He is great to work with but I do not envy him.

Re: 10x Engineer

#104
More studies will definitely help. I have a 10X engineer in my larger group and there's no question that he is one. Since I've seen this 'mythical' creature, I would not agree with the piece. Of course memetic transmission of the idea without critical evaluation can be harmful. However, color me paranoid but I see the sentiment behind this as being egalitarian and not meritocratic.

Re: 10x Engineer

#105

While the article correctly highlights the lack of rigorous scientific studies on 10x engineers, it also generalizes a bit too much from anecdote to make the argument that they are mythical creatures. A more reasonable argument is that the hypothetical existence of 10x engineers explains little about the productivity of most organizations. Personally, in the couple decades I have been in this business working in coun…

[deleted]

Re: 10x Engineer

#106
post #77

I thing part of the mythology about the 10x engineer stems from the very real and shockingly widespread existence of the NNPP or the "Net Negative Producing Programmer". There are many environments in which NNPP's are pretty much the standard, programmers that produce more problems and bugs than actual working and sustainable solutions. In such an environment any competent developer will quickly stand out and will ea…

I like the way Mike Church put it in a Quora answer ( http://qr.ae/NHgRJ ): employees are either multipliers, adders (most common), subtracters, or dividers (fire immediately). Whether multipliers are 5x or 10x more productive is a matter of nebulous metrics, but there are obvious standouts whose presence brings a very nonlinear increase in value to the team.

The four-types classification reminds me of a semi-famous saying by a German general, Kurt von Hammerstein-Equord (http://en.wikipedia.org/wiki/Kurt_von_Hammerstein-Equord):

I divide my officers into four groups. There are clever, diligent, stupid, and lazy officers. Usually two characteristics are combined. Some are clever and diligent -- their place is the General Staff. The next lot are stupid and lazy -- they make up 90 percent of every army and are suited to routine duties. Anyone who is both clever and lazy is qualified for the highest leadership duties, because he possesses the intellectual clarity and the composure necessary for difficult decisions. One must beware of anyone who is stupid and diligent -- he must not be entrusted with any responsibility because he will always cause only mischief.

Re: 10x Engineer

#107

The 10x is a huge simplification, but it doesn't make it any less true. Obviously there's a huge range. I'd go so far as to say there are 100x engineers -- but it's not that they personally achieve 100x more than another programmer sitting in front of the computer. It's that they have the vision and talent to set a project up the right way from the start, so that the normal programmers can be productive. They're the…

Bingo!

As problems get more complex, the amount of time to complete them can go exponential for some developers. I've been forced to work with people like that; it really can be the case that some developers (who are otherwise competent) would simply never finish tasks that involve a crucial level of complexity.

And EVEN at just about any nontrivial level of complexity, where the time spent is only in the 1.5x-2x realm, the code written by the awesome programmer will likely be easier to understand, shorter, and easier to maintain.

Huge articles like the one linked are simply written by (and for!) the average competent programmer, to make them feel better. If you haven't worked with developers with a huge range of productivity, then you either haven't worked with a really good developer, or you've somehow lucked out and never worked with a poor developer. Statistically, it's likely the former.

Re: 10x Engineer

#108
post #102
post #86

Earlier quoted context omitted.

This resonated with me. If the programming tasks are somewhat mechanical/procedural, I am not sure that an exceptional engineer can create 10x as much value as a quite good one. I've never seen it. What I've seen several times are engineers that are able to tackle problems that require so much creativity or skill that giving them to a less qualified engineer would most likely be a waste of everyone's time. In instanc…

I've worked at a lot of places and I clearly see it. It isn't very hard being a "10x" engineer if you look at the average programmer profile : 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 exac…

>So tell me, is this a good engineer ? Great ? Or a disaster ? He's not exactly a stabilizing force, that's for sure.

Sounds like he doesn't want to be working there. Sorry, but it's probably the right decision to encourage him to find a job that he wants. Elsewhere.

In a few of the behaviors he described, I find some sympathy. I do have a high opinion of myself, and at one job would end up in loud arguments with the CTO over how to do things. Sounds like this guy takes it farther, though, doing things that are spiteful when he doesn't get his way. That's a scary, pathological behavior, and that alone would make me think you'd be better off without him. I wasn't happy when I didn't get my way, but I'd suck it up and deal; that's the only professional response.

And speaking of pathological: It sounds like he's intentionally misinterpreting instructions when he can? Again, that speaks of passive-aggressive behavior. And he avoids other employees? Not to say that anyone is in danger, but you've painted a scenario that strikes me as the backstory for "the guy who cracked, came in to the office, and went on a shooting rampage."

Or he's just Aspergers. Can't really tell the difference from here.

Re: 10x Engineer

#109
post #86

Earlier quoted context omitted.

I feel obliged to toss in Joel's commentary... http://www.joelonsoftware.com/articles/HighNotes.html His commentary about "hitting the high notes" was new to me. It isn't just that 10x people are faster and make less mistakes, they also can do things that others can't. This doesn't mean that you have to ignore culture, and tolerate bad behavior. But it does mean that in software it is worth the effort and cost to cha…

This resonated with me. If the programming tasks are somewhat mechanical/procedural, I am not sure that an exceptional engineer can create 10x as much value as a quite good one. I've never seen it. What I've seen several times are engineers that are able to tackle problems that require so much creativity or skill that giving them to a less qualified engineer would most likely be a waste of everyone's time. In instanc…

For many systems, maintenance requires more effort than construction. Bad coders require much more maintenance. Some of it is from code not built for reuse, and some of it is for "Drop everything everyone is doing until someone can figure out why this isn't working any more!"

Re: 10x Engineer

#110
post #102

Earlier quoted context omitted.

I've worked at a lot of places and I clearly see it. It isn't very hard being a "10x" engineer if you look at the average programmer profile : 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 exac…

>So tell me, is this a good engineer ? Great ? Or a disaster ? He's not exactly a stabilizing force, that's for sure. Sounds like he doesn't want to be working there. Sorry, but it's probably the right decision to encourage him to find a job that he wants. Elsewhere. In a few of the behaviors he described, I find some sympathy. I do have a high opinion of myself, and at one job would end up in loud arguments with the…

Not to say that anyone is in danger, but you've painted a scenario that strikes me as the backstory for "the guy who cracked, came in to the office, and went on a shooting rampage."

This is a highly irrational conclusion, even with the meaningless caveat.

Post reply on HN