Alan Cooper on the “10x” Programmer(twitter.com) |
Alan Cooper on the “10x” Programmer(twitter.com) |
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).
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.
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?
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?
Nowadays programming is teamwork.
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.
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
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.
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).
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.
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.
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.
The kicker was that the question had absolutely nothing to do with the job. Nothing.
“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.”
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 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.
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.
Sales. Some people can make it rain and generally nobody begrudges paying them well to do so.
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.
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.
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.
* 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.
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.
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)
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.
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.
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.
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.
And Object Astronauts suck.
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.
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.