Alan Cooper on the “10x” Programmer | Hacker News Reader

Alan Cooper on the “10x” Programmer

twitter.com

114 pointsjamessun65 comments

All I can say is, it’s been my subjective experience that competence and productivity are really variable. Some people at my company can produce beautiful, working, end to end solutions for complex problems in the time it takes others to grind out trivial maintenance tickets. Everyone knows who they are. Programmers are not basically all the same, and it’s worth thinking about the nature of the differences if you want to become one of those people, hire them, retain them, grow your team to be more like them, etc. To write them all off as myths, children, assholes, etc. is to reject the possibility of substantially improving at our craft. That’s a dangerous thing to do.

Agreed. I've known some very productive, very stable, very nice engineers. I've met the erratic kind too, but they're definitely not all that way.

Agreed. I was formulating it as this (at a previous job, obviously)

There are 4 "top engineers." All 4 of these top engineers would identify each other as such.

There are 4 "D tier engineers." You'd rather have any ONE of the "top engineers" than ALL the "D tier" engineers.

These D-Tier engineers usually end up "managing" a rote manual process (e.g. calling a script sending emails in batches manually), when any "top tier" engineer would have written an automatic scripted solution that runs periodically, batches on an intelligent interval, logs its output, and automatically alarms if its results are anomalous (and done so in a week and moved on to a new project).

10x programmers can hit a target no one else can see. This is true for 10x persons of all types in all endeavours, not just programmers. In this mode they are more artists than technicians. Compelled by vision from an overflowing sacred gift outpacing its faithful servant. Conventions and norms are not designed for this. Those who push beyond the bounds by definition cannot be bound by them. If you want to maximize their productivity, provide them with supporting infrastructure and surround them with brilliant editors to optimize this process and integrate their vision.

One interesting twist is that some problems are completely intractable for most programmers. I mean that they cannot produce a working solution no matter how much time or effort they use, or if they do it's so riddled with bugs it's practically useless.

Thus it follows that for certain tasks there are "∞x" programmers. Therefore there are absolutely "10x" programmers as well, which fits in with my subjective experience.

Certainly domain knowledge can play a very big role, but there are also rare individuals that seem to be much more productive no matter the task.

It's certainly task-dependent at least to some extent. If the task at hand is to fix a zillion spelling errors in the UI, there is certainly no 10x variance in programmer's ability (there might be a big variance in motivation though, and individual performance is a product of motivation and ability).

I mean that they cannot produce a working solution no matter how much time or effort they use

Of course, but they don't represent the middle of the distribution. When people speak of the myth of the "10x programmer", that claim is meaningless if they can hold the reference productivity all the way to the far left of the distribution.

Any meaningful claim of "10x programmers" needs to be measured against the mean or median of the distribution - the so-called "average programmer". How many non-dysfunctional "10x programmers" who don't create messes for others genuinely exist?

>but they don't represent the middle of the distribution

Really? I don't think most middle-of-the-road engineers, given certain requirements, could come up with a working solution in any reasonable amount of time. For example if you just told an engineer "Implement a basic server that can execute queries based on this language spec, where you upload tables as immutable tab-separated text files" I'd guess only the top 5% of engineers could get something working in less than a month.

I don't think that executing tasks like this is something that innately only some small x% of engineers can do. For example, almost all engineers will lack at least some of the skills needed to complete any sufficiently large task: best practices for translating a query to a query plan, how to do efficient Ser-De, what data structures to use to implement the data, etc.

But most engineers lack the meta-skills or traits needed to complete the task. For example, would they first look at how basic SQL implementations and toy projects work? Look up some of the theory of RDBMS? Would they know how to write good tests, good class structures that don't require refactoring in 2 weeks as they understand more portions of the problem. Would they try to roll their own query parser or use a standardized tool like antlr?

As an experienced programmer - if you really want to improve productivity 10 times, find the junior programmers in your team, empower them, give your advice when asked, shut up when not being asked, tell them they can do that hard task and help them out when they have problems. Be a decent human being. Then watch with pride as they grow in amazingly quick time. Oh - and just work for a company, that honors when you're doing that.

Nowadays programming is teamwork.

I'd argue that programming, like any other human endeavor, has always been teamwork.

In a sense, every programmer is a member of a global, mostly remote, asynchronous team of every person who contributed to the hardware, software, documentation, and theoretical foundations upon which the programmer depends.

Here are some indicators I've seen from 10x and 100x:

The 10x person fits very well in their organization. They are admired by upper-management for their ability to quickly comprehend, estimate, and deliver solutions to problems. They mentor everyone that asks or needs help. They provide 95% test coverage on all code. They show up for work well dressed, clean-cut, and on-time every day. Their code isn't 'brilliant' because they understand it must be maintained by the whole team. Their code reads well across difference experience levels but also includes clever tricks. They have an absolutely rock-solid understanding of the operating environment, platform, and modules. They don't document their code. They are the smartest person you know.

The 100x person seems to fit very well into the organization at first, and appears to be a 10x. They take on several seemingly-impossible tasks up front and eat it for breakfast. They automate large portions of the business and their own processes. They provide 99% test coverage on all code. They create production-quality docs after their public interface solidifies. They know security and implement it correctly. They spend months to years on self-driven projects to master different categories and build their tech-tree. They have invented tech and patented it. They bump into the intentional barriers of the organization. They break through and create a billion-dollar product, or they are removed from the organization. They are the smartest person you know and without explanation they appear to be insane.

It really seems 10x is a stigmatized term. It used to mean a developer that could produce 10x lines of code, but at this point I've taken it to mean a single developer that can leverage technology, their department, and organization to manifest a 10x positive impact compared to someone just cashing their check delivering story points. I don't think this term really fits for someone on the spectrum wreaking havoc in their organization.

in my experience, 80% coverage is about the correct number, but then those same lines of code are being covered over and over again for each major business use case.

Bumping the test coverage up past 90% definitely has lines re-run multiple times, with core logic even being re-executed possibly hundreds of times. This is absolutely ok! Your main purpose of writing tests is to make sure when you change business logic that a test will point you to the exact spot. If you commented out any single line of business logic; a test should fail.

I understand that this may seem crazy if you are used to 80% coverage, however there are subtle ways to build your unit/integration/feature/security/performance tests where you only pin your public api, and code changes to the internals don't break the tests, and the test suites only have minimal (necessary) overlap. This is test engineering and it takes about a decade of TDD to be comfortable with.

I would have said 100% test coverage for 100x but that last 1% isn't worth it. Some things just can't be tested without altering the public interface of your code JUST to accommodate the test, or they require some crazy significant re-work of the code that makes it hard to follow, or you have a module with a crazy way of interfacing with it that makes testing a specific part extremely difficult, or it's code that doesn't really need a test (like a log statement).

Side note: 99% test coverage isn't typical but is absolutely necessary if you have automatic patch-management solutions in place and are striving towards zero-defect code. How comfortable would you be pushing to production after bumping the major version of your platform and seeing your test suite pass? Having 99% confidence in this situation is a good thing and saves you time in the long run.

I begin to relax around 85%.

It’s perfectly possible for a project to hit 85% without much untoward going on. Running the code and testing the code are not the same, and as the numbers go up I tend to find shenanigans.

I’d rather have an honest 85% than any dishonest number you could want. My butt starts to pucker again above 95%, because it’s all lies.

There also comes a point where running certain tests by hand is faster or more reliable than having a test for it. False positives (failing tests) are expensive, and in a way that is often counted poorly.

For a start, a false positive doesn’t cost the time of the test, it costs the time of the entire test suite times three - the one you wasted, the one you do over, and time between getting a failure and noticing the failure.

It also costs trust in the tools. Red tests become untrusted, which really hurts when you have a test that has false negatives. People become conditioned to hit the run button again without understanding the error, which then blows up farther down the line, possibly in production.

> My butt starts to pucker again above 95%, because it’s all lies.

With the way you are describing false-positives; it sounds like most of your tests are written as integration or feature specs. Exercising the UI at 95% coverage is insane (maybe that is why you said it's all lies). You will definitely be pulling your hair out with false-positives and with a large enough project you'll never get it 100% passing each day.

The answer here is to shift your tests from the UI or integration level down to unit tests. You should test at the function or model level with unit tests to pin all possible execution paths, then perform a sanity check test in the UI. For example; exhaustively test your login module at the unit level, then perform a sanity check at the UI level. Moving exhaustive tests down to the function or unit level increases test speed because you don't have to load or render the UI to perform the tests (which also eliminates most classes of false-positive tests).

If you or your team have issues with false-positives at the unit level then something isn't right with your test harness, OR you need to git-blame to identify the person on your team that needs some mentoring.

Testing is hard. Most of the people who tell you otherwise are full of... bravado. Sometimes they have the worst tests.

When I started working with more dynamic languages I took comfort in the promises from TDD folks that you can write tests to cover all of these things, but I've seen how tests are written in practice and it's not good. I've met maybe ten people in twenty years who are really competent at writing bulletproof tests (as in, "You wrote tests for that? Enough said" versus Trust but Verify) and I am not at the top of that list. Frequently enough, I find eyerollers that have my name by them in the commit history.

I'm not saying I'm ready to go back to static languages because of this, but I will say that I see evidence for hope on the static analysis side for once in a very long time.

As you say, the problem is often discerning between unit tests and functional tests. Some people clearly can't tell the difference, but a number of people have confessed discomfort at writing unit tests (something about my frank communication style seems to invite people to share their fears with me, and I hear things that the "everything is great" people don't due to self-censorship). That these unit tests seem juvenile, pedestrian. Remedial. But to my mind that's the point. The cognitive load of determining why I just caused a bunch of tests to go red should be near zero, since I'm still trying to keep my head wrapped around the new code I'm in the midst of writing.

For about as long as I've been writing tests I've worked with people who think writing their own mocks or helper functions in tests is a good use of time. They take some work, so once you have them working they write five more tests that use them. The poor SOB who gets a red test six months from now has no idea what's going on.

Worse, adding more to these mocks may cause some of the tests to be evergreen, and others to be required (deleting test 1 makes test 3 fail). Which is only discovered when a customer complains about bugs and you say, "wait, don't we have tests for this?" The tests are coupled which is bad juju. Every test should be capable of being run in isolation (debugging your tests!)

Often the first thing I do is rip this mess out and winnow the mocks down to the one, two, or three calls that actually need, so each test can be taken at face value. I also replace a lot of ten line tests with more four line, transitive tests (if A->B and B->C, then A->C.) Then I remove any coupling between the input and output that wasn't fixed by doing that (once a month almost, I find a test whose assertion boils down to expect(a).toEqual(a)). And the utility functions get split up into matchers with much more diagnostic data added in, and a bunch of incidentals taken out.

Effectively what we are doing versus languages where writing the code up front requires more thought, is that we are marking stories as done that aren't properly done for weeks, months, or years. It's a bit of knowledge that makes me uncomfortable. I have a lot easier time hiding that discomfort with people whose position in the org chart implies that they are still learning, and quite a time being constructive to the braggadocios. It's a lot of emotional labor and it's taxing.

There will always be outliers but it really depends what thing the 10x programmer is making ten times more of. If it's simply lines of code then it can strongly be argued that he's creating 10x more technical debt as well, as one of the stories suggests. I've read that many outlier programmers are on the moderate-to-advanced portion of the autistic scale, at a place where it's actually a superpower in terms of being able to concentrate and write massive amounts of code and usually very good quality. The biggest problem with devs like that is that their colleages/teammates have a hard time keeping up with them and management usually tries to coerce others to try to catch up and not treat them like the benevolent freak they are. Even if there's no conflict with a high quality 10x performer there's also the future case problem of trying to figure out how to fill the shoes of such a dev if/when they leave. Management will never authorize hiring 10 people to replace that person, and unless the person was writing perfect code your maintenance is usually a lot more than your staff can handle as well. Are there other fields/jobs where someone can consistently produce 10x more than others simply on their own ability?

I agree with this, for anyone to be a 10x developer, most likely their brain has massive deficiencies in other areas of functioning. I've only worked with one 10x developer in my life. After seeing his code and problem solving abilities, I started to question whether I was any good at coding at all (and I am regularly regarded as the best on my team).

Finance is another industry that supports 10x employees, its common for traders with a natural ability at pattern recognition to produce 10x - 100x returns. Like technology, their minds can be leveraged by increasing the amount of capital they can manage.

The spectrum guys are good for deep dives and best operating practice based implementation, not so much on branching code and creativity.

> Are there other fields/jobs where someone can consistently produce 10x more than others simply on their own ability?

Sales. Some people can make it rain and generally nobody begrudges paying them well to do so.

Fiction or non-fiction writing. The difference between Terry Brooks and the average wannabe fantasy author is enormous and the difference between him and JRR Tolkien is greater again.

Mathematics. Terence Tao is as far ahead of the average Math professor as they are of the average high school Math teacher.

Law. If you give the average lawyer twenty times as much time and all the research resources of a partner at Skadden Arps the Skadden guy will still come out on top.

Finance. Whether you’re talking VC, PE or Hedge Funds the people at the top are a lot more than ten times as good as the average, never mind the marginal member of their reference class.

All of academia as far as research is concerned. Research impact as measured by citations is a power law. People at top departments routinely get hundreds of times the citations of those at no name ones.

In any human endeavour that isn’t limited by severe bottlenecks in material input you get people who can do much more with much less than others can, and who are capable of doing things that those less skilled simply can’t do.

Add carpentry or vehicle technician to that list. All jobs where you have some sort of choice on how and what to do and motoric aptitude leads to high variance in skills.

The big difference is maybe that bad vehicle technicians are singled out by the boss or customers and quit? While neither the boss or customer can pinpoint a single programmer.

I think this boils down to literally any arbitrary skill based activity. Unless the output is heavily dependent on RNG, there will always be someone who is orders of magnitude better than the average person.

One other thing, software has the benefit that product development occurs in a simulation.

There's a freedom that comes with that, we're unbound by physics - layer upon layer of abstraction make it a lost concern.

It feeds into itself, growing in power at a rate proportional to its surface.

Until that is, it collapses under its own weight. When that happens is a matter of structure, and the extent to which the developer understands what the structure is, where it should be and how it must expand to cater for new requirements.

For simple cases a single largely linear block of code will be fine.

Eventually things get more complex. You'll need to move the lower level functionality to another file and call through to its methods.

Some of the methods in these files will become so heavily parameterised - and with repeat parameters - that you might want to introduce state. Welcome to OOP.

Then with the proliferation of the files you've created you'll need to introduce a directory structure.

Then a module structure.

Then a separation of API and implementations.

Then a division across projects.

At any of these points some will falter.

Some can't even write a single class without copying a pasting massive blocks of code. Some write class after class without consideration of abstraction or structure.

Yes there are 10x developers - those who understand structure and can implement the code accordingly.

Why does this happen in software and not other industries? As I said, we're unbound by reality.

If the best of us were engineers, we would be more tightly constrained by the physical limitations of the world.

If the worst of us were engineers, they would get people killed.

You've described how I feel about this in such a succinct yet expressive way. I find it hard to communicate to ${NON_PROGRAMMERS} the difference between highly skilled software folks, average skilled, and the huge bulk of copy+paste wannabe's.

Definitely, but only because some developers are insanely incompetent.

Sometimes they'll spend days going around in circles, creating files and writing hundreds of lines and introducing a couple of dependencies. When it comes to review time it's like... Wtf are you doing? It's a 5 second one word fix?

It's not 10x code, it's 10x faster to deliver value and solve problems

Being a 10x programmer or whatever isn't all it's cracked up to be. It's not like they let you work 1/10x, or even 1/2x. You're expected to deliver that 10x 50 weeks a year, it's impossible to not get burned out. The "velocity tracking" craze is killer. A very strong developer and regular in #python on IRC was working as a janitor for a while. I didn't get it then, now I totally get it. It's hard to muster the motivation to continue working in software.

>The 10x programmer is essentially a libertarian concept: That is, they do it all by themselves because they don’t recognize how much is done for them by others.

I'm finding myself meeting a lot of "10x" descriptors. I'm not doing 10x the work but I'm definitely doing the work of the next two highest performing colleagues put together.

I also see myself putting burdens on my team. My communication, teamwork, and managerial skills are poor and always will be. Yet I always seem to do things technically that makes people look at me like I discovered fire. For me to say I didn't outperform my colleagues would be effectively to say I had no value as an employee since there would be nothing to compensate for my shortcomings. There have been meetings about me where everybody except me was in the room and I was talked about and the only reasons the team decided not to fire me was my performance and work ethic.

It makes me feel really bad reading all the response to high performers that aren't well rounded like they are inherently arrogant toxic drags on a team. There's nothing wrong with having an employee with a lopsided skillset in a team that can support somebody like that. I think seeing such employees as inherently toxic, or seeing them as a holy grail. They're like artillery; only effective with support.

> My communication, teamwork, and managerial skills are poor and always will be.

Could you elaborate on how they're poor? And why you think it won't/can't change? You seem to have expressed yourself very clearly in this post, so at least when it comes to communication, I can't deduce any shortcomings (from this post).

Autism. So text based communication isn't impaired. Also led me to spend a lot of time on the computer so I naturally got better at using them. I send a lot of emails at work and my co-workers will usually try and deal with walkups. Writing is a strong point for me.

There's little problems with communication like having the emotional intelligence to tell when your co-workers are having a hard time and when to back off and treat them differently. I lack that which puts extra stress on them. I tend to say too much and make my team lose face and cause us political problems. So I try to compensate by doing such a good job my co-workers won't be under as much pressure to work hard and my team will be doing such a good job we won't get in shit.

Just know your limitations. I worked with a guy, somewhere on the spectrum.

He was very good at some things, but understanding other people's perspectives wasn't one of them.

He was excellent from a broad architectural perspective, but failed to acknowledge his limitations in regard to API development and user facing content.

There will always be a difficulty in understanding why it is that certain concepts are beyond our grasp, but it might not stop us from understanding that they are.

Thanks for sharing this. It's fascinating to read the article and then have such a blatant counter-view/argument/description in the comments. I've really started to like HN mostly for the comments these days.

Some totally unsolicited advice, but have you considered writing a user manual for yourself and making it available to your management and team members? This a concept a friend/colleague of mine turned me onto and it's been a huge help for everyone involved.

It's basically just a couple of pages with brief descriptions of her communication and work styles, philosophy and approach to conflict and and communication, a list of some modes of interaction which are the most effective/productive when engaging her, and some of her blind spots which may not be apparent.

Aside from equipping coworkers with tools to interact and work with you better, it also gives them permission to engage with you in ways that, while highly effective for you, may be considered rude or socially awkward with other people.

A personal example: I've got an almost non-existent sense of smell, which means that if it's been a particularly hot day or I've been exerting myself I can occasionally get a little ripe smelling without being able to sense it. I am incredibly grateful when someone lets me know if that's the case, but I have to give them that context and permission before they're willing to say "dude yer getting smelly". Generally people wouldn't make that kind of statement for fear of being rude, but once they know that I react well to (and actively solicit) that kind of non-standard interaction it makes everyones lives easier (and significantly less stanky)

I feel like we probably spend too much time playing around with the idea of 10x engineers. It's definitely true there are more effective engineers and less effective engineers, but I really find it funny that there's always a focus on the 10x engineer. Partly because it's impossible ot judge a 10x engineer truly, and partly because it almost always is accompanied by a story about how the 10x engineer only works on one specific type of problem, almost never in a way that adds value to a customer. What you really often have is a 0.95x engineering team - where one engineer has the 10x reputation and the team as a whole is performing 0.95x. Meanwhile the 3x team contains a number of '10x' engineers operating at 4x and making sure everyone else is the team is around the same level as them.

What I hope we can all agree on is that in every day life we're a long way past the point where a single engineer is going to make or break your company by being 10x. It's far more important to be making sure that a team of 10 is working at 3x or a team of 100 is working at 1.2x.

I think the focus is just pure jealousy just the same way people are jealous of those who are 10x income earners.

There are 10x engineers out there who not only product great work, but solid work that doesn't need support, they test, they document. They might not be a pleasure to work with for most because their thinking level is completely different and they don't subscribe to modern software rituals. They focus on what it takes to get it done.

I can't agree that we are way past the point where a single engineer can't make or break the company being a 10x. Sure for most enterprises, but startups and small companies those are still valuable if they can get one.

I remember once being asked during a phone-screen how many lines of code I had written. Ever. Some of those things were on classified systems years ago, there is no way I'm going to remember that or even be able to look that up any more. Why would I ever log "wrote a net-worth of xyz lines of code today" for a personal record? I've never worked for anybody who had that as a metric but apparently I had a chance to now; I gave them an estimate and moved on.

The kicker was that the question had absolutely nothing to do with the job. Nothing.

It was probably just a question testing your ability to estimate. Of the “how many manholes are in Seattle” ilk.

https://www.youtube.com/watch?v=sxhKMuDJ_E8

It's a question to ask to weed out people who say "I'm a programmer" but a tually haven't written much code.

10x discussion aside, I found this quote to be eye opening, and not just about programmers:

“The 10x programmer is essentially a libertarian concept: That is, they do it all by themselves because they don’t recognize how much is done for them by others.”

I think the people looking hard for 10x engineers are poor team builders. The thing is a team of two good engineers can be a much more potent combination than one 10x arrogant prick who cant communicate or work in a team. Good engineers are still rare but they more frequently found than 10x engineers.

Did Gerald Weinberg speak of 10x programmers? I don't think I have a copy of The Psychology of Computer Programming, but that doesn't really sound like his later work.

After working with ~ 30 odd programmers, I would probably classify myself as a 10x. I think a good chunk of HN'ers are 10x, with imposter syndrome of course.

1. Patience - I have the patience to sit through and fix a bug. Googling it, reading the source ... this is fun for me. 1x programmers give up very often and very soon. They either blame others, feel pity for themselves for not figuring it out or hate the computer for giving the wrong answer.

2. Fuck OOP - I stick to the separation between data and code. If I am forced to use OOP, I abuse the command pattern. My code is procedural for the most part. Procedural code is easier to debug .. usually, when I see a bug, I know the exact function. 1x go "wow" at this, whereas I feel like an Imposter.

3. Tools - This would probably be my biggest sin and probably where I could be a bit of a hipster. I stick to tools and libraries that make me productive.

4. News - I try to keep up with the latest news. This often helps me leverage the next best thing for increased productivity.

5. Egoless - I don't care about rewriting, throwing away and deleting code ... trying a new library. 1x programmers get attached to their babies.

6. My code is not a mess, your ideology is a mess - I've found it easier to work with absolute beginners, 0x, than "experienced" programmers who like to throw jargon around. Beginners tend to find my code easy to follow, easy to fix, easy to debug. The first instinct of the "experienced" is to rewrite it because it's not "clean" enough for them. I'd rather you look at the forest than the tree. The whole thing delivers 80% of what business users want! I've had three projects where I did in two weeks what a group 10 programmers took months and that's sad.

Things where I can imporve

1. Testing - I usually do a lot of integration testing for the critical paths.

2. Security - I always tell people to hire pen-testers but no one ever listens!

3. Documentation - My biggest weak point of all. In my defense, I choose functions names reasonably stupidly. I think it's good move to hire great documentation writers.

4. Complex Algorithms and Maths - Always good to know more! This is where I have to rely on 100x programmers to come up with a good library. I aspire to be 100x.

I'm definitely a 10x programmer, but unfortunately 90% of my time is spent on hackernews, so nothing is gained.

That means you're not a 10x programmer.

Poe's law strikes again?

Guess so

Sure i am, i just keep the 9x for myself :-P

Whats your shtick?

* avoiding object-oriented programming

* avoiding testing

* avoiding security

* avoiding documentation

* fixating on known platforms

* a highly inflated ego

* demeaning other programmers

* arguing with experienced programmers during code review

* using the word 'maths' (the plural form of math is mathematics)

None of this classifies you as a 10x programmer and your comment has 'arrogant' written all over it. You have expert syndrome.

Maths is the proper term in British English.

Thanks, I was also wrong because there is no such thing as expert syndrome - it's called the Dunning-Kruger effect. This doesn't change my belief that all of foobar_'s coworkers hate him/her.

Classic projection. You probably suffer from it. I spell out my weaknesses clearly.

And Object Astronauts suck.

Not quite sure what I'm projecting here... Your statement "I would probably classify myself as a 10x" is very misguided, and your response here is a poor attempt at manipulation. I only spoke up because I saw others agreeing with you about being a 10x under your definition; which is more aligned with a programming intern's view of the world.

Here's my opinion on what I have seen in the workforce for 10x and 100x engineers: https://news.ycombinator.com/item?id=20441541

I think you'll connect with my last statement in that comment.

the correct term is architecture astronauts, but we get your point.

Yeah, didn't tackle that one...

I highlighted the fact that ignoring OOP is a weakness for @foobar_ and their response was essentially "you force every problem into objects and you suck". Interacting with this person is like carrying an open bag of snakes.

This is one of the most profoundly sad--as in, generates genuine pathos--posts I've ever read on the internet. Planting "egoless" square next to "your ideology is a mess" and clearly flagging that you'd rather have the chance to bully beginners than come to an accord with fellow professionals who might not lick your boots the second you walk through the door. While assuming--with no grounds, but you already know that--that somehow those poor benighted "1x programmers" don't have the patience to understand and fix bugs.

This attitude is gross and demeans you and those around you. Worse, even by the standards you spout off about: in my experience it is also and without exception the attitude of someone who is not a "10x programmer" but somewhere in the negatives, causing needless and constant churn for the sake of looking smart.

I truly hope, a few years down the line, you have cause to remember that post with regret because you've grown out of that phase of your development as a professional and as an empathic person.

amen

Reply on news.ycombinator.com