Hacker News Reader

Comment by devanti | Hacker News Reader

There are 10X programmers. I'll give an example. If you take an average programmer and "the best of the best" and ask them to build a relatively complex iOS app, of which neither has previous iOS experience, the best programmers WILL finish the task up to 10x faster than the average. This is because the average programmer gets stuck on bugs, solving problems, complexity, and is slower at learning new things. The better programmer has a combination of skills that allows him/her to do the correct research and solve the problem at a much faster space. The rate of which grows as the complexity of the task increases. Thus reaching 10X.

View on HN

Actually I believe almost everyone who is reading hacker news is a 10x programmer. It's really quite simple, the average IT person, especially in "enterprise" has very limited knowledge, but they do know some programming. Either in Cobol, Basic, ASP or Excel. Their job is to solve problems, but they're not really interested in their work. A job is a job, not a hobby. They have never heard about system automation, still thinks Linux is evil and a bedroom project and believes VMWare is a coming revolution for system administration, which they're gonna start to use soon.

I don't agree, if only because I'm the anecdote. I'm trying to pick up Rust and mess around with app/net security, but at my job, I feel like I'm in the middle of the pack. There are instances when I quickly fix stuff but also take forever to find a simple problem. To be fair, we do have a very extensive app with 15 years of code rot and only 2 members of the original team to guide/teach. But a guy that started a month after me is already 2x what I am in LOC/fix time. (I know, I know, LOC is a poor metric)

This and "if you read books, you're already way ahead of the pack" or similar statements are just feel-good statements. It's very clear that the other guy and the two original team members are way more productive than I am despite me trying to hit all of the recommended reading books and reading HN/subreddits/blogs/etc.

You can read HN/books/stack overflow and be really good as long as you take advantage of the information and actually practice it in the real world. But until you go and actually measure real things like LOC/fix time/projects completed, the signals "reading HN/books/whatever" are just cultural signals.

The attitude you have is the one that eventually drives you to be a 10x. If you think you are awesome at what you do, that is when you probably are not.

> If you think you are awesome at what you do, that is when you probably are not.

Nailed it.

Here are some observations that may or may not help you:

Average programmers tend to: * like new projects * want to build "new things" * not like fixing bugs * not like reading code * not like to redo their designs/code * think their code is as good as it gets

Good programmers on the other hand * tries to find joy in thr task at hand * thinks their old code is bad * aren't invested in their own designs * don't fear trying solutions * reads code rather than docs about the code * don't mind fixing bugs * happy when the code quality goes up, hates it when it goes down.

In other words - good coders CARE, average coders just want to have fun and build stuff. This means the latter group doesn't build the understanding of how to build good, bug free code. They prefer to build themselves into a corner rather than throwing out their designs. Thus they get less practice.

I agree. It reminds me of parenting, if you are thinking about how you can be a better parent, you are already ahead of the pack.

I wish it would be like that but my experience is that even average IT people are quite interested in what they do. (I'm still a student so my sample size is not that big).

I find it's heavily dependent on the company. Companies that see IT as core to a successful business tend to attract 10x programmers. If you are still in school then my advice is to learn to interview a company while you are interviewing for a job. Find the place that's going to push you more, regardless of pay.

The problem with the 10X label is that it models the productivity as linear relationship, when it's not, as you allude to.

A bad programmer can do simple tasks nearly as fast as a good programmer.

But at a higher level of difficulty that difference might be 10X. Hell, it might even be infinite.

For example, the best NFL QBs will win 10X as many games as the 3rd string backups. But you wouldn't call them 10X better. In fact they are probably only 10% worse than the elite QBs in their completition percentage.

Or if you raised the height of the hurdles 4 inches in hurdle racing, some of the racers wouldn't be able to jump over it any longer.

In this particular case, isn't "10x" just a factor of IQ then? Smarter programmers get complicated things done faster. That seems like a no-brainer. Problem is, how many of those people actually exist in programming? A much smaller subset than exist in the world, which is already a small subset of the general population. Hinging your company on hiring nothing but 10x programmers is like trying to hire a unicorn.

The scientific evidence [0] compares to "worst" for 10X, not "average".

[0] http://www.construx.com/10x_Software_Development/Origins_of_...

In my experience, the worst programmers have negative productivity. 10X programmers must be real monsters.

Because they have negative productivity multiplied by 10?

In that case, there are "InfiniteX" programmers. The worst programmers will get stuck on complex problems and may never complete the task without help. It all depends on the task.

And I say "average" programmer because average is fairly bad if you look at the workforce on a global scale.

Maybe these 10X programmers can quickly solve bugs and problems because they have faced similar issues before and spent the time nesseccary to understand the problem. In that case the important lesson is to limit the amount of novelty in your work so that you are mostly building on technologies you understand well.

In which case you'll probably inevitably end up building something with a suboptimal stack -- and limiting novelty also means you won't learn anything _new_, which sounds more terrible to me.

I am not arguing that you should elimate novelty completely. Just that the amount of time you have to learn new things is limited and needs to deliver returns.

Take the iOS app development. Consider someone who has never used Objective-C but has lots of experience doing client side web development. It would probably be faster for them to develop using a tool like Phonegap and use existing skills. It is theporetically sub-optimal to native code but surely the time spent learning phone gap will produce faster results than trying to learn an entirely new stack.

I think the point was to stay in the same niche, not to avoid new approaches to common problems in your niche.

If you give the average programmer a problem that is impossible for him to solve, the best of the best will appear as a infiniteX programmer.

Reply on news.ycombinator.com