10x more selective
Blog<br>Site<br>đť•Ź<br>Feed
10x more selective
April 19th, 2013
There's this common notion of "10x programmers" who are 10x more productive than the average programmer. We can't quantify<br>productivity so we don't know if it's true. But definitely, enough people appear unusually productive to sustain the "10x<br>programmer" notion.
How do they do it?
People often assume that 10x more productivity results from 10x more aptitude or 10x more knowledge. I don't think so. Now<br>I'm not saying aptitude and knowledge don't help. But what I've noticed over the years is that the number one factor is 10x more<br>selectivity. The trick is to consistently avoid shit work.
And by shit work, I don't necessarily mean "intellectually unrewarding". Rather, the definition of shit work is that its<br>output goes down the toilet.
I've done quite a lot of shit work myself, especially when I was inexperienced and gullible. (One of the big advantages of<br>experience is that one becomes less gullible that way – which more than compensates for much of the school knowledge having<br>faded from memory.)
Let me supply you with a textbook example of hard, stimulating, down-the-toilet-going work: my decade-old adventures with<br>fixed point.
You know what "fixed point arithmetic" is? I'll tell you. It's when you work with integers and pretend they're fractions, by<br>implicitly assuming that your integer x actually represents x/2^N for some value of N.
So to add two numbers, you just do x+y. To multiply, you need to do x*y>>N, because plain x*y would represent x*y/2^2N,<br>right? You also need to be careful so that this shit doesn't overflow, deal with different Ns in the same expression, etc.
Now in the early noughties, I was porting software to an in-house chip which was under development. It wasn't supposed to<br>have hardware floating point units – "we'll do everything in fixed point".
Here's a selection of things that I did:
There was a half-assed C++ template class called InteliFixed (there still is; I kid you not). I put a lot of effort<br>into making it, erm, full-assed (what's the opposite of<br>half-assed?) This included things like making operator+ commutative when it gets two fixed point numbers of different types<br>(what's the type of the result?); making sure the dreadful inline assembly implementing 64-bit intermediate multiplications<br>inlines well; etc. etc.
My boss told me to keep two versions of the code – one using floating point, for the noble algorithm<br>developers, and one using fixed point, for us grunt workers fiddling with production code. So I manually kept the two in<br>sync.
My boss also told me to think of a way to run some of the code in float, some not, to help find precision bugs. So<br>I wrote a heuristic C++ parser that automatically merged the two versions into one. It took some functions from<br>the "float" version and others from the "fixed" version, based on a header-file-like input telling it what should come from<br>which version.
Of course this merged shit would not run or even compile just like that, would it? So I implemented macros where you'd pass<br>to functions, instead of vector&, a REFERENCE(vector), and a horrendous bulk of code<br>making this work at runtime when you actually passed a vector (which the code inside the<br>function then tried to treat as a vector.)
And apart from all that meta-programming, there was the programming itself of course. For example, solving 5Ă—5 equation<br>systems to fit polynomials to noisy data points, in fixed point. I managed to get this to work using hideous normalization<br>tricks and assembly code using something like 96 bits of integer precision. My code even worked better than<br>single-precision floating point without normalization! Yay!
For months and months, I worked as hard as ever, cranking out as much complicated, working code as ever.
And here's what I should have done:
Convince management to put the damned hardware floating point unit into the damned chip. It didn't cost that many square<br>millimeters of silicon – I should have insisted on finding out how many . (FPUs were added in the next chip<br>generation.)
Failing that, lay my hands on the chip simulator, measure the cost of floating point emulation, and use it wherever<br>it was affordable . (This is what we ended up doing in many places.)
Tell my boss that maintaining two versions in sync like he wanted isn't going to work – they're going to<br>diverge completely, so that no tool in hell will be able to partially merge them and run the result. (Of course this is exactly<br>what happened.)
Why did this end up in many months of shit work instead of doing the right thing? Because I didn't know what's what, because<br>I didn't think I could argue with my management, and because the work was challenging and interesting. It then promptly went<br>down the toilet.
The hardest part of "managing" these 10x folks – people widely known as extremely productive – is actually convincing them to<br>work on something. (The rest of managing them tends to be...