Hacker News Reader

PHB's tend to measure themselves by how many people they're in charge of; better 10 guys than 1 that's productive as 10. PHB's aren't entrepreneur types, they're middle managers who require underlying to justify their existence, the more the better.

That's been my feeling about it, too. Headcount and control rather than actual productivity. Also, I feel like middle managers have a terrible incentive profile. If an underling really shines, then it reflects well on the underling. If one underperforms or makes a mess, boss gets shat on for not keeping them in line. It's easy to rip on middle managers, but they have a shitty job and it's not their fault. It's just structured badly.

I think it's easier to understand why middle managers are the way they are once one understands their incentive structure. They participate in an employee's downside but not upside (she did it herself) so of course they're going to be the way they are.

I may be radical but I think open allocation is the only answer for software development. All the nonsensical process that grows up around closed allocation seems archaic and stifling. I think typical middle management is useless. What you really need are HR-independent mentors. Aside from mentoring, the other thing managers can do (firing) should be so rare in a well-run company that you only need one per few hundred people.

I recommend reading about the Gervais principle![1]

[1]http://www.ribbonfarm.com/2009/10/07/the-gervais-principle-o...

When Michael read about the Gervais principle it inspired about 100,000 words of response: http://michaelochurch.wordpress.com/?s=gervais&submit=Se...

thanks for the link!

If you have the time, you might want to check out my blog. I've covered that topic in exacting detail.

just had a quick look and am as excited reading this as checking out more espisodes of 'the office'! (I only started watching the american version recently. Originally I dismissed it as just another copy-cat of the original UK, but I'm beginning to get into it).

I didn't read any of it yet, but just the thought of having more to read about it makes my life already better :)

EDIT: I just realised who I was "recommending" this too. Well, at least it was worth it for me :)

.. brought to you by her Majesty's Civil service. http://en.wikipedia.org/wiki/Yes_Minister

The ten 1x programmers tend to turn against the 10x programmer before he/she has time to manifest, to protect their own 10 jobs.

Very fucking true. Also dangerous is the 2.5x who thinks he's a 10x, convinces management of this, and then drives out everyone better.

(For my part, I'm only a 6-8x. I'm fairly new to software and I also spend too much fucking time on activism.)

They would also have trouble identifying the 10x programmer to begin with, and with the pointy haired-ness have trouble retaining them.

It is trivial to identify a 10x programmer.

Take any project (or platform) that uses quirky and individualistic style, preferably written in an obscure language. Any programmer that has been working with such a project for a year or two, would be a 5x programmer. Any programmer that has actually started that project would be a 10x programmer. Why? Because an amount of effort that any developer, unfamiliar with an obscure approach has to spend is 50x.

So a 10x programmer is one who writes crappy code? I think you have your definition backwards.

>One who writes quirky and individualistic code. Not crappy. It could be well organized. And even good. And even solve the problem, at the time when it was written. But. If that code is approachable by any regular developer, when the original programmer would not be 10x. And management and peers wouldn't think about the original developer as 10x.

Nope, still got it backwards.

The characteristic of a 10X programmer is how FAST he can write GOOD code that solves a particular problem. Neither individualistic, nor quirky. He doesn't even have to read Ayn Rand.

If it's not code that his 1x coworkers can understand, then he's not 10X, just show-offish and hackish.

To give some examples: Dennis Ritchie and Brian Kernighan. Linus Torvalds. Poul-Henning Kamp. Zed Shaw. Notch. John Carmack.

All of those are/were very much 10X programmers. But no obscure languages and nothing quirky and particularly individualistic about their code.

I think you have mixed the notion of the 10X programmer with the notion of the "cowboy coder" (with traces of crazy genius, e.g the autonomous, quirky, Lisp/Haskell/J/whatever yielding programmer who completes some huge project in his own peculiar way in a short amount of time).

The problem is, that the consensus about a particular developer in a particular project -- to call that developer "10x, 1x 0.1x" -- is a consensus of peers and management.

And peers almost always lack the information to make the objective call. If they'd had that information, they wouldn't have called that developer a 10x. And that's one of the reasons, why you never see normal people calling themselves 10x, by the way.

One who writes quirky and individualistic code. Not crappy. It could be well organized. And even good. And even solve the problem, at the time when it was written.

But. If that code is approachable by any regular developer, when the original programmer would not be 10x. And management and peers wouldn't think about the original developer as 10x.

But if, the code is quirky and individualistic... a funny thing happens. Suddenly whoever works (or can rise up and work with that code for whatever reason) is 10x. And peers and management would see them as 10x.

I've seen that quite a number of times. Many times as 10x, as 1x and even a few as 0.1x.

Good code is dead simple to read and understand. That is what makes it good, because sooner or later, someone will need to read it and maintain it.

Getting to that point is difficult, and may require a 10x programmer. But the end result is simplicity.

I think you misunderstand grand-parent. Once again I will use a quicksort example - we all know quicksort, even if not iterative, then surely recursive version, right? Ok, so here goes quicksort implementation that is dead simple and easy to read:

    quicksort=: (($:@(<#[), (=#[), $:@(>#[)) ({~ ?@#)) ^: (1<#)

It's in J. Someone who wrote this has much higher chance of being 10x than someone who implemented the same algorithm in Python. That's all I think grandparent wanted to say and if so then I agree completely.

Someone who wrote this has much higher chance of being called 10x by peers and management. And someone who has to support that code has much higher chance of being called 0.1x by pears and management.

Risk management.

Assuming the PHB can hire 10 junior devs or 1 senior dev at the same cost:

If you have 10 junior devs and 1 decides to quit, the PHB can swap him out fairly easily - he just has to wait for graduation day.

If you have 1 senior dev and he decides to quit, the PHB's hands are severely tied, especially if the company is located in a place where talent is lacking.

This is also the reason why mainstream languages will likely remain popular forever in the enterprise world - no one wants to take a chance on a language that only 5% of devs know.

> This is also the reason why mainstream languages will likely remain popular forever in the enterprise world - no one wants to take a chance on a language that only 5% of devs know.

Unless they have a legacy system. Or what percentage of developers know Cobol these days?

They're not taking a chance on a language only 5% of devs know, precisely because they know how painful it is to be chained to a legacy system. So they do every new project in the industry standard language, which is Java.

Problem is, the industry standard used to be COBOL. Sooner or later, if/when Java falls out of vogue and stops evolving, they will end up with two legacy systems instead of just one.

I can't find the link right now, but I saw an ad from a technical school here in Sweden only a couple of weeks ago advertising their new 1 year Cobol developer program.

I'm not surprised. Over here in Malaysia, almost all banks still run a COBOL backend.

Yea I remember the ad listing a number of large Swedish banks and insurance companies that still use COBOL as an argument for why you should learn COBOL and why it would be easy to get a job afterwards.

This is a good point, but it serves to point out what others are not bringing up. The truth is, managers know programmers aren't cogs and can never be. How could they not? The issue is that their managers believe or really want to believe that programmers are cogs, so the lower manager can cut all experienced programmers and replace them with the cheapest labor they can find. What shows up in the short term is a cost savings, and therefor probably a promotion. Yes, since these new programmers don't know the system it's destined for failure, but who cares? By the time that happens the PHB will be in a new position and no longer responsible for this mess they made.

The true plague or our industry and everyone else's is short term thinking, and I don't see how it could be fixed at this point.

You've just proven the point. Commit to the popular language because finding maintainers in X years will be that much easier

I think people are not as rational as they seem and it's basically a form of power hunger - PHBs feel more powerful when the distance between them and their employees is larger: one feels much more powerful having 10 people well below him than having 1 person a little below him, and 10x programmers that also have social skills in a company where IT matters will have a say in lots of things, even not IT related and even if not in a direct way, so they end up closer to the PHB on the power scale than each of the 10 1x ones, which is a bad feeling... Now if the 10x is totally lacking in social skills and introvert, that's ok for the PHB, but if lacking in social skills and more of an extrovert, it's bad again, because although he wouldn't have a say in things because he's "the smart asshole", he'll make everyone, including the PHB, feel and look stupid (and they probably will be 20 iq point below him and they'll know it and feel somewhat demoralized by him).

Basically the 10x guy is uncomfortable for all guys above him (not only in software but in any other field that has a 10x skill gradient) that lack self-control, self-knowledge and people skills (what's called "being wise"), and most PHBs are "very not wise".

But what could be the underlying reason, seeing as 10x programmers are only 1.5-3.0x as expensive?

I'd venture that it's because something like less than x% of all programmers are elite; where x is some number between 5 and 10.

In this case, if you are PHB and have a budget of y for staff (where y <= average) and time variable of z (where z <= average) for a release date - it would appear that you are an incompetent PHB if you believe you can hire an elite programmer to solve your problem(s).

Why is that the PHB's wet dream?

Because it makes the business more failure tolerant. Finding even one 10x guy is tough - many teams will have only 1 or 2 of them, and a swarm of 1x guys.

If the 10x guy is on vacation, quits, or has something more important to do, you can throw one of the 1x guys at it.

You don't need nefarious "I hate the 10x cause I'm a psychopathic PHB" motives to explain this one.