The 10x developer is not a myth (2013) - <AUTHOR> http://www.ybrikman.com/writing/2013/09/29/the-10x-developer-is-not-myth/ <comment><USER3> The reason for pushback on the idea 10x programmers isn't the real gradient of skill, it's the labor aspect. Lots of companies want to hire 10x without paying 10x dollars, and they've figured out that blowing smoke up the ass of young people (though it works better on young men than women) is a way to squeeze blood from that stone.

Especially if you're working in a small company, you're going to hit a point when there is a massive wall of work to be done, bigger than you would ever be able to handle alone, and your organization will fail if you don't do it. The skills you need to actually handle that situation are going to be more in the vein of basic professionalism than technical talent. Better programmers might need a bigger wall before things get rough, but they will still hit it.

The reason for criticizing the 10x idea isn't that it doesn't exist, the reason is because feeds into myths that might end up being harmful far beyond the actionable decisions it lets you make.

<comment><USER4> > you're going to hit a point when there is a massive wall of work to be done, > bigger than you would ever be able to handle alone

This is my core complaint. All software development is (eventually) rate- limited somewhere other than developer brilliance. Most business software hits this limit fast.

A huge portion of business software is stuff you can't solve with brilliance - tasks from integrating with other companies to building out simple new features happen at the speed of spec development, email responses, or other non-development limits.

If the 10x myth makes employers expect 10x _productivity_ from certain devs, or even 5x, it's badly misleading them. Not always, there are compiler companies and ML firms and whatever else that need brilliance, but I think most companies that advertiser for 10x developers are usually limited by forces 10x development can't help with.

<comment><USER5> A lot of "developer brilliance" is simply avoiding the inevitable slowdown that happens when projects mire themselves in technical debt.

I've worked on plenty of projects where two smart developers would have massively outperformed the 10-12 mediocre and highly risk-averse developers working on the shitty (gradually getting shittier) code base over a period of 6 months.

For greenfield I don't think 10x productivity is likely though. If you're testing an idea you might throw away, cheap and cheerful will do.

<comment><USER6> On many of the projects I worked on there were two smart developers doing all the work and 10-12 mediocre developers doing almost nothing.

</comment></comment></comment></comment><comment><USER7> I had a boss 25 years ago (smart guy, did compiler work, etc. for new computer architectures) who claimed that there was really a 100x factor difference from the best to the worse. I believe this: would you rather have one day of work from Daphne Koller, Peter Norvig, or Jeff Dean - or 100 days from an average developer? Well, the answer is that "it depends." There is a ton of work that can be effectively done by non-rock stars, and there is some work where a 100x person can do things that other people can't, no matter how much time they spend.

An example: I use TensorFlow, but looking at the concept and implementation, I don't think I could conceive of and write TensorFlow in 10 years of work.

<comment><USER8> > I use TensorFlow, but looking at the concept and implementation, I don't > think I could conceive of and write TensorFlow in 10 years of work.

And this is exactly why software is eating the world. Once written it stays written and all those people that could not write something like TensorFlow if their life depended on it are able to use it _as if they could_.

Abstraction is a super powerful thing, all this building on the knowledge and capability of those that came before is what makes the whole thing possible in the first place. Probably the people that wrote TensorFlow would not be able to design (each of them individually) the computers that it runs on, or the operating system that allows them to run TensorFlow in the first place.

<comment><USER9> I agree very much. Just came to say that this has always been the case with the know-how of starting fires, metal molding, forging tools and weapons, inventing microscopy, large scale industrial processes, computers... software is the extension of the exponential acceleration of abstraction and reuse that our society was built on.

<comment><USER10> I feel like there's a difference with software though. Maybe not in degree, but in the constant factor.

With e.g. metalworking, you can transfer the knowledge but training takes time. And building a new implementation of that knowledge takes time too.

But in software the knowledge and implementation is transferred effectively _instantly_. You can nab software off the internet (transfer knowledge) and start running it locally _right now_ (implementation).

Software changes the complexity from O(2^N / T) to O(2^N).

<comment><USER9> Sure, but is this not the same as buying a hammer/fertilizer/metal press and using it for your own means? That's a quasi-instantaneous acquisition of the result of hundreds of thousands of years of innovation.

<comment><USER8> Electrons move a lot faster than molecules, you could invent X in the United States and a person in China could be using it tomorrow without any cumbersome shipping or cultural barriers to adaptation.

The hammer, fertilizer and the metal press are all part of our tool-making culture, ways to adopt nature to do our bidding and in the case of the hammer and the metal press to shape it by brute force. In contrast, something like TensorFlow is a tool of the mind which means you can encode it as bits and those will travel the world a lot faster than your average bulk goods or container ship every will.

So they are comparable at some level and totally incomparable at others.

<comment><USER11> Even if software didn't have tremendously higher cultural barriers for usage than manual equipment, the rapidity of exchange is a very small component of the exchange value for the means of software production (which is primarily hardware anyway). The value of both hardware and software is measurable by the amount of labor needed to produce them, so it's not even comparable--it's identical.

</comment></comment></comment></comment></comment></comment></comment><comment><USER12> My own productivity fluctuates by more than an order of magnitude. But that means it's not my intrinsic ability. Sometimes it's choices. Most of the time it's who my manager is, what choices the team (or the team before) made, how much I care, and whether I get along with the people I'm working with.

The article is strangely defensive of the number 10 specifically; having discussed this topic here several times I get the feeling most people on HN already agree that there are order of magnitude fluctuations in productivity from person to person at any given time, but that 10 itself is a biblical number -- symbolic and not even meant to be taken literally.

I'm sure 10x has been true somewhere for someone, but there's nothing special -- _nor empirical_ \-- about the number 10. There are more people 2x better than average than 10x. The distribution looks like what you'd expect -- peaks at 1 and falls off in either direction.

> You become a 10x programmer not by doing an order of magnitude more work, > but by making better decisions an order of magnitude more often.

I think this isn't necessary to be 10x more productive. You can make a single decision and become more productive. You can also use a single philosophy. You can also get yourself in the right company and on the right team surrounded by people who are smart and cooperative instead of competitive, and watch everyone's productivity soar.

The most 10x-famous programmers I know are ruthless about not implementing things until they need them so badly it hurts. And they keep their code really, really, _really_ simple. No cleverness, no tricky bullshit, just super-simple super-readable easy to understand, and literally boring code.

</comment><comment><USER13> Of course there are some people that are vastly more productive than others. In business they're called "rain-makers" in programming, "10x".

Whatever the case, these people are always outliers. Unfortunately that doesn't prevent teams from claiming that they only hire 10x's.

No one starts out as a 10x. Perhaps instead of focusing on who is or is not 10x or how many 10x's are out there, it is more interesting to explore HOW people BECOME 10x?

A more realistic view is that individuals are a moving target. Skill is something that needs to be nurtured, practiced and modeled by mentors in order for others to pick it up. Orgs that just stop at the fact that people are going to have a wide distribution of skills are doing a disservice to themselves and their employees.

<comment><USER14> I have worked with many brilliant people that didn't have motivation. And if they did, their energy wasn't directed towards the task at hand. Then, you need an environment that doesn't get in their way.

</comment></comment><comment><USER15> I wasn't sure I believed in 10x developers, then I thought "I've worked with people 3.2 times more productive than me, and I've also worked with people 3.2 times less productive than me..."

<comment><USER16> Wow, it's even better 10.24x developers exist!

<comment><USER15> There may be some rounding errors involved in my assessment :)

<comment><USER16> You can't be expected to exact as the square root of 10 is irrational. Perhaps that says something about the 10x developers.

</comment></comment></comment></comment><comment><USER17> _[...] They studied professional programmers with an average of 7 years ' experience and found that the ratio of initial coding time between the best and worst programmers was about 20 to 1_

I thought the perceived idea about the 10x developer was that he/she is 10x better than the _average_ programmer, not the worst.

So even this scientific study (from the 60s) says that there aren't 10x developers according to this definition: the ratio goes down to sqrt(20), using the geometric mean, if a good-enough sample was chosen. Program size and program execution speed would put that ratio to sqrt(5) and sqrt(10), respectively.

<comment><USER18> _I thought the perceived idea about the 10x developer was that he /she is 10x better than the average programmer, not the worst_

That could well be what people perceive. It's not what the studies said. While the article has some good references, I might as well quote Peopleware again just for the fun of it. I churn this out every so often:

A 2nd edition of Peopleware summarises it; the 10x programmer is not a myth, but it's comparing the best to the worst; NOT best to median. It's also not about programming specifically; it's simply a common distribution in many metrics of performance.

The rule of thumb Peopleware states is that you can rely on the best outperforming the worst by a factor of 10, and you can rely on the best outperforming the median by a factor of 2.5. This of course indicates that a median developer, middle of the pack, is a 4x developer. Obviously, this is a statistical rule, and if you've got a tiny sample size or some kind of singular outlier or other such; well, we're all adults and we understand how statistics and distributions work.

Peopleware uses Boehn (1981), Sackman (1968), Augustine (1979) and Lawrence (1981) as its sources. [ "Peopleware", DeMarco and Lister, 1987, p45 ]

<comment><USER19> 10x the worst literally means nothing at all if you find a sufficiently bad programmer you can have an infinity times programmer and the 10x developer as it is normally expressed is 10x average.

Further author even punts at the end of article by claiming that its not needed to measure difficult to measure things as we can instead reason our way to the right answer which is practically nonsensical. Measuring is step one in actually reasoning about things.

In short author may be a good developer but he is certainly not a 10x author.

</comment></comment></comment><comment><USER20> Upon reflection, I just realised something: If the biggest difference in productivity comes from the impact of decision-making, then perhaps that is also a big part of the impact of pair programming. If you are a fresh-out-of- uni developer working alone, then it is a lot easier to believe something like "Even though this documentation is in Chinese, I can make do with Google Translate. I don't need to push my manager to approve a budget for having it professionally translated into English." When you have two people talking to each other, the explicitness of your reasoning and verbal communication makes it much more obvious when a decision leads to 3 weeks of wasted time.

(yes, this was my first project out of uni. A can-do impossible-is-nothing attitude can be misinterpreted to lead you to relentlessly pushing against a wall rather than resourcefully going around it.)

</comment><comment><USER21> I've never seen a 10x productivity, or even a 2x. I'd like to see one, show me a scrum where one programmer takes 10 stories on the board, and the others just did one, and he successfully finishes all 10, where the team estimated all stories to be of a full scrum length. I doubt this exist.

Now, I've seen 10x quality, though sometimes they're a little slower, but never 10x slower. So maybe 1.2x to 3x times slower for something on the order of 5x to 20x quality.

That higher quality might pay off long term for the buisness in hard to measure ways, such as faster future extenssion, better customer experience, less work required on bug fixing, etc. If that's what people mean by 10x, I agree, they definitly exist, in fact, compared to the worst there's probably infinite x as people are saying, some programmers can't ever get certain things to work at all.

P.S.: Actually, I've seen maybe 2x or 3x productivity on teams with uneven standards, generally lacking code reviews. In those cases though, the 2x or 3x productivity programmers always had similarly lower quality code.

<comment><USER22> "scrum" I found your issue. I don't think 10x developers work in places that do "scrum", as if they are some low skill assembly line worker. You think Jeff Dean does "scrum"?

<comment><USER23> So 10x programmers don't work anywhere with a somewhat objective performance metric? I don't think that's a coincidence.

<comment><USER24> No. Rather, they avoid places which employ procedures designed to get consistent output out of mediocre workers. Such processes naturally exchange flexibility for consistency of results, but lack of flexibility will cripple a 10x programmer.

</comment></comment></comment></comment><comment><USER25> Here's a question: Is Picasso a 10x artist?

The thing about the 10x claim is that it takes something complex and creative and applies a scalar multiplier to it.

Talking about 10x programmers is _semantically_ problematic.

<comment><USER26> It's a self-serving mythology, because a few individuals can claim to be 10Xers to gain special privileges.

It's telling that there's no such thing as industry talent matrix. Instead of general skills - creativity, accuracy, speed, debugging insight, ability to learn new languages/frameworks, team leadership, good-to-have-around vs toxic asshole, and so on - we have this myth of "the rockstar".

A certain kind of management loves because rockstars because having them around reflects well on management (reason number one for hiring them) and supposedly they are super-productive (reason number two, which often turns out not to be true in practice, especially in a team setting.)

The hiring process tests for almost none of the qualities on the talent matrix. There's a ridiculous notion that knowing algos makes you a developer worth talking to, and a slightly less ridiculous notion that a bit of hazing tells you something about how well someone works under pressure.

The bottom line: that after all these decades we have far too little research defining the qualities that really matter in different work contexts, and almost no research at all into how to select for them.

<comment><USER27> There's also a certain kind of person who seems to really want 10x people _not_ to exist.

I'm not a 10x person, but I have worked with some. I don't think they are unique to programming..there are 10x folks in every field.

Sometimes you don't need a 10x person, and if you don't, it can seem like they don't matter. In those cases, a few 1x people will do just as well. But I do believe that sometimes you _do_ need a 10x person, and if you do, you can't do the same things without them. In those cases, I'd absolutely take a 'toxic' 10x person over the nice-but-1x alternative.

Part of the issue is that there's more work for programmers than ever, and most of that work is of the 1x variety.....if you're just banging out CSS for some small-business website, it doesn't matter whether you have Jeff Dean do it, or a new grad from Omaha Community college. If, however, you need to write a new globally consistent database abstraction at scale, then the new grad probably won't cut it. If you actually need that thing, then it wouldn't matter if the new grad was the nicest person on earth, and Jeff Dean the most 'toxic' (though actually I understand that he's a very nice person).

</comment></comment></comment><comment><USER28> > 10-fold difference between the best programmers and the worst.

He cites this as evidence and _still_ goes on to talk as if the observed 10x-ers were 10x average. Then he tries moving the goalpost, with talk of high-level project decisions and code not written. Just come out and say, "A _true_ 10x programmer does X, Y, and Z. A _true_ 10x programmer would never do A, B, and C." Sounds more like a certain fallacy involving Scotsman when phrased that way.

The only saving grace is that he backs off and recommends against a hiring strategy targeted solely at ninja rock-star devs, but then he reinforces the boogeyman of negative programmers

I get that some people are _good_. There's nothing outlandish about Peopleware's cited figure of 2.5x average programmers, but that's not so incredible that the 1x devs need be weeded out. There must also be a handful of developers with IQs of 160 walking around, but there's too much demand for talent to act as if such rarities are the baseline of who's employable. None of this is worth continuing to blog about.

</comment><comment><USER29> > Imagine traffic increases exponentially, and this average team setup an > average website, with a data storage engine that's hard to shard, hosting > that doesn't have enough redundancy, version control without proper backup, > no CI environment, and no monitoring. How productive will those 10 coders be > if they are spending all their time putting out fires?

The 10x developer may or may not be a myth, but the idea that you can design your system for exponential traffic increase without any tradeoffs is not engineering, it's fantasy. I guess "no silver bullet" is dead in the year 2017.

<comment><USER30> This was a weird example to me because anyone who's dealt with exponential traffic increase knows that you will end up rewriting several times. Dean's Law: "Plan for 10x growth, but expect to rewrite before 100x":

[https://static.googleusercontent.com/media/research.google.c...](https://static.googleusercontent.com/media/research.google.com/en//people/jeff/WSDM09-keynote.pdf) (page 11)

Additionally, one thing the best programmers I know have all drilled into me is _don 't write code speculatively_. You should write code because it solves the problem you have now, not the problem you think you're going to have in a couple years. It's very much a novice mistake (one that I've made a dozen or so times, sigh) to think that you can jump straight to your "ideal" architecture without any of the steps or missteps along the way.

<comment><USER31> THIS:

 _It 's very much a novice mistake (one that I've made a dozen or so times, sigh) to think that you can jump straight to your "ideal" architecture without any of the steps or missteps along the way._

Code evolves as the problem evolves and NEEDS to be adapted. Is impossible to foresee the future.

<comment><USER32> This approach generates regular expensive rewrites that a typically slightly more flexible and/ or modular solution would avoid.

The key words are slightly. The trap is to overgeneralise or apply a technology or approach like a hammer without understanding its limitations.

Out is impossible to foresee the future, but trivially easy to see current requirement and extrapolate a bit.

<comment><USER30> The problem is that you usually don't know in which direction that flexibility will be required.

I can't count the number of times I've "trivially extrapolated a bit", showed my boss or VP, and then gotten back "actually, we don't want to put any more effort into X. I appreciate how you went above-and-beyond, but priorities have changed, and it turns out we really want Y instead," followed by much handwringing when I go back to the code and find out that the flexibility and modularity that I built into the system expecting we'd do more of X next actually impedes progress in making it do Y.

Lest you think this is just bad management - I work for myself now, on a startup, and I have the same problem (or would had I not beaten this habit out of myself). Very often, I'll think "Woah, there's a much more elegant approach that will let me do Y and Z much better at relatively low engineering cost", and then I'll finish X, and put it in front of potential users, and they'll say "Actually, we don't care about Y and Z at all...why would we want them? We want to do A and B instead", where A and B take the product in a completely different direction from Y and Z.

There is a place for planning a little bit ahead, but that place is to plan to reach the next milestone as quickly as possible. You should never try to guess what the milestone beyond that is without checking in with users or management.

</comment></comment></comment></comment></comment><comment><USER33> There may or may not be 10x programmers - I, personally, find the reasoning in the article convincing. And I think there may be programmers that _vastly_ outperform others in programming tasks. So I think there may be 10x programmers.

But, I believe it does not really matter (at least most of the time, most meaning something like 99%).

We are working in teams, inside a company that has a certain culture, rules and processes. How we work together as a team and how the company/culture/system we work in helps us in / prevents us from doing our work has a much greater influence in overall results than individual programmer performance.

This also includes how the system supports us in learning (not only formal training, even though this might be beneficial) and teaching. Teaching each other skills needed for the job, and learning how to work together so that we amplify our collective skills and dampen our shortcomings.

<comment><USER34> It also doesn't matter if 10xer's exist for most companies.

Most just don't have the money, culture, management, fellow coworkers, or whatever else to keep that 10xer (often times even get them in an interview).

Seriously most companies can't even keep a 10xer janitor if they tried.

</comment></comment><comment><USER35> Hip firms only hire 10x programmers. They don't pay 10x though, the total compensation is closer to 0.7x + free session beers. For some reason, results have been mixed.

</comment><comment><USER36> Like so many discussions that bring out the same old discussions year after year, this one is marred by

1) Oversimplification

2) Arguing over semantics

The term 10x engineer is particularly bad because it implies something: that some engineers are just generally 10 times more productive than others. I'm pretty sure most engineers would be vehemently opposed to their performance or value being _quantified_ , so why do we even bother arguing about it?

If I remember right, this term was inspired by some study that showed that some students did their CS homework at a school (CMU?) 10x faster than other students, and the implication that some engineers are just _that_ much better than others as to deserve distinction.

Anyway, this is obviously true. There are some things that simply can't be written or designed by the average coder (or teams of average coders, for that matter), say important bits of the Linux kernel, key optimizations for your latest AAA titles, hairy distributed protocols, etc. No amount of project management will turn a team of average coders into one able to produce such things. In these case, the exceptional coders are more like ∞x than 10x.

And in other cases, you might only see a marginal improvement in performance if at all. If the task is particularly dull, a previously ∞x coder might turn completely unproductive.

Can we just all agree the term is stupid, evokes a sort of reliance on metrics we all hate, that hiring a team is more complicated than assigning value to coders and maximizing, and just move on?

<comment><USER37> "say important bits of the Linux kernel, key optimizations for your latest AAA titles, hairy distributed protocols, etc. "

THe thing most people lack in all those examples is body of knowledge, not aptitude. All those areas are learnable by average developer.

</comment></comment><comment><USER38> I have no doubt that there are programmers who are 10x as productive as other programmers. I witnessed it over and over.

But as I understand it, the "10x" means 10 times the productivity of an average programmer. I wonder how productive the average programmer is. I find this question super interesting.

For example, I see more and more programmers who use "Query Builders" and "ORM layers" without understanding the underlying database mechanics.

Coding this way not only takes multiple times longer then - for example - <USER2> writing plain SQL. It also often results in code that runs hundreds or thousands of times slower. And complexity explodes as the project grows.

I have the feeling that - with the rise of frameworks - this might be the new "average" of coding. If so, then there definitely are coders who are orders of magnitude more productive then this average.

<comment><USER39> This is not only about frameworks and ORMs, it's about refusing to comprehensively understand stuff before you use it or change it. It can be any abstractions, even (usually) the ones you created by yourself.

It's easier to add a special case check, than to read through the codebase to see if it's even needed, or, God forbid, to refactor in 5 places so it's not needed (it might break sth else!!! I would have to read and keep in memory the whole control flow of the program!!).

Programmers have to do dozens such decisions every day, so after a few months if they go the easy way too often it adds up and creates chaos.

I've done this myself, and seen this done by younger programmers. It's that crucial skill of stepping a few steps back and looking at the code as a whole.

I've seen a great compact example recently, one of the students I supervised wrote sth like this:

        List<Person> findBySurname(String surname) {
            List<Person> persons = session.find(surname);
            if (persons.size() == 0)
                return null;
            return persons;
        }

        ...

        List<Person> persons = findBySurname(surname);
        for (p : persons) {
            p.doSth();
        }

The student wrote both methods, and got rejection from tests because of NPE. He wanted to fix it by adding if (persons != null) { ... }

:) this example is easy, but in more complex situations it's easy to do the same, and it adds up. This is one of the reasons I dislike OO programming (especially the kind where you hide everything behind a few layers of interconnected objects). Because it makes it harder to understand what REALLY happens on the data level.

<comment> UK-AL I think types should not be nullable unless explicitly specified.

<comment><USER32> That, much like a null check, solves only a special case.

</comment></comment></comment></comment><comment><USER40> Those who complain most loudly about the 10x being a myth are those whose self opinion of their skill (placing themselves as a 10x), and their actual level of skill (placing them a 1x) are too far apart. Often they don't realise what their actual skill level is until then meet and work with a real 10x in the flesh. This makes sense because why would you care if people believe there are 10x programmers or not? Why would you be upset if people are going around tweeting that unicorns are real? It makes no difference to anyone. It's only a problem if it rubs up badly against your self-esteem.

</comment><comment><USER41> It is not the developer that is 10X. It is the environment they work in that is an enabler of 10X productivity. If that environment is also relatively stable, a smart developer can learn all the levers that the environment/company provides to them, and start achieving hyper productivity. But move that developer to a different company and they could be a dud. Even just an increase in the instability of the environment can thwart hyper productivity.

The focus here is on entirely the wrong thing. It is the development environment provided by the company that enables above average developers to surge into hyper productivity. Good programming practices. Competently prepared requirements. A collegial atmosphere that encourages frank and open communication between departments.

Searching for 10X developers is like looking for a silver bullet. Silver bullets do exist in the real world but ask a shooter whether they provide results any better than the common kind of ammo. Mythical stories can be fun but in the real world we have real work to to, real problems to solve, and while you can find shortcuts generally you don't find them by looking from them. But dive into the messy chaos of creating order out of nothing, and from time to time you will come across real honest to goodness shortcut opportunities that may provide up to a 10X increase in productivity. Use them if you can, but don't waste a lot of energy in chasing them.

Also, the idea of a 10X rocket scientist is rather glamourous. But the fact is that there are real opportunities for productivity improvements that are in the boring details, slogging through improvements in processes, making small incremental improvements continuously and consistently. There is more to learn from refactoring than from chasing clouds.

<comment><USER42> Some people have read far more than ten times as many math and programming books than others, and spent far more than ten times as much time making sure they thoroughly understand what they've read; and then gone on to tackle ten times as many hairy projects on the edge than others because it was fun for them.

True, an environment can encourage the laggards to catch up or fire 'em if they have no interest in improving their skills and knowledge; but it can't wave a wand and create the skills. I would also note that there are tenX (plus) refactorers who can freely cut large amounts of code from large projects without risk, too.

If you started tackling mathematical puzzles when you were eight, and programming a couple years later you're a different species than someone who switched majors to computing in third year for financial reasons; the early starter's brain is actually physically different (for instance some of your visual cortex and memory will now likely be devoted to math and logic instead of geography, this has been measured in chess players.) Same with a concert pianist vs someone who started playing the piano at age 20. Sure, the environment of the concert hall or practice hall matters - just not nearly that much.

I agree we do need to spend more time paying off boring technical debt, too; though that's not getting much more popular.

I don't want to leave the wrong impression. There's absolutely nothing wrong with doing a very conscientious job of coding and recoding that a whole lot of others could also do, just with a better ethic and constant attention to detail - we need many more such coders too, and I honor them very much.

</comment></comment><comment><USER43> Something I saw on Twitter once:

How to be a 10x programmer: make 10 other 1x programmers into 2x programmers.

<comment><USER44> This only works when the programming task is highly parallelizable.

<comment><USER45> That's called project management fwiw.

<comment><USER46> Turning 1x performance into 2x performance is people management.

<comment><USER29> Tools writing.

<comment><USER47> Tools writers really are the unsung heroes of the development world.

</comment></comment></comment></comment></comment></comment><comment><USER48> I find the arguments in the "Programming is about choices" section a bit contrieved.

Yes, if you have a small team of say 10 people, a very competent lead engineer can make all the difference by setting up proper testing, SCM, CI, etc. i.e., by choosing the right tools and people for the job.

However, as soon as you have a slightly larger team, these decisions will usually not be made by one single person. If you have a large project with dozens or hundreds of engineers, you'll have dedicated teams for some of these tasks, making their own desicions.

In my opinion, the most important thing then is to spot anything that will make things go haywire, communicate them and convince the right people that this has to be fixed. If you force a new porgramming language onto the whole team because it makes you, the 10x engineer, more productive, you might face endless discussions, additional training costs and a big backlash ("why do we need this now?") from the team.

<comment><USER49> Why do you assume it's all about code?

When I look at _great_ developers, they can not only build things without taking as many dead ends but they can explain why and share their reasoning with the rest of the team effectively.

The very best can not only complete their own tasks well but their "prowess" (for lack of a better term) is witnessed and people seek out their advice.. therefore making others more effective too.

</comment></comment><comment><USER50> Arguing that 10x developers _don 't_ exist strikes me as the extraordinary position requiring extraordinary evidence, rather than the inverse. People vary; why wouldn't they here?

Some people argue, essentially, "programming is complicated," but even if you want to claim that programming consists of multiple dimensions along which programmers can be measured, how about when one person outperforms another on every dimension by a factor of ten? What should we call that other than _one person being ten times better than another?_

Other people argue that while 10x developers may exist, teamwork matters far more. Well, what do you suppose would happen then if you managed to assemble a team of _only_ 10x developers?

<comment><USER51> People vary yes, but do we have 10x variation in performance? Actually for 10x to be a meaningful size, would need significantly more variation. Can one find support for such level of variation in other, more well studied fields? Say students, managers, factory workers?

<comment><USER50> Sorry for the downvotes; I upvoted you to correct. I think it's an interesting question. There are probably fields where it's possible and fields where it's not.

Some students certainly outperform others by a factor of ten. I'd hesitate to score managers numerically, but it seems plausible that working for one could feel ten times more smooth or whatever than working for another, whatever that means. Intuitively, probably not factory workers, but prove me wrong.

10x is not actually that much. I could play basketball with Michael Jordan or chess with Magnus Carlsen, and they'd win essentially an infinite number of games against me without losing once. That doesn't mean they're infinitely better, because theoretically I could through practice become as good as them, but the factor is way more than 10.

<comment><USER51> Re 'factory worker'. When I studied, I worked part-time in a shop selling bicycles. One of my main tasks was assembling & tuning the bicycles (they come flatpacked). I recall that on my first day (as a 14 year old with no prior experience), I could only complete one bike, with another one in progress. The teaching was mostly 'here are the tools, tell us when done/stuck'. A couple years, maybe 1000 hours of experience later, I would average around 3 bikes per hour. So, a factor 12-15 speedup. This was basically as fast as the guys who had been doing it 20-30 years full-time. I stayed basically at that level until I stopped at 6 years. Note, this was no sweatshop, just a pretty active and successful self-owned store.

It is possible that those that assemble Ikea furniture for a living have 10x over a typical Ikea-buyer.

<comment><USER51> I can also do programming things in 1x which friends who fiddle with Arduinos can't do in 10x the time. But they are non-professionals, and may even stuggle with fizzbuzz.

But in a professional setting I've yet to meet a single developer I would claim to 10x. Probably not even 5x. Unless one would look isolated at tasks that requires specialized or domain knowledge which the other person doesn't happen to have. And I'm pretty sure there would be tasks where same person would nX me.

</comment></comment></comment></comment></comment><comment><USER52> This completely misses the point. Nobody is denying that they exist; it's that they are completely irrelevant to software engineering because software engineering is delivering consistent (not necessarily "outstanding" or "very good") results with the fat part of the bell curve.

Yes, you can deliver a project with the right person with 100th of the effort, but this is not repeatable (the person will move on or very likely work as singleton contractor). If you get a 10x developer at the rate of the 1x developer and can convince him to stay at this pay grade, then we would be having an actual topic to discuss.

<comment><USER42> Look at the number of massive outright software project failures (no delivery, ever.) I think there are many times when you'll cheerfully pay at least ten times for the one guy who could actually get you to the finish line.

</comment></comment><comment><USER53> Many personal attributes are normally distributed. Normal distribution is formed as a sum of several independent random variables with mean and variance.

There are reasons to think that productivity is multiplicative and not additive property, leading to log-normal distribution. Person who is hard- working × experience × motivation × single-mindedness × self-management skills × 2sigma IQ can get ahead of person who just has the smarts.

Prime example of '10x' programmer is Richard Stallman.

Extreme Pair Programming - Guy Steele and Richard Stallman [http://cycle- gap.blogspot.se/2007/09/extreme-pair-programmin...](http://cycle- gap.blogspot.se/2007/09/extreme-pair-programming-guy-steele-and.html)

</comment><comment><USER54> Yeah, the first argument backs the notion that there are developers who are 10x better than than the worst developers -- I take "10x" developer more to mean 10x the average/typical developer.

Also I love, love this line: "10 engineers writing the wrong code could definitely be out performed by a single engineer writing the right code."

Especially as it extends up the chain -- 10 employees building the right product can outperform 100 employees building the wrong product. Etc.

</comment><comment><USER55> "They found no relationship between a programmer's amount of experience and code quality or productivity."

and

"From years of experience, a great programmer will know that errors are much more costly to fix later."

So which is it?

<comment><USER56> Contrary to @iaweihli, I think the error is in the first one and that they originally meant: "They found no relationship between a _0.1x_ programmer's amount of experience and code quality or productivity."

</comment></comment><comment><USER57> I've certainly known some 1/10x programmers. I'm a 10x programmer by comparison.

<comment><USER58> How about negative-times programmers: Programmers that decrease productivity by introducing bugs and broken features that costs more time to manage & fix than the sum of the value added.

Programmers writing features that add points of failures to previously working systems

<comment><USER59> Oh yeah, those abound... and they tend to believe of themselves they're the 10x material that no-one understands. That's case study Dunning-Kruger

<comment><USER23> I think management believes this too. They're checking off their tasks list like crazy, so they must be productive...

</comment></comment></comment></comment><comment><USER59> Obligatory reference to a book that spends quite some time on - debunking it - this 10x myth:

[https://leanpub.com/leprechauns](https://leanpub.com/leprechauns)

I liked it

</comment><comment><USER60> It's really not that difficult to explain, Programmers are like musicians. You have the ones that have over 100,000 hours of dedicated professional practice and are grandmasters, those that play in a band, and those that do it casually.

</comment><comment><USER61> 10x is a metaphor. I believe we also have 2x, 3x, 8x dev's, it's a very relative factor. But it sure is an illusion to think that 10 average guitarists together will produce better results than hiring Paco de Lucia or Jimi Hendrix if you like.

It all depends on the job to be done and being the right fit. But some people have this talent and skill to make the right decisions split second, over and over again.

I definitely prefer one 6x dev over 6 average developers that are creating a horrible spaghetti of bad ideas and poor decisions, not talking about all the meetings they need to align and try to fix the mess they continuously create themselves.

</comment><comment><USER62> The difference between an average programmer and a "10x average" programmer is in the architecture and design phase, not the "fill in the methods for the API" stage. If you put people who don't have domain knowledge (or experience) in charge of API design the resulting codebase will easily take 10x longer to complete (if it is ever finished), and maintenance will probably require 10x the manpower.

Doing good design and tooling upfront is at least a 10x opportunity. Too often I've seen it get brushed off by people who want to see quick results, to the detriment of the long-term design goals.

</comment><comment><USER63> After doing an extraordinary number of technical interviews of people, I began to think of it as a Gaussian curve with a normal distribution. Despite headhunter filtering, resume filtering, and short phone interviews, one out of six people slips through those filters without knowing much. On the other hand, one out of six can answer pretty much every question, clearly and in some depth. These are the people, the unprepared and the very prepared, who are one standard deviation below and above the mean. Insofar as the other four of the six, they all are more-or-less average. They are working at the job, and are competent, but minimally. They can give basic answers, but can't go into much depth on most topics. They are kind of an amorphous blob that blend into each other.

For example, I used to ask sysadmin/devops people what syslog was. One of six would not know, four of six would give a basic answer, one of six would give a more in-depth answer. Then I would ask what syslog's various facilities were and what the severity levels were. Only one of the six would give a good answer.

Actually, I program Android now, but knowing the order of severity is still useful as it is in the same order in the Log class (althouh they add one beyond DEBUG - VERBOSE).

Once I read an article about the top people at Google, and they claimed these people are three standard devíations above the mean. I noted that the author saw this in the same pattern I did.

<comment><USER64> And yet there is no real scientific evidence that performance on technical interviews actually correlates with job performance.

</comment></comment><comment><USER65> Its not about programming skill, its about focusing on the right thing. Many very technically good developers can be very productive at engineering stuff no one needs.

</comment><comment><USER20> The natural follow-on questions are:

What are the decision-making habits that make someone significantly more productive on a software engineering team?

What are ways to imbue a team with these habits?

<comment><USER42> Good questions. You should post an AskHN for this.

Someday we'll have "problem-solving" classes in elementary schools to help teach those basics; and better unambiguous communication, etc. One habit that's been well-documented for a long while is that the best problem-solvers take more time being sure they've understood the problem correctly and settling on an optimal approach before charging in doing the work.

The best habits that often spring from good character - I agree with Bourne on that - those with neurotic motivations or insecurities may choose "solutions" that show off their ability with some extra arabesques, rather than taking a more straightforward path that's best for the company, for example. Not to mention being willing to possibly embarrass yourself by asking what may or may not be "dumb questions." That's huge.

</comment></comment><comment><USER66> I think we should talk more about 10x organizations. A lot of people can perform well if they work in a good environment. Most 10x people I have seen had the ability to do what they needed to do to get the job done. Give them a process where they need approval for everything and have to report every day I think the 10x is gone soon.

</comment><comment><USER67> "There are only a handful of people who can tell the difference between you and me, but I'm one of them" \- Professor from Good Will Hunting

The main difference (besides using vim) of a 10x programmer, is being able to immediately envision 5 ways to solve the problem, mentally following that path and seeing the pros and cons of each.

The 10x programmer probably does really hard stuff on weekends for fun.

The 10x programmer doesn't give a shit about your paradigms if they don't make the code more maintainable.

The 10x programmer's code is fun to read.

The 10x programmer's code could be read by a non-programmer and they could understand the jist of it.

The 10x programmer can't tell you the 'most interesting bug' they've ever found. The solve bugs all the time. They solve them and move on, and remember the lesson, but not the bug.

The 10x programmer doesn't fit in well at the office and usually has to start his own business.

He also types fast.

<comment><USER68> > _The 10x programmer doesn 't fit in well at the office and usually has to > start his own business._

Is a 10x programmer also a 10x businessman?

<comment><USER69> Perhaps there are many roads to 10x!

What if 'x' is transitive? Is the 10x programmer, 10x businessman 100x?

That might explain things. I've seen plenty of 0.5x programmers who are 20x bullshit artists.

</comment></comment></comment><comment><USER70> I wonder what you should do if you are one of these 0x programmers. Throw away your degree and change career? Or try to close the gap? But what if you really aren't able to become one of the 10x?

I wonder because I feel that this is my situation. The people I started working with are so much above my skill level, it's ridiculous.

<comment><USER71> If you really are 0x then yes you're in the wrong job. But first read up on [https://en.wikipedia.org/wiki/Dunning–Kruger_effect](https://en.wikipedia.org/wiki/Dunning–Kruger_effect) and [https://en.wikipedia.org/wiki/Impostor_syndrome](https://en.wikipedia.org/wiki/Impostor_syndrome) because those are much more likely than a 0x realising they are a 0x.

<comment><USER42> I like this. Plus, related to the Imposter Syndrome - you might be conscientious, and they might not be.

</comment></comment></comment><comment><USER72> I'd suggest there is no quantifiable way to measure what "a good programmer" is.

Nor is there a way to quantify "good code" in any scientific manner. It IS possible to identify obviously bad code, BUT "good code" comes in a variety of forms and looks different depending on the experience level of the developer.

In the end, many of the measures that people apply to assess programmers are simply a matter of personal opinion.

edit: downvoters - if you think I'm wrong then please explain your counter opinion, don't just downvote. A downvote without a counter opinion simply confirms my assertion that there is no science to this because you won't identify what that science is, you have only a vague opinion that I am wrong.

<comment><USER42> I disagree - wish you hadn't used the word science when you probably meant verifiable or respectable, too - but I upvoted 'cause you used a great transcendental argument vs your downvoters. My comments on measuring are elsewhere here. I think it's difficult, and something Muggles in management get way wrong most of the time, but that's another matter from whether it can be done or is done, all the time.

</comment></comment><comment><USER73> Strongly agree. I've worked with several.

Now have a blast whatabouting, caveating, and arguing definitions!

</comment><comment><USER74> My problem with the concept of a "10x" programmer is that its baseline is not well-defined. Who's the 1x programmer? Figure that out and then we can have a fun discussion about the existence of 10x (and maybe -10x) programmers.

<comment><USER42> It's a baseline that's changing rapidly (mostly for the better) and that will be so for a while. So it can't be an absolute value or static variable.

</comment></comment><comment><USER75> Another way to think about it : have you, from the time you started working in comp science, to now, become 10x better ?

I don't think a lot of people with 10+ years of experience would say no ( if you do, it may be time to change company).

<comment><USER58> You could extend that logic: Since I couldn't code at some point in time and I can now, I've become infinitely better at it.

Compared to someone that can't code I'm infinitely faster in theory. Do note that in reality, if someone that can't code needs to write code, he'll likely learn to code first. However, once he learns to write code, he is no longer someone that can't write code.

The 10x programmer isn't 10 times nothing, of course. The 10 times rule is, I think, 10 times better than average. So we have to know the average first.

The amount of programmers rises very fast: IIRC, the amount of programmers doubles every 6 years or so. The average programmer therefore has 6 years experience.

The 10 times programmer has to be 10 times better than that. How is he 10 times better? He has to be able to beat a 10-person team of people with 6 years experience on average. That is a team of 4 juniors with 4 years experience, 3 "medium" programmers with 8 years experience and 2 senior programmers with 10 years of experience.

Imagine a contest where you have to develop a huge SAAS management-like system. One team has the 7 developers described above. The other team is the solo mythical 10 times developer.

Well, I think the 10 times developer is going to have a head start, but he's going to burn out within 2 months, releasing nothing and starting a new project somewhat later. The project manager now has to find a new 10 times developer, but he finds out that no-one can replace him and they need to start over.

Meanwhile, the 7 developers are playing table-tennis and having boring meetings and finish the product much later than planned, but it is done and it sells fine.

<comment><USER75> You're right, my thought experienced only proved that it is possible for a developper to be 10x better than another one, with the same brain, only more experience.

About your project, i had the experience of building the exact same project ( an product demo ios app with a web backend and its content management interface). First project had to be done using "enterprise" practices, and the other was free. First one i did with a senior developer helping me on the web interface side, the other with an intern i had to explain what MVC was.

First project took 6 months, plus 2 more because of some guidelines i didn't respect first, plus a whole team of admins to handle the production side. It probably costed more than 100k to the company ( not counting the internal days spent in meetings). The internal team that was supposed to maintain the code wasn't able to do so.

The other took less than 3 months and costed something like 10k, including server cost (i used app engine). The intern made the project evolve for more than a year.

A 10x developper is not just able to produce more, it can prevent you from falling into traps that can simply lead your product to a complete failure, and your company to simply cease to exist.

</comment></comment></comment><comment><USER76> Demis Hassabis, John Carmack and Elon Musk ARE 100X developers. Why stop at 10X?

<comment><USER61> 10x developer is just a metaphore, not based on some mathematical model. For me it relates to the difference between an average singer in an average band and Prince or Whitney Houston for example.

<comment><USER76> Yah its hard to give it a direct number but to say its a myth is just obviously wrong given the evidence of these brilliant minds we know exist.

</comment></comment></comment><comment><USER77> Comparing developers is like comparing apples to pears. The vagueness comes from the fact that software development is such a broad profession. It is a combination of many different factors, for example handling with databases is totally different than graphics. Of-course there are big differences between beginners and experienced software developers, but it becomes harder when you compare specializations.

Furthermore, I do want to note that understanding user needs can greatly improve your effectiveness. Because not building something can save you multiple weeks or months of programming.

</comment><comment><USER78> If the problems we solve are NP hard problems, it stands to reason that 10x quicker solutions are actually not that impressive and certainly would be very likely to exist. Suggesting that certain people aren't able to arrive at solutions that are an order of magnitude better or develop workable solutions an order of magnitude more quickly is clearly ignoring reality.

<comment><USER42> I had a hard time sorting out your meaning, but adding NP to the mix is delicious so I can't resist replying, and I hope I get it right.

I take it you mean something like this: In the real world, NP hard problems are "solved" by approximations; and the range in the accuracy (and speed) of various possible approximation algorithms is immense in many or most cases. Which means you want your best woman doing the job, 'cause she's easily ten times better than the next man up, in fact her final algorithm might be thousands of times better and faster than her previous try last week and yet still leave a crazy amount of room for improvement, one day.

</comment></comment><comment><USER79> The problem with this 10X myth is that no one ever defines X. Lines of code? Inverse of defects found? Delivering in 1/10 of estimates? There is no definitive way to measure the end result of what people develop and any of these values can be gamed. Clearly there are major differences between programmers but turning it into math is not really possible.

</comment><comment><USER80> I think everyone can have a 10 times day or week or project but outputting at that rate over a long period of time is the issue.

</comment><comment><USER81> Referenced study: Exploratory experimental studies comparing online and offline programming performance (Sackman, Erikson, and Grant) - [http://dl.acm.org/citation.cfm?id=362858](http://dl.acm.org/citation.cfm?id=362858)

</comment><comment><USER82> The area that I see this really come into play is with problems that the developer initially doesn't know how to solve. Some developers learn and adapt 10x faster than the average developer, and it seems like they're never blocked.

<comment><USER83> IME a more common case is overengineering. Not only does this slow someone down initially, but the extra complexity often continues to slow them (and anybody else in the same codebase) into the future.

<comment><USER82> Yeah, that's part of what I meant. If the path is totally clear; "add API to existing codebase, write tests, do CR, commit" then I don't think you see as much 10x behavior. If it's a new technology that the team isn't familiar with, or a tricky API for some reason, then solutions can start getting totally overengineered, and it can spiral out of control.

</comment></comment></comment><comment><USER84> I think the point of "10x" programmer is largely missed because we're looking in the wrong place: at the 10x programmer. It's better to look at what comprises the implied 1x programmer. If it's the mean, then there is a really, really long tail of programmers out there that are really bad at their jobs. It's quite easy to be 10x, 100x, or even infinitely-x better than them.

Infinitely times better? There are just some problems that bad programmers, no matter how much effort they expend, will never solve. Even if I take 10 years to solve a problem that a bad programmer will never solve, that makes me infinitely more productive on that sort of task over the bad programmer.

"But how many problems like that will you ever encounter in your career?" If you're content being nothing more than a CRUD website developer, then not very many. If you want to do more with your career than collect a paycheck, then you can structure a career around doing nothing _but_ solving new, hard problems.

I'm a very productive programmer over most people because not only do I know how to do lots of things, I can employ them very quickly. I know it's popular to say we don't have to memorize things in the era of Google and StackOverflow, but there is a real, significant, large productivity improvement for not having to context-switch. I use Google and StackOverflow, sure, but let's be honest, most of the time is spent just trying to figure out what half the questions are even asking, say nothing about whether or not the "accepted" answer is correct and relevant to our tasks.

No, I don't have everything memorized. It's impossible to memorize everything. But that doesn't mean not memorizing things out of some sort of perverse spite is a winning strategy. No one strategy is the best strategy; a myth we consistently perpetuate in this field despite the constant evidence to the contrary. You have to employ _all_ strategies. But all most programmers have is googling. I have googling _and_ a larger corpus of memorized knowledge.

</comment><comment><USER85> It's all about domain knowledge. Duh.

The value of a software development team is their ability to create new intellectual property similar to things they've made before. (Or maintain an existing system, of course.)

<comment><USER42> It's a big part of it, but careful about what you mean by "domain knowledge." Look at Richard Feynman's stint as an analyst for Kurzwiel as parallel- programming got underway; in theory Feynman had no significant domain knowledge but in fact the immense range of mathematical knowledge he brought with him turned out to be extremely valuable, perhaps irreplaceable for that particular project (given how creative he was.) He really was a (more than) ten times guy, there.

</comment></comment><comment><USER86> Using an analogy of biological evolution, the "engineer" that nails the right "mutation" on a project can impact its scale of success by orders of magnitude.

</comment><comment><USER87> Not just 10x, just infinite. I am fairly a decent programmer but still i think i will be not able to write a kernel from scratch in a decade.

</comment><comment><USER88> The problem here is that the concept got off on the wrong foot and has stayed on the wrong foot since then. The conceptualization of software developers as some sort of industrial worker who churns out widgets all day long is simply ludicrous. In the days back when a lot of software development involved just doing the same thing repeatedly for hire the measurement of "productivity" based on "output" at least had some basis in reality. But that era didn't last long, modern software development is an incredibly automated endeavor. We use automation (compilers, linkers, IDEs, unit test frameworks, and so on and so on) to take out a lot of the drudgery that previous generations had to grapple with more directly. Today productivity in software development is not about churning out lines of code (even assuming it ever was) it's about building stuff that has a high value (to users/customers et al) and low cost (operationally, tech debt. wise, and so forth). And there, of course, the range in productivity spans not just one but _many_ orders of magnitude between the highest and lowest tier of coders.

There is a small group of folks (charitably tiny, uncharitably maybe like 1/4 of all devs) who on average contribute negligible or even net _negative_ overall value vs. cost to the code base as they work. And there are some folks whose individual work has a value of upwards of several billion dollars. In between there are perhaps bunches but it would be a stretch to imagine that there were only one bunch where the vast majority of other devs were collected within a single order of magnitude in terms of the value of their work.

And, make no mistake, I'm not just talking about moving up the "hierarchy" or the management chain in terms of value. Even if you restrict your dev. sample to just individual contributors with more or less identical work responsibilities (instead of say, junior intern vs. principal architect or somesuch) you will still find _many_ orders of magnitude difference in value and quality of work.

The reason why this isn't objectively obvious is that so much of software is invisible. Yes, you can in principle read all the source code but in practice that's not tenable. And we still do not have all of the tools, models, or even terminology to concretely break down the structure of complex software systems into representations that aren't _extraordinarily_ handwavy and overly simplistic basically almost immediately (compare, for example, an electronics wiring diagram versus a UML diagram or a layer representation). That coupled with the fact that software development is a creative and even artistic endeavor where the value of some piece of work can vary greatly between otherwise very similar examples (which is much less true of, say, bridges or diesel generators) means that estimating the value of a given developer's work a priori is enormously difficult. Indeed, that also explains why hiring is such a constant struggle.

<comment><USER42> Back in the day, the concept started out very well as a way of trying to convince Muggle bosses (etc) that coding wasn't pretty much the same as bricklaying, with most bricklayers being about the same in precision and productivity.

</comment></comment><comment><USER89> Would John Carmack be considered a 10x developer? If so, I think we cannot dispell the Myth.

</comment><comment><USER90> antirez on "the mythical 10x programmer" [http://antirez.com/news/112](http://antirez.com/news/112)

</comment><comment><USER91> Surely the 10x CEO is a myth, though?

</comment><comment><USER92> just like the 10x CEO. They just make the right decisions and hence are compensated accordingly.

Companies like MS and google have sufficient data to tell us whether the 10x programmer is a meaningful term.

<comment><USER93> > _just like the 10x CEO. They just make the right decisions and hence are > compensated accordingly._

A lot of being a successful CEO is being at the right place at the right time (of course: _in addition_ to actual qualities).

Anecdote time:

I once was a franchisee of a major (services) franchise that some time ago decided to expand to Germany (I sold my franchise years ago). I'll only talk about one person, but this happened throughout the network, it wasn't nearly as successful as hoped in this country.

So anyway, I personally know one of the guys who lead one of the best franchises in a major German city. He expanded, became responsible for the entire wider area (which allowed him a cut from all franchises in it in exchange for recruiting new franchisees and for advising them).

He had this exact opinion (and he was a former business consultant too, I think he even has an MBA), when a franchisee didn't do well that he just wasn't good enough. He himself was proof, after all, just do your customer acquisitions and all the necessary stuff,and success will eventually come! It worked for him!

When a franchisee failed he acquired their shop, it was in the same city and they seemed to be in very good areas, lots of businesses that fit the description of the target market. Not a big risk one would think given that his own shop was doing exceedingly well with the exact same demographics, just a few miles away.

Long story short, he ended up giving up the franchise for the area as well as the two additional shops he had acquired. Today he has just that one original location. Turned out that the exact same extremely successful guy only managed to be successful in _one spot_. Not even in very promising areas just a few miles away did it work out!

There were more stories like this, some of them I knew personally (through franchisee training at the beginning where I met many of them), all people who were formerly employed and "important people" in their jobs, and who all thought that it's all about _you_ and the effort and skills you put in. Some of them managed to indeed build a successful business, but they all became much more humble over time, because they all found the large amount of randomness in their success when they tried to expand (area franchise or another shop).

So, tell me again about those successful CEOs, I'd like to learn more... the books are full of such people, successful in one place and time and failing in another place and/or time. Because they themselves are only _one ingredient_ into what is needed for success, and not even the major one ("necessary but not [even nearly] sufficient").

<comment><USER42> Right. Survivorship bias. Totally a thing.

</comment></comment></comment><comment><USER94> These things make my blood boil. I'm going to allow the assumption that 10x programmers even exist.

First, it's elitist. This isn't a professional athletics team, this is the workplace focused on engineering. _Most_ places are not chock-full of the 10x'ers; I need to depend on other people to do things for me, and them on me; not all of us are 10x'ers, and it behooves all of us to work as a _team_. The 10x discussion distracts from that: a functioning _team_. Further, people seem to want to worship these "10x" programmers and forget about training anyone; we'll just hire 10x-ers only.

Second,

> _Imagine traffic increases exponentially, and this average team setup an > average website, with a data storage engine that's hard to shard, hosting > that doesn't have enough redundancy, version control without proper backup, > no CI environment, and no monitoring._

This is exactly the output I imagine coming from a "10x" programmer: that person has been able to output at such a constant clip by writing code with enormous technical debt. I've had to work on these systems, and they're a PITA: how productive could _I_ be if I didn't have to deal with the decisions of the guy who, judging by the codebase, was shoveling code out the door as quickly as possible?

(i.e., what if a study held the programmer constant, and varied the environment? I bet I could be _much_ more productive if I worked on a codebase that didn't fight me at every turn.)

Last, the assumption; the article claims there are numerous studies on the matter … and cites none. What we _get_ is a SE answer that contains a dead link to an article containing citations, which thankfully was quoted in the SE answer (but screw hyperlinking to anything). The first I can't find, the second's abstract doesn't seem to support the notion of 10x's ("Understanding and Controlling Software Costs"; the abstract indicates that it's about understanding software cost estimation[1]), the third is a _book_ , not a study, the forth is a study wherein the participants are told to use different methods of implementing the solution (the research appears paywalled, so I can only see the abstract; and thus, doesn't apply), the next is too vague to tell as it "summarizes the results of […] investigations in the areas of design practices, coding techniques, test/verification methods, and computer utilization" and is paywalled, the next seems relevant but is paywalled, paywalled, paywalled, this is also a book ("Peopleware"), this is also a book ("Software Productivity"), this one is relevant and available[2], but it doesn't look like a very big sample?, and the last two I've lost motivation to find.

[1]: [https://ai2-s2-pdfs.s3.amazonaws.com/2147/c6218db2e35d40f4a7...](https://ai2-s2-pdfs.s3.amazonaws.com/2147/c6218db2e35d40f4a7bdb87ed47e3814ef4b.pdf)

[2]: [http://www.dtic.mil/dtic/tr/fulltext/u2/645438.pdf](http://www.dtic.mil/dtic/tr/fulltext/u2/645438.pdf)

<comment><USER42> Controlled experiments are in order. The article cites "Curtis 1981, Mills 1983, DeMarco and Lister 1985, Curtis et al. 1986, Card 1987, Boehm and Papaccio 1988, Valett and McGarry 1989, Boehm et al 2000" I'm sorry the links don't work, but that still sounds like a traceable bibliography to me. I just tested Google on one study, and found it (paywalled I assume) - "A summary of software measurement experiences in the Software Engineering Laboratory Article in Journal of Systems and Software 9(2):137-148 · February 1989 with 19 Reads DOI: 10.1016/0164-1212(89)90016-2 · Source: DBLP"

<comment><USER95> Lauren Bossavit has taken the trouble to trace those citations. His book about his search for the truth behind those claims (and several other common software engineering beliefs) is well worth reading:

[https://leanpub.com/leprechauns](https://leanpub.com/leprechauns)

<comment><USER42> This is a general point, probably should be directed to the article itself, not a discussion on whether the bibliography given there exists or can be found; your URL risks being overlooked at this depth on a different point. Thanks for it, though.

</comment></comment></comment></comment><comment><USER96> There are two kinds of developers:

1\. Those who are good developers 2\. Those who can't write any real code (cargo cult or cut&paste developers, e.g. the 25% who I didn't hire over the years because they were not able to FizzBuzz)(25%-50% of the market)

The 10x comes from comparing (1) and (2) - although dividing anything by 0 is larger than 10x.

<comment><USER97> +1 however I think there is a 3rd kind of developer as well. The 3rd being those who CAN do fizzbuzz/codekata style tests but when faced with a real programming problem in real code base they falter.

<comment><USER98> There are a thousand gradients of skill level, dividing it into 2 or 3 stereotypes is facile and pointless.

<comment><USER99> There are actually just millions or billions of discrete points, one for each programmer. Implying that they can be approximated by some kind of continuous gradient is quite frankly insane and unfounded.

<comment><USER50> The gradient covers all the hypothetical programmers that could exist but happen not to.

</comment></comment></comment></comment></comment><comment><USER100> 10x only works if you're a team player or if the company is organised in a way that encourages team work.

the 10x is just the guy that's already overcome this blocker that a more junior coder could spend a day on, and if the company doesn't encourage teamwork the junior is still taking a day and the senior is appearing 10x when he should be assisting other coders.

there's more value in a team being 3x than one person being 10x.

</comment><comment><USER101> Everyone can point at some poor maniac whose whole self-worth is derived from work and exclaim - he is the 10x. But the fact remains, if you choose the insane as a example, you have a insane standard.

</comment><comment><USER102> Lol

</comment><comment><USER103> This clearly bothers you so much you had to write an article about it.</comment>


All-in-one I-have-no-idea - <AUTHOR> http://www.37signals.com/svn/posts/1612-all-in-one-i-have-no-idea <comment><USER2> The really big thing to look at is ink prices and ink capacity. Some printers have cheap ink made by third parties that lasts forever. Some printers have expensive ink only made by the company that only lasts 100 pages.

That's really the only thing that I research when buying a printer.

<comment><USER3> Another important thing to look at is where the ink jet nozzle is placed. Some printers have this as a more durable part that's separate from the cartridge, whereas others have it in a more disposable form on the cartridge itself.

One lasts much longer, and the other will crap out shortly if you try refilling it too many times. It's a great way for them to keep you going back for the "real" ink.

</comment></comment><comment><USER4> "Buying a printer remains the last confusing part of modern computing."

Graphics cards are just as bad. RAM can be tricky with all the different types and price points. And how are you supposed to compare between the different CPUs with different numbers of cores, processor speeds, L2 Caches, bus speeds . . .

Everything about buying a computer is complicated for the uninitiated. Even hard drives, which should be a matter of picking the biggest one, have different speeds to complicate matters.

Of course, once you've bought a few printers it will all make perfect sense and you'll forget that it seemed confusing.

<comment><USER5> normal computer users don't buy graphics cards or care about cpu l2 caches. they buy things like laptops and imacs that just work and they never upgrade them or take them apart.

unless you're an avid gamer, graphics designer, or building your own pc, i don't know why anyone would even care what kind of graphics card their computer has.

</comment></comment><comment><USER6> The solution to the colour printer problem is not to buy a printer. I've probably spent as much time trying to get home colour printing to work well as I have re-installing windows. These days neither thing (colour printer or windows pc) exists in my life. Use a cheap laser for black & white and when you need a colour print send it to the copy shop/bureau.

<comment><USER7> That's a good idea, but when I bought a laser printer (a Brother) last year, I was disappointed with its quality. (Seemed dim and/or pixelated.) Any recommendations for a reasonable laser?

<comment><USER8> If all you want is a printer, the old HPs are really good. The Laserjet 4 in particular was a high water mark in quality. You can find them fairly cheaply, and if you fix the one problem they have (accordion jams), which is not very difficult and requires about $20 worth of parts, they will basically last forever, and are cheap to run.

The output quality from these printers is about the best I've seen from a laser.

</comment></comment></comment><comment><USER9> Printing needs the equivalent of the ipod or flip video camera: something that was redesigned to do the most common stuff really well and is dead simple easy to use

<comment><USER10> Most printers _are_ simple to use and do the common stuff (printing black text on white paper for non-critical documents) really, really well.

That being said, if you want the iPod experience on a printer, come to a Japanese showroom some time and look for the ones aimed at women. ("You can sell electronics to women?!" -- US tech industry)

Sleek industrial design, appealing bright colors, focused mainly on easy integration with cameras (another consumer electronics item Japan does really well) with every single sample print being "three of the girls having a fun day out" or "the loving family, perfection captured on film".

Printers are not _about_ putting ink on paper. That's just what they _do_.

<comment><USER11> _Most printers are simple to use_

They were 5 years ago, but they're hard again for some reason. Not too long ago you could plug a printer into your router, find it on the network from any machine and print to it. No software install. Just find it and print. If you weren't on a network, you could just plug the USB jack into your machine and print just as easily. Remember plug and play?

For some reason, it doesn't work like that anymore. You need to find the CD and install the drivers, and even then chances are you won't be able to connect to it over the network. Even if you have the USB cable plugged into your box, it's not smart enough to pretend it's a memory stick and give you the drivers you need.

Anybody know what happened there?

</comment></comment></comment><comment><USER12> This problem isnt limited only to printers. In my opinion it is also present when buying internal PC components.

For example how do you choose which graphics card to buy? The model number / name of the product isnt gonna help you at all. So you would think that the specifications would help you compare products. They do, but only to some extent. For example is a 4 core processor at 2Ghz better than a 2 core at 4Ghz? And then sometimes the specs even "lie". For example graphics card RAM is cheap so companies like adding a lot of it to their products. It has come to the point where a 8600 nVidia card I saw had 1 gig of RAM, where Im pretty sure that it can only use half of that.

So all we are left with are benchmarks... which also have their downsides.

More: [http://www.reddit.com/r/technology/comments/7xiub/buying_a_g...](http://www.reddit.com/r/technology/comments/7xiub/buying_a_graphics_card_is_a_lot_like_buying_a/)

<comment><USER3> High graphics card memory has its benefits - it allows the use of high- resolution textures (which has the maximum benefit at high display resolutions). It also allows developers to do more work without hitting your bus, which is the _real_ benefit.

Nowadays all games use shaders, which are GPU programs that can transform images (and geometry, but that's another story). One of the chief pains in graphics programming is the necessity to feed data to the card, run a shader on it, and feed the data back into RAM for lack of graphics memory, so you can make room for something else.

Bus speed is _the_ killer of 3D performance. Pushing and pulling data cross PCI-express 16x is really, really slow compared to how fast your shaders run. More memory really does give you significantly higher performance.

</comment></comment><comment><USER5> i found it ironic that jason ended the article asking for suggestions, and there are now as many suggestions for different models as there were on the page he took a screenshot of.

</comment><comment> cool-RR "they all come from reputable brands. We have options from Canon, HP, Brother, and Samsung."

I think HP printers are junk, at least in the below $500 range.

I recommend buying a Xerox laser printer. In my country I've seen a Xerox all- in-one color laser printer for about $500. It's more expensive than ink printers but you save a lot of money since toners are cheaper than ink.

Aside: How can HP be called reputable? I think they're just living off on what's left of their reputation. Every HP device I've seen was shitty and full of bloatware.

</comment><comment><USER13> don't buy samsung (korean) ... unless you only use windows

i bought scx-4100 3 yrs ago, later on misteriously the mac driver (no scanner, printer only) disappeared from the site

the linux driver is also ugly, breaks security, dirty uninstall, etc ... such a pita

korean loves windows, so don't expect much for mac and linux from them

</comment><comment><USER14> Maybe they are all mostly OK. Personally I would look for Linux support.</comment>


Js-scheme - a Scheme interpreter written in JavaScript - <AUTHOR> http://www.eriksilkensen.com/projects/js-scheme/ <comment><USER2> How is this any better than the existing n+1 scheme interpreters in javascript? Including Crockford's one:

<http://www.crockford.com/javascript/scheme.html>

</comment><comment><USER3> I did (almost) this same thing 12 years ago: <http://joeganley.com/code/jslisp.html> ... though his is more complete and polished than mine, and the interface is nicer in ways that were basically impossible in 1997.

<comment><USER4> Your project was a huge inspiration for me when I first stumbled upon it! I am now using a totally different approach for my "scheme on php" project but your project gave me the notion that it was actually plausible. So thank you!

</comment></comment><comment><AUTHOR> "Starting in version 0.4 two extensions are packaged with the main download: a primitive API wrapper for Last.fm Web Services, and an interface to the flot JavaScript graphing library. "

      (load 'last.fm)

      (load 'flot)

<http://code.google.com/p/js-scheme/>

</comment><comment><USER5>
      > ((lambda (f) (f f)) (lambda (f) (f f)))

      ;InternalError: too much recursion

</comment><comment><USER4> "dude - wheres my macros?"

I will qualify that with: the funnest part of writing "a scheme" is implementing the macro system! Especially as you can use that to implement a lot of the r5 spec itself.

</comment><comment><USER6> Now that is one impressive hack!

The source to the scheme interpreter lives here:

[http://www.eriksilkensen.com/projects/js-scheme/js- scheme.js...](http://www.eriksilkensen.com/projects/js-scheme/js- scheme.js?r=50)

If there ever needed to be proof that JavaScript is a real language then I think that's taken care of now.

<comment><USER7> Really? You mean after hundreds or thousands of non-trivial applications written in / using JS, a cutesy scheme interpreter was the tipping point?

<comment><USER6> No, I mean that a language implemented in JavaScript is sort of a milestone, once you can emulate language 'a' in language 'b' I think that counts for something. My JavaScript knowledge is somewhat dated and this opened my eyes as to how dated it really is.

I was not aware that JavaScript was so versatile, even though I've used it plenty of times to achieve some functionality not present in html. In fact, that's probably the closest I can come to a one line description of the way I viewed JavaScript, an extension to html, obviously I was very wrong.

The html in this case simply is a container for a completely self contained language implementation, so that goes well beyond 'extending the functionality of html'.

<comment><USER7> I find Cappuccino (objective-c-like interpreter) and 280slides (corresponding demo) significantly more impressive, and they're from a YC startup to boot.

<http://cappuccino.org/> | <http://280slides.com/>

There have been major apps written in Javascript for at least 5 years. I mean, a huge slice of the whole "web 2.0" shebang is client side Javascript apps doing asynchronous communication with servers...

<comment><USER6> > client side Javascript apps doing asynchronous communication with servers

that much I'm aware of, but the fact that there is enough general functionality in there to be able to stick together a complete implementation of another language was definitely news to me.

I've been using JavaScript since its introduction to deliver 'video' (as in one jpeg replacing another) for the longest time, and I found a way to do an underwater call to the server long before 'ajax' even had a name or microsoft introduced the corresponding http request call.

I'll look at the examples you cited, it definitely sounds like cool stuff.

</comment></comment></comment></comment></comment><comment><USER8> Also check out <http://www.jsconf2009.com> where JavaScript developers will be rallying to discuss how to use JavaScript to build cutting edge mobile, desktop, server, and web applications. If you have any interest in deep JS tech, you should be there.

</comment><comment><USER9> This is absolutely kick-ass!

No foldl or foldr though?

<comment><USER10> As if they're hard to write...?

        (define (foldr f end xs) (if (null? xs) end (f (car xs) (foldr f end (cdr xs)))))

        (define (foldl f start xs) (if (null? xs) start (foldl f (f start (car xs)) (cdr xs))))</comment></comment>


Book Review: Coders at work - <AUTHOR> http://dfectuoso.com/?p=246 <comment><USER2> I bought the book with high hopes, but to be honest I found it a little dry. About halfway through I had to give up on the idea of reading it cover-to- cover, and instead just cherry-picked the interviews I wanted to read. It lacks a lot of background info on the interview subjects, so unless you are familiar with them you may find yourself lost as many historical and technical details are referenced without additional explanation.

Personally, I thought "Founders at Work" was a much more interesting read and would recommend checking that one out first.

<comment><USER3> I'm busy reading both now and I'm in total agreement. I am, however, reading it cover to cover.

I've learnt a lot, but that's because I went and read up about the topics that I didn't know about.

I'm also enjoying founders at work more.

<comment><USER4> Yeah I have found that, stumbled across quiet a few things I knew nothing about, looked them up and learned even more in the process.</comment></comment></comment>


An Open Letter to Elon Musk from Ariana Huffington - <AUTHOR> https://www.thriveglobal.com/stories/40343-open-letter-elon-musk <comment><AUTHOR> While there is some truth to what Ariana says, scientifically, and she gives one example from FDR, who was a manufacturer of ideas, I would argue the most difficult tasks in history were achieved through the strength of will.

I'd also observe Elon is paying the price for setting out to do something extremely difficult, and though it appears that he's losing right now, he'll come out on top as long as he stays the course. Taking a long vacation, though it may be the best thing for Elon's health, is arguably not the best thing for the company right now. A long weekend is probably in order, but I hope Mr. Musk can find the strength to keep doing what he's doing because it's working (sans the late night tweets and poor choice of Grimes' so-called friends).</comment>


Port scanner written in x86 assembly (32-bit) - <AUTHOR> https://github.com/edma2/asmscan

<comment><USER2> Hack value: moderate to high. It's nice assembly code.

Practical value: low to negative. This port scanner is slower than a competently written scanner in C or probably even Ruby, because it has a static timeout and no dynamic timers.

Someone else here pointed out that a port scanner is pretty much the most I/O bound application possible. That's true. The performance wins in port scanning probably mostly revolve around maintaining sliding windows and trying to infer timeouts.

It is probably a really excellent technique for getting comfortable with assembly (I'm not, at least so much that I could write this code as cleanly as the author). I wonder what some other good short assembly versions of Unix programs are. Maybe a plugboard proxy.

<comment><AUTHOR> Actually, if you run asmscan as root, it pings the target host first to estimate the timeout value. Otherwise you're out of luck, because you need root privileges to send raw packets.

IMO, it is quite fast with this feature.

You're right, I wrote this for educational purposes. nmap is hard to beat ;)

</comment></comment><comment><USER3> Oh... indented assembly language. Is this, like, a 21st century thing? Everybody I know (including me) who started in the 20th century just naturally writes their assembly language out at the same indentation. I'm rigorous about my C indentation, but it never occurred to me that it would be useful for assembly language too. (And in fact I'm not sure that it is :)

I'm not quite sure what this might mean.

Probably just that I'm old.

<comment><USER4> It used to be called "Structured Assembly Language"; it had huge proponents in the 80s, even gurus who were trained in Pascal and Ada and wanted to take structure programming to the mainframe.

On the PC, various assemblers added "high-level" macros; Turbo Assembler had .if, .while and .struct type macros. Even processor manufacturers where on the bandwagon; that's why the x86 has the ENTER and LEAVE instructions, to make function calls "trivial", at the risc of performance.

In the 90s you had at least on academic (Randal Hyde) who wrote HLL, high- level assembly language, and along with it a very successful series of text- books on indented assembly.

Anyhoo. On the x86 side at least, the Netwide Assembler was created by a bunch of volunteers, one of its initial goals was to remove high-level cruft and make assembly straightforward again.

Personally, I think assembly is something best reserved for fun, one-off hacks, and inner-loops.

<comment><USER5> > at the risc of performance

that's some good punning.

</comment></comment></comment><comment><USER6> Pointless other than as an exercise in asm writing. A port scanner is one of the most I/O-bound applications imaginable.

<comment><USER7> It doesn't depend on libc. It might be useful in penetration tests or other particular scenarios (port scanning being quite particular job in itself).

<comment><USER2> Aren't there tens of portscanning shellcode eggs already?

</comment></comment></comment><comment><USER8> Normally I wouldn't ask. I really wouldn't.

But why? Why's this better than gcc -S?

It's not exactly CPU-bound. For not needing libc, your own implementation of syscall() isn't exactly hard, if you can't just statically link in libc as-is.

</comment><comment><USER9> It makes calls into [C?] libraries that handle the actual networking. Not quite as impressive as I was hoping. "...in assembly" tends to make me think "implemented completely and entirely in assembly." I know, not necessarily a common connotation, but that's how _my_ brain works.

At any rate, my point is you can "glue" functions from libraries together in any high-level or low-level language you want and make whatever app you'd like. I'm having trouble seeing the novelty in writing the app in asm but letting the libs do the heavy (and perhaps less-optimized) lifting.

<comment><USER10> It's making (linux) system calls via a software interrupt. There's no integration that I see with anything above the kernel.

But yes, I suppose it's "merely" gluing together straightforward system calls. A port scanner doesn't by itself have a lot of complicated logic.

</comment></comment><comment><USER11> in 1985 i would have loved reading this end to end. now, looking at assembly makes me want to stab myself in the eye with a fork. twice.

does that make me old?

now, where is that Scala book and my glasses.

</comment><comment><USER12> This reminds me of the tool that HBGary was planning to write.[0] They thought that using assembly would make it a super-duper fastest-ever scanner! The author of this tool clearly doesn't have the same delusions, even noting that its about as fast as nmap.

[0]: <http://news.ycombinator.com/item?id=2315564>

Edit: Turns out that HBGary didn't mention writing it in assembly language but instead wanted to use LFSR (careful, they're mathy!!) to parallelize a scan and make it "FAST AS SHIT". I think I was getting confused with Steve Gibson's, another "security" blowhard, NanoProbe project.[1]

[1] <https://www.grc.com/np/np.htm>

<comment><USER13> Hey, Steve Gibson is a good guy. His long-running show is by far the most worthwhile on the fluff-based TWiT network.

<comment><USER14> The last time I saw a Steve Gibson discussion here, I bookmarked a few good links.

<http://attrition.org/errata/charlatan/steve_gibson/> <http://radsoft.net/news/roundups/grc/> [http://allthatiswrong.wordpress.com/2009/10/11/steve- gibson-...](http://allthatiswrong.wordpress.com/2009/10/11/steve-gibson-is-a- fraud/)

<comment> mkr-hn I stopped reading what he had to say after his campaign against raw sockets in Windows.

</comment></comment></comment></comment><comment><USER15> I imagine it could be used to circumvent whatever forensic tools that some organizations use. For example, in the very recent case involving Yihao Ben Pu and Citadel:

'... Pu had also downloaded a "port scanner" program to his Citadel computer ...'

text of complaint: <http://www.scribd.com/doc/63606232/Citadel-vs-Yihao-Ben- Pu></comment>


Show HN: Amazon is littered with fake reviews, see through them – Freshdill.com - <AUTHOR> http://freshdill.com <comment><USER2> Seems like this is just low effort affiliate link spam. The actual "fake review" filtering is done by fakespot.com, and price tracking is done by thetracktor.com, so you are just adding an affiliate code?

<comment><AUTHOR> We are not trying to hide the fact that we're using fakespot review data (or tracktor pricing data for that matter). We are providing the ability to search for products rather than cutting and pasting URLs between browser tabs into multiple different websites. We are trying to provide a more cohesive user experience than we have found elsewhere.

</comment></comment><comment><USER3> Have you considered making it a browser extension? It would be good to maintain the amazon interface I'm used to.

On another note I heard from folks who have tried starting companies like this that it's hard to change habits (hard to get people to stop going to amazon and start going to your site, even if you add a bunch of extra useful info).

<comment><AUTHOR> I initially looked into making a browser extension but my reading of the Amazon Product Search API led me to believe it would be a violation of their terms of use. I have seen some similar extensions using their API since then which has made me reconsider.

<comment><USER3> Another possibility: if you scrape the data from the page directly, amazon would never know.

</comment></comment></comment><comment><AUTHOR> The review quality on Amazon has gone down significantly over the last few years, especially in the electronics category. I needed a way to search for products that allowed me to quickly identify real vs fake products. I couldn't find anyone providing this search service so I built it myself. Any and all Feedback would be appreciated.

</comment><comment><USER4> So does the check mark next to the item mean it is legit and the others have fake reviews or the opposite?

<comment><AUTHOR> The check mark means that the price is the lowest in the last 90 days and the reviews are reliable. Good question, I should make that more clear.</comment></comment>


Ask HN: Assuming there's a bubble, how do we mitigate its damages? - <AUTHOR>

<comment><USER2> Assuming you mean personally and career wise and not as an industry.

What you will see is that the people that moved into Tech because of "easy" money will move on and will have a hard time finding work they likely weren't qualified for to begin with. Those with experience and a solid base of skills won't notice much of an issue. Yes, it will take a little longer to find a position if you want to move around, capital won't be as freely available, but if you are good at what you do work will be available.

So personally, make sure your skills are solid, stay up to date and network with friends and others. Make sure some people you network with are in enterprise level companies so that if the time comes you can use those contacts to help you move to a more enterprise role (assuming you are not in one now). When the dot com bubble burst that is exactly what I and some friends did and we barely noticed anything, hell a couple got raises. I also eventually started a consultancy during the downturn and we did awesome during that time because companies didn't want to hire FTE's and were happy to use us instead. Also, it was nice to see the greedy money seekers without skills get booted by the market. It pained me to see non tech people getting development jobs and being paid as if they were qualified developers when they weren't. Mind you, there were some that rocked and deserved every penny, but they also never had to worry about work either. And I never cared if they were paid commensurate with their level of experience, but it torqued me seeing a new grad with a non-tech degree and no experience getting paid $60-70k/year when I knew very qualified devs getting that or just a bit more.

Also, something I personally believe, for each successive year that passes software becomes further ingrained into everything in our lives Engineers become a necessity to keep around. It used to be companies could downsize R&D and cut support Engineers to the bone to save costs. They can't really do that anymore without risking significant revenue. Not to say Software Engineers are without fail or always safe, but as software continues to eat the world it becomes harder to dispose of us without consequences. There is a side affect to this too, it can lead to Engineers becoming a commodity that is easily found and traded, but at this point I don't think that is really valid nor will it be for a significant time.

</comment><comment><USER3> If you're asking from a personal standpoint: I would imagine that you'd want to reduce your debt, cut your expenses and increase your personal liquidity.</comment>


Spy Agency Consensus Grows That Russia Hacked D.N.C - <AUTHOR> http://mobile.nytimes.com/2016/07/27/us/politics/spy-agency-consensus-grows-that-russia-hacked-dnc.html <comment><USER2> Why are all the DNC hack related threads on HN being censored?

edit: threads, not threats

<comment><USER3> The discussion of this post is at [https://news.ycombinator.com/item?id=12169891](https://news.ycombinator.com/item?id=12169891)

<comment><USER2> Thanks. Everything appears to be being removed from the front page of HN though</comment></comment></comment>