There's some fantastic stuff in here about how great design is the key to increased productivity. For example:
"It is very important for a designer to recognize all the parts of a design that are not easy wins, that is, there is no proportionality between the effort and the advantages. A project that is executed in order to maximize the output, is going to focus exactly on the aspects that matter and that can be implemented in a reasonable amount of time. For example when designing Disque, a message broker, at some point I realized that by providing just best-effort ordering for the messages, all the other aspects of the project could be substantially improved: availability, query language and clients interaction, simplicity and performances."
redis itself is a masterpiece of pragmatic design - the feature set is brilliantly selected to make the most of what you can do with shared data structures exposed over a network. Let's talk about that.
I remember a very specific example of this from Perl 6 development circa 2009. perlgeek (I think) and I had been struggling with coding up the sequence operator for a couple of months. Every time we thought we had it, someone would come up with a case that broke the system again.
pmichaud (not sure if it's the same pmichaud here on HN) comes up to us and says something like, "Guys, you're not getting this, let me do it." And I was kind of offended, because it wasn't like perlgeek and I were chopped liver; why did he think he could easily solve a problem that had been plaguing us?
But here's what pmichaud did. He went up to TimToady (Larry Wall) and said, "There's too much magic in the sequence operator. We need to simplify it." I don't know which combination of the two of them came up with the details, but less than 24 hours later the spec had been changed so that there was no magic on the right hand side of the operator and they had a working implementation. Any sequence possible before was still possible, but the user was required to be more specific about what they wanted. After the change the median sequence took maybe two more characters to specify ... but suddenly 90% of the hard part of coding the operator was gone.
Alexander the Great did the same thing in order to solve the Gordian Knot[1], he changed the spec by removing the complexity (in one stroke).
I was not in a position to even think about proposing the removal of any spot that had to be guarded at all times. Doing so, might have resulted in someone (including myself) doing double-shifts for a few days. Only he who has the power can do it (e.g. Larry Wall for Perl, Alexander the Great for the Gordian Knot and the sergeant for the military camp).
Not doing something, or doing something dramatically simpler, ends up with less code being written. The cost of writing the code is usually a small fraction of the cost of supporting it during over the life span of the system.
One problem I faced was a client that as part of an e-commerce re-implementation brought a huge list of requirements for promotions and how they should work. There was hundreds of use-cases, some being very complicated.
I came back to the client and said, "are you sure you need all of this?" After working with them to investigate, it turned out that they had just documented all the features of their existing system. In the previous ten years, they had created exactly one coupon, and that was for a flat 10% off.
That was the functionality we initially went live with.
In the end, you provide value or you don't. The hardest thing about any product development is to stop taking things out or worse yet, keep adding things in. The top performers are usually the ones who can weigh these pros and cons almost immediately and force the product in a better direction.
Given how many times the 90/10 principle will brutally murder your time estimates ("we're 90% done, so there's only 90% left to go!"), learning to also harness it in your favor as antirez talks about is a great programmer differentiator. If 90% of the effort is coming from 10% of the design, and you can find some way to cut that part of the design in half, you just cut 45% of your effort out. My numbers are made up, but the principle holds. Most of the time you don't get that lucky, but every once in a while it is possible to do even better; I have, on occasion, seen entire seemingly-massive multi-month projects dissolve into 200 lines of code in the right place, built on the right foundation.
We were discussing this in a meeting with the C-level execs and other top employees, and they were working out a plan for bulk manufacture of CDs containing the textbook content. Many of the textbooks already had CDs that came with them when you bought the physical book, but most of them did not, and we'd need to manufacture copies in either case. There was liner material to produce, CDs and cases to buy, global distribution to manage, and a new department and headcount needed to manage all of this.
I interjected with an idea. I was building the online display of this content, and had already built everything needed for converting the xml into a table of contents display and per-chapter displays, all in html with the styling that we wanted, including features like the substantial amount of cross-linking between sections, chapters, figures, indexes, appendices, etc. So I told them "You know, as part of the production process where I'm converting all of this xml for online display, I can also produce a set of static files that would work well for an offline display, either sitting in a folder or on a CD. We can do that, create an iso image from it, and let the customers download the iso and burn their own CD if they want physical possession. It'd be exactly the same content, and would only lack the online searching and dynamic excerpting features that the website has which depend on our search engine."
They were stunned. They discussed, and decided that for most of the customers this would be just fine, and for the handful of exceptions we could burn the CD for them and mail it. We included a cover-art image from the book on the CD if they wanted a liner, and our download links had a little help icon that pointed to documentation we wrote for a few free CD burning utilities. Overall cost was a few extra days of development time.
I pored through the specs, talked to everyone who would use this, and realized all the queries could be calculated from a much smaller, summarized version of the data.
I wrote a script that would create an Excel PivotTable every month and send it to everyone who asked, solving the problem in a few weeks with a <500 lines of code. The execs decided it would not be worth spending an extra two years to get the exact same answers in a web UI.
Good times.
Knows how to handle not knowing or getting stuck - some people have a melt down or won't ask for help when they hit a wall or don't know when to push back (we had a vendor that gave us buggy code but kept claiming it wasn't until we pushed back through our management and forced them to let us see the code).
Can visualise the program - how much of a program someone can hold in their head is the only thing I've really seen make a programmer exceptional. It is rare and I've only met a couple of people that can hold a medium sized program in their head, the whole thing this ability lets them basically just vomit it all out into the editor without having to switch between functional and structural context and really does make for a big productivity bonus (maybe as much as 4x).
Of course I am completely biased in that I can bold barely anything of a program in my head. I feel like that makes me a better programmer in terms of writing shorter, maintainable code. It's hard to assess yourself honestly though.
http://www.insearchofstupidity.com/
The author calls them "marketing disasters" but I recognized several purely technical disastrous decisions there, like "let's rewrite the product from scratch, but ignore the way the users use the product (to print) and ignore the printer drivers existing in the earlier version." Then wonder why nobody wants to use the new version, and the competition takes over. These things are eternal in tech.
On another side, if we claim that as soon somebody is making any design decisions is not "just a programmer" then sure, all the programmers are "good enough."
The way I understand it, antirez probably considers himself a programmer and for what he produced he really made most of the design decisions himself?
But if you factor in the design decisions: they can make the product great or kill it. What's the difference then between the best and the worst? Much more than 10 times, if we compare the survival vs. the death, it's even infinite.
It's interesting that this anecdote is from Apple, as Steve Jobs was a famous proponent of the 10x or 20x programmer and hiring only the best available. In contrast at Microsoft Charles Simonyi took completely the opposite approach, with a highly stratified organizational structure dependent on hiring large numbers of drone programmers[1] and reducing programming tasks down to easily implementable essentially rote modules.
I don't think it's a matter of one model or the other 'winning' though as the Simonyi strategy certainly seemed to work for MS.
[0] http://www.folklore.org/StoryView.py?story=Negative_2000_Lin...
[1] https://en.wikipedia.org/wiki/Charles_Simonyi#Denmark_and_US...
You've really got to have people who have a culture of celebrating trimming the fat at both ends to get to that.
can provide daily anectodes but here's the last one: we use a javascript scrolling library, for reasons etc, long story short a programmer spent a couple day trying to figure out why the horizontal bar wronly showed on edge, until I went in and dropped a display none on the bar itself.
ultimately we aren't paid for technical excellence but for working programs.
If that is something that has to be done a couple of times in a projects whole life, fine. If that is how bugs are solved all the time or frequently, I can only imagine how bad the codebase will be to maintain in years, and how depressing a job it must be to work on it.
That line of thought bleeds that no-one cares about the project, and only cares that the "people paying for it" hopefully don't notice the state of affairs underneath, and that they are not in a position to switch away from the product when ultimately it burns, which it will, if that is how bugs are treated. It bleeds that money is the only incentive, not heart, not passion, and that's just sad. It's why so much software is so bad and ends up costing much more in the long run than fixing the damn bugs properly right now, either because you end up having to maintain it until death, because it's so hard to maintain, or because you can't keep increasing customers after years because the product is now in such a bad state that time is spend fixing/hiding bugs instead of adding new features or improving existing ones.
> ultimately we aren't paid for technical excellence but for working programs.
That is true for most people and most projects, unfortunately. Bugs should not be covered and hidden away, they should be fixed.
Wouldn't an even simpler solution be to just use the scrolling built into browsers?
In my very un-expert opinion, there has to be a balance between technical excellence and working program.
I'm assuming that your case is really a non-issue. A dev wanted to find the root cause of the issue, fix the issue, and then never have to worry about it again. That's an admirable quality to me, but from your quick fix, it proved to be too much overhead for so little gain.
On the other hand, you can reach a point such that you peel back a Band-Aid brand adhesive bandage, you find a generic brand adhesive bandage atop a goopy dollop of ointment atop rotting wounds. I think technical excellence is knowing when a quick-fix for your situation is good enough and knowing when you really need to roll back the sleeves to dive in.
Depends who you are, now doesn't it? People writing core OS components, network infrastructure, cloud servides, etc have a much higher bar to hold to.
But I'm in agreement with antirez that good design and solid technical underpinnings often make projects go much faster. Even if you don't know it by heart, being able to research the tools you need can give better results than not knowing at all.
Some level of technical excellence is required, though, otherwise complex technical debt piles up, and we are then no longer able to deliver working programs.
In optimization, if you make an analogy between speedup / improvement with advantages / effort, you get Amdahl's Law:
https://en.wikipedia.org/wiki/Amdahl's_law
"[T]heoretical speedup of the execution of the whole task increases with the improvement of the resources of the system and that regardless of the magnitude of the improvement, the theoretical speedup is always limited by the part of the task that cannot benefit from the improvement."
Sorry, doesn't fit in a two week sprint.
Agreed - the actual content reads more like "The mythical 10x programmer ... is me". ("many people told me that they believe I’m a very fast programmer... I’ll also use myself as a reference of coding things fast").
I don't mean to disparage Redis or the author, but the point needs to be made that seniority makes it a lot easier to be a "10x" programmer. First off, you have excellent knowledge of business requirements and PMs will listen to you; so it's relatively easy to redefine engineering tasks as you work on them ("killing 5% to get 90%"). Second, you're much less likely to be interrupted by someone who's decided you're working on a low-priority project ("focus"). Third, you probably get to decide what "programmer productivity" even means.
And the headline was purposefully chosen to elicit that effect -- nothing engenders a massing crowd response quite like summoning the boogeyman of the 10x programmer, allowing everyone to flow forward with their anecdotes and personal grievances.
-10x for readability.
It's a design anti-pattern that makes the article difficult to read, even if you don't have a cognitive differences that make reading more challenging.
* For most of my past clients, the skill / output of their programmers was not the bottleneck, even though they thought so. As long as something is not a bottleneck, there's not point in trying too hard to optimize it (since you can get better ROI somewhere else).
* Software is a team effort. Improving how the team works together / how work flows through the system probably has a bigger impact than raw programmer output (unless you are already very good at that).
* Improving the quality of your software (minimizing defects and rework) will improve the output of everyone in the team, regardless of how good they are.
* I have heard of cases where removing the "top programmer" from a team made the whole team more productive, even though an important person was missing. I don't have data to back that up, though.
Update: Thinking more about this... I have a talk called "Your Company Will Never be Agile", where I talk about how most companies actively prevent their people from doing a good job (by having policies, procedures and a company structure that is not suitable for empowered teams). And then, those same companies complain that they cannot get good people and how all the hip companies can get the 10x programmers that "we cannot hire".
I don't have an English recording of the talk, but I started a series of blog posts about it: http://devteams.at/your_company_will_never_be_agile_intro . I should maybe finish it some day ;)
And programmer reading anything on his blog, or anything on HN for that matter, is not an average programmer anyway. The simple fact you are interested in your work singles you out.
Guys, you need to come out of your super power bubble and come to work down here. Where people uses PHP, SVN, and don't know what an environment variable is. Where they work for money, not for passion. Where Vi is scary and they pay the licence for Oracle even if their DB has one table.
This is the huge majority of the devs : plumbers.
I find it disrespectful when people don't realize this, because it means they live a life ignoring a vast majority of dev tool users.
Not only those people are numerous, but they create a lot of wealth because they are so many.
Don't assume:
- devs know the command line
- devs know how to setup a server
- devs know how to use a package manager
- devs know how to version control, unit tests...
And above all, if they don't know how to do that, don't assume they can't do their job. Because according to their employer they do. And they are paid for it.
They won't do a graceful reload, they won't compress their css and won't escape the user input. But the website will be online, serving customers.
This is why on my blog I have articles explaining what's javascript, what's RSS, how to setup the Windows PATH, etc. Because for important tutorials on Python, I can reference those, not assuming people know what I'm talking about.
Like how the Turing Test was rendered obsolete because online comments (e.g. Youtube) became so bad, the bar to writing a bot that passed as one of them was lowered dramatically.
Heck even the large recent trend among app developers and business analysts for low-code tools, tools that require mostly GUI and some code to get pretty complex applications going, offering maybe 5x-10x (or more) boost to productivity - that trend wasn't even mentioned at HN over the last few years, even though it seems like a really important trend, if you develop software or start businesses.
That just makes me wish there was a different type of community for entrepreneurs, one that is focused on democratizing creation and simplifying knowledge, in many fields - because those are the building blocks entrepreneurs work with.
Also, I don't get what I seemingly did not realize (mostly helping clients with legacy code on legacy platforms in legacy organizations to improve their quality and teamwork), or why this is disrespectful...
Every other engineering discipline has licensing requirements. People think software is special because the industry moves quickly, and indeed I agree that creating a formal, standard licensure body is extremely difficult, bordering on impossible, but think of it this way:
If, hypothetically, there was a proper licensure - how many people would be competent enough to earn it? We may think that there's a labor shortage now, but really, it pales in comparison to how bad things could be if all of a sudden everyone had to get licensed.
That's the real problem - most "software engineers" are not at a level of competence where they could get licensed, if such a license existed. And the industry's way of dealing with a lack of licensure is to throw more people and money at the problem, because the problem has defied all attempts to think smarter about solving it.
..., frustrating them, leaking their data, and wasting their time.
I am in engineering, not IT. The executive director in charge of engineering software for the company wants to own all data and processes. He HATES my project. My second week there, his underling told me, to my face, that it was his intention to kill the project I was hired to do. (Yeah, it's like THAT.) The ED convinced my boss' boss to stop me from working on my program, and hand it over to his team. That was 5 months ago.
When I was hired, this director restarted his THIRD attempt to write the same thing with contract, overseas labor. They've been at this attempt for as long as I have been here. Their program doesn't work very well. Literally every step (that they've managed to code) takes 3-5 times longer to do with their version. The engineers are refusing to use the tool.
My boss, through excruciating effort, has collected feedback on IT's tool, and made a list of things it must do in order to switch to it from mine. This "must-have" list is about 140 items long. The program manager of this competing tool finally "put pen to paper," and estimated that, using EIGHT people, he could code TWENTY-FIVE of the required items in THREE MORE YEARS.
Rough math says I'm a 100x+ programmer, and I feel pretty good about that, but I've worked with several people who are sharper.
I said all that to set this up: To the parent comment, yes, these people produce software, and use tools, and get paid, and all that. But at what cost? The other group has spent TENS OF MILLIONS of dollars for something that will take YEARS more effort to match something my boss did for a couple hundred grand. You're right, "they" don't know how to do a lot of stuff. The person assigned to pick up my project doesn't understand how work with Azure, doesn't understand the database schema (let alone the process that dictated it), and apparently can't even copy working code from the existing program to derive new features. If you want to give people credit for being able to log into a computer, and run Visual Studio, that's great, but there's quite a bit more to it than that. When these kinds of people are creating software, it'd be better to let the users continue to do everything in Excel themselves.
I guess some people would pat the executive director on the back for creating such an empire out of this one project inside a vast Fortune 150 company, but the waste just leaves me shaking my head. And the worst part is watching how my boss, very deftly, and very respectfully, has worked to give engineers a tool that will help them do their job, and improve the process, and how the person actually in charge of such things has fought him for almost 10 years now, trying to force people to use an inadequate tool which doesn't match how they work, just to say he owns it, and there's apparently no one in the company who will or can do anything about the situation, because it would take the CEO to make IT and engineering play nice together, and he could not possibly care less what software thousands of his engineers use, or if they do it all by hand, as long as profits are increasing and the stock price is rising.
I know, I know. This is not uncommon in large manufacturing (i.e., non-"IT") companies, but this example is the worst I've seen.
What kind of dev do you suppose know what you listed? A 1.5X, 2X, or 5X programmer? Surely not a 10X/Free Electron.
"x10 programmer" doesn't mean "great programmer", it means specifically "programmer 10x better than average", so simply writing great software isn't enough - the strongest man in the world might still not be 10x as strong as the average man.
Part of that was having great programmers with great habits, sure. But a big part of that was something like "Not letting your broken organization and practices break our delivery speed"
Bad org structures and practices pull developers and teams into poorer and poorer practices, like an accretion stream getting sucked into a black hole. The org itself can take a .1 dev and turn them into a .01 dev.
I have heard about a case where really the best programmer left, and now everybody else had more responsibility, had to learn about parts of the code they did not know previously, had to fix harder problems.
So, everybody else was getting better because the one person who could help with the hard stuff was not there anymore.
But I honestly can't remember where I heard that...
> Often complexity is generated when there is no willingness to recognized that a non fundamental goal of a project is accounting for a very large amount of design complexity, or is making another more important goal very hard to reach, because there is a design tension among a fundamental feature and a non fundamental one.
It happens all the time that requirements are very complex. Junior programmers will fail to implement them. Better programmers will manage to implement them, but it'll take too much time to develop and especially to maintain their solution.
Experienced programmers recognize what's happening and have the personality to stand up the project leader and get a simplified version of the requirements accepted.
It's also why very large software projects fail, especially the type that is intended to save costs by replacing many different existing informal systems by a unified one. The requirements will be ridiculously complicated (have to do everything all the projects to be replaced do), and nobody in the software development part has the power to change the organisation first.
Some years ago I was tasked with taking a program and fixing a major bug and adding a new feature. The original devs were gone, the code base was a mix of spaghetti code and a large number of design pattern layers. I brought up rewriting it but was told no, absolutely not. After thrashing around the code for a while longer I rewrote it anyway, taking the requirements from our actual usage in production plus the desired new feature, and was done in short order with about 1/4 the LOC of the original. A lot of supposed requirements fell on the floor, but none of them were being used and some of them never belonged in that particular program at all.
For someone like me, a "normal" programmer, this is the only way to achieve bursts of 10x productivity. At that same job there was another like-minded person I collaborated with. As a nuts and bolts dev I was as good or better than he was, but his ability to cut to the chase and somehow convince management was almost magical. 10x doesn't come from typing in code very quickly on sub-tasks.
One of the biggest problems in this type of project is that many requirements are unknown. Yes, the new system must do what the old system did, but no one can write down exactly what that is.
It's been very hard to define tasks and timescales because there are little dark corners and special edge cases in the legacy mudball that don't immediately jump out at you when trying to review the code and work out what the hell it does, and why. The original developer is long gone and there's not much way of commentary in the code. A lot of the code is illegible because somehow the original dev's indentation went mad at some point in the past.
Then there's the database....
This is the hardest thing to communicate to people running projects, in terms of why the amount of Python or Django or whatever that you know has very little to do with being a good or bad developer.
The lead on my current project micro manages every point of the code's architecture. I have no freedom to make any calls, even on legacy parts of the code that could be refactored to better fit new requirements. None of the other developers "own" anything so no one can make any calls. Anything takes a week or more to be discussed. Arbitrary non-obvious decisions have been made in the code base and it's up to you to figure them out. I am left fixing simple bugs and building things very slowly, treading very carefully rather than making it right. I am now a 0.8x programmer.
I look at my week's schedule. I see that I have a lot of meetings and checkups that, while important, are unrelated to my current project and will only take a chunk of my time and energy. I am now a 0.6x programmer.
I work in an open space office where terrible music is played through its sound system the whole day. I have a hard time focusing and staying focused. I am now a 0.4x programmer.
--
While I enjoyed the article, I think it overlooks the fact that a developer's efficiency is also often a factor of their environment (not just physical, but the project itself too). I've been 5x, I've been 0.1x, and the biggest contributing factor from project to project has been my environment. My experience and knowledge is also a factor, but this changed slowly, over time, while environment changes can mean I'll go from being super productive to very unproductive in a month. More managers and leads need to be aware of that.
It took me a long time to realize I don't have to say yes to everything that comes my way. What happens if you say some version of, "I'm not going to do that"? It may or may not be tenable option in your situation.
It's like going to a party, the host keeps offering you food, you eat everything offered to you, and then blaming the host when you gain weight.
You go down to 0.1x if management doesn't make decisions, drags you through tons of process like status meetings and stupid metrics, forces you to use incompetent vendors and so on.
Slightly off-topic, but you might try some white-noise to defeat the bad music.
If you run linux, here's a nice little one-liner in a terminal:
play -q -c 2 -n synth brownnoise band -n 1600 1500 tremolo .1 30
I resisted believing in this phenomenon for a long time, especially because I'm no great shakes myself. But in the end it could no longer be rationally denied.
Works great if you pair them with a more senior developer who has the chutzpah to make an impact by deleting egregiously bad code. E.g. one of the best I know made a failing project succeed by literally deleting all unit tests (which in that case were not providing value at all).
Code? I know people that have caused big projects to fail by just showing up at the meetings. The amount of damage a -10x idiot can do to a project is just mind boggling.
Here is my unsolicited advice to young players: if you end up in a project with a -1x (or worse) guy who is also the darling of the PM or CEO: no matter how hard you work you cannot save this project, don't wait for the shit to hit the fan, give them your two week notice today!
I think that's probably quite normal, except for small pieces of software.
If the snags aren't becoming less significant though then I agree, that's a big warning sign.
I am today, a 10x better programmer than I was where I started. In terms of quality, complexity, efficiency, readability, maintainability, everything. I was paid too much when I started and/or not enough now!
Notch and Carmack are 1000x better game programmers than I am. Linus is a 1000x better file system and operating system programmer than me. Monty is a 1000x better database programmer than I am. DHH can build a website at least 10x faster than me and do it in a way that would contribute 100x more to the community than I could.
If you discard people with decades of experience. If you discard people who have specialized. If you discard the many geniuses in our field. And then if you start to make excuses at the other end, and if you narrow it to a specific set of tasks, with a specific set of complexity, then maybe there isn't a huge gap. But even then, I feel that if you apply yourself to that task for a decade or two, you'll find that you're a 10x better programmer than you used to be.
I've seen programmers that were dead weight, moved to a different team and begin to flourish. I've seen programmers that on paper were the least valuable part of the team, do all the small things so well they were actually invaluable. I've been the developer that was considered a 10x dev but due to life stuff getting in the way I was probably a negative.
So sure, there are developers who are better than others, maybe even in non-linear ways, but so what? I think we can put lots of 1x developers into situations were they get 40% productivity improvements and that will go a lot further than chasing the long tails of 1000x devs.
The fastest way to kill high levels of productivity is to not value high levels of productivity.
Edit: And I believe there is a strong correlation between people who value high levels of productivity and people who can build highly productive work environments.
Maybe we should discuss the role of the managers in getting everyone closer to their 10x potential instead of talking about this mythical always-10x creature?
I don't think we're saying anything exclusive. From what I've seen, pretending the gap doesn't exist (for whatever reason), is a sure way to make sure things don't improve.
I've watched Notch program, and while he knows of lots of game related algos that I don't, he's not a magical snowflake and it'd take me no time at all to find those algos and implement them. There are huge swathes of the code he writes that I'd be comfortable writing at about the same speed.
From experience solving other complex problems in unrelated domains, it might take me 2 or 3 hours of googling, once, for particular problems. The worst ones a day or two. After I've done it once, it's not hard to either remember or find that code and remind myself.
It certainly wouldn't take me 1000s of hours as you seem to think it would.
I don't believe in 10x programmers. I don't agree with many things stated in this article.
What I believe is that most programmers have a complexity ceiling, where if the code goes past a certain level of complexity they are practically useless on that code base. Often they can just deal with bits of it, but try getting them to do a large scale change and they simply can't. They can't reason coherently about their changes. I think both natural talent and experience raises that ceiling, as does time spent on a particular code base (just for that code base).
And that's where I think the 10x myth comes from.
EDIT: I've even seen projects where the original authors couldn't make much more progress with an operational product, I call it 'coding themself into a corner'. They took the project past the point of the complexity that they could personally handle.
I think "10x dev" usually means 10x average - with the assumption that the average (or median?) is still fairly productive. Also, what metrics have you to conclude this? Do you actually measure your own productivity, or is this a subjective judgement?
When discussing this, I think it's important to be aware of the strong psychological bias that skews our perception of how we have improved ourselves over time. I expect you are a better programmer but people tend to significantly overestimate the extent of improvement.
If I work at it, sure, in X years, maybe I can be in the same ballpark as him. But today, if you wanted a game prototype or full game built, Notch would be worth more than 10x me. Just think of the experience he's collected.
If we're talking in the abstract, sure, maybe he isn't 1000x the programmer I am. I'm not really sure there's a huge value in looking at it that way though.
Too many people approach "programming" like it is a simple execution of ideas. It's more art than execution and I've been inspired by the creation of many amazing programmers in my long career. And in 35 years of developing technology to solve real-world problems I've managed to have a couple nice ideas that inspired others.
To me coding is a creative process, often I will code for many hours straight without a break, I will "wake up" afterwards like I was in some sort of trance. My wife laughing at me as I realize it's dark outside, not because it's still morning, but because the day disappeared and its night time again. For me coding is a form of meditation, it's pure thought and comes from somewhere outside of my body out my fingertips like lighting into the keyboard. It's a gentle dance with a computer to dialog with it about a problem I'm trying to solve and ways it can help me or many of its friends can help me.
If you don't feel this way about coding, maybe something else is in your future, but for me coding saved my life and without it my soul would be trapped in a metal box without any way to express itself.
Am I a 10x coder, I don't know, I don't care. What I know is I am inspired by amazing coders and sometimes when I'm really lucky I inspire someone.
EDIT: PS: Antirez has inspired me every time I've looked at his creations. I wish some day others could feel that way about my work.
So whether intentionally, tempermentally, just due to the constant demand for their services, or just because it's tautological, the 10x programmers don't actually contribute back to their team's knowledge, which means the rest of the team stays at 1x, and whent he 10x programmer moves on to another project or company, the rest of the team flounders around while they have to figure out all the things the 10x programmer never bothered to share.
But, did any of the other developers even look at what the other ultra-productive developer did ? Did it get studied in detail, and were questions asked of the ultra-productive developer ?
I've been the ultra-productive developer in such a situation before. After a couple of runs of "hey, here's some cool things that I did that I thought you might be interested in" followed by a lot of glazed-over looks and shifting in seats, I got the message and stopped doing them. There simply was not any interest, and I learned a valuable lesson: most developers don't have any where near the same level of interest in the craft as those that have done it for 25-30 years and are passionate about it. It's just the way it is, and no amount of persuasion or pleading is going to change it.
Either that, or I'm mind-numbingly boring and that was the reason... ;-)
I think I experience this in my hobby projects, when I fully own the project even when it is fairly complex, every time I spend an hour or two on an evening I pump out a few features that on a big team project would feel like they could've cost weeks.
The physical analogue I offer which might be a little far fetched is the construction worker. I have been renovating a house, doing demolition, basic construction, electrical, plumbing, and hopefully in the future finishing of the house. I'm a total novice, so obviously it's going slow, but eventually I will have constructed (most of) an entire house. Because I do everything, there is little to no overhead (besides me having to learn everything) when switching between tasks, I own all of the project. I bet that someone who solo-renovates houses as a full time job is ridiculously productive, much more so than a general contractor managing a team of subcontractors.
Anyway, obviously this is all just hypothesizing based on anecdotes.
If we go meta and generalize the disagreement, the skepticism about "10X" is the same as the rejection of other labels such as "ninja" and "rockstar".[1] For some, the idea of categorizing a subset of programmers with a grandiose label is psychologically distasteful. It doesn't matter what the label is; any label that attempts to stratify programmers is a "myth".
As for "10x" specifically, I'll repeat what I've written before...
To make peace with the "10x" label, I suggest people just think of it as a rhetorical figure-of-speech instead of a rigorous mathematical term. We don't get hung up when people say "Star Wars IV was 10 times better than Phantom Menace" or "I'm not even 1/2 the football player I used to be."
Even if people were to use a new term such as "3-Sigma Programmer"[2] instead of "10X Programmer", the ensuing debates would still be the same.
E.g. "Some people say 3-σ programmers write string parsing loops that are better in speed and quality than 99.7% of the other loops but that 3-standard-deviations-above-the-mean is a myth... etc"
The argument pattern would be the same: take a label, any label, hyperfocus on some literal meaning to the exclusion of all other colloquial usage, and debate why that mathematical interpretation fails in the real world.
tldr: "10x" in discussions is more of an informal ranking of programmer ability and not a rigorous mathematical measurement of output.
[1]https://www.hanselman.com/blog/TheMythOfTheRockstarProgramme...
The comparison between writing a play or a program starts to break down if the problem space is narrow, as the article also mentions, so a lot of what people end up arguing about is what programming actually is.
I've seen cases where one ostensibly 10x developer comes in and solves 90% (the easy parts) of a problem. Management love him. Then he moves on to other projects and leaves a team of "1x developers" to deal with the 10% (which management still insist on having). This team now have to re-write everything this superstar did from the ground up without taking shortcuts this time. The time it takes makes them all look like 0.1x developers.
Their code worked, but it was also incomprehensible to everyone else on the team.
I have found that high-speed programmers tend to develop a very personalised workflow style. They do things their way, they code their way and forget that other people may have to maintain that code.
What slows down my productivity more than anything is looking at someones code and thinking "Why did they do that?" Simplicity pay off in the long term.
However in reality, and what my comment was referring to, is that every sizable team has that one dev who rattles off code quicker than anyone else. Yes it works, but it will have a lack of comments, or they don't check in often enough resulting in merge issue or worst of all they implement a design pattern no one else has heard of.
I worked with a guy who was the star of the department, a nice and friendly guy, but holy crap he built some interesting solutions. Example: Our main product could only be debugged if we started up a development environment, consisting of 12 VMs. The 10x guys only problem was that the subnet these thing ran on was a little to small for all us to have a full environment.
You're absolutely right that these people develop tend to develop a very personal style, and often it's harmful to everyone else.
I've observed on a number of occasions that very good programmers get accused of writing "incomprehensible" code simply because they use data structures that you learn in the second half of CS 101, e.g. token buckets or bloom filters.
The kind of developer you describe literally almost the complete opposite of what antirez was talking about!
It's because the 10x programmer is too fast for the team. Therefore its code is not shared with the team (no time to explain, to time to document, no time to teach), so the team doesn't understand it. But it's not team's fault, nor the 10x programmer's. It's the delta between them.
One thing that it's missing from the post is a bit of focus on how good developers (and indeed good leaders) concentrate on maximizing their impact. Not only you want to be fast and reasonably accurate, but also make what you do matter. Sometimes shaving down compilation time by a couple of minutes will save each developer in the team two minutes multiple times a day for years, for example. Not all productivity wins are obvious.
Yes, it's obvious that some people are getting a lot more done, but it's very hard to quantify and vulnerable to social engineering. It can be hard to spot quieter people working effectively, and it's really hard to quantify those who spend their time helping others or improving team effectiveness or business communication.
Or the other extreme, people who overengineer everything in anticipation of a future that will never come.
Which is also unquantifiable and is a very similar myth.
In Peopleware, DeMarco and Lister write:
Count on the best people outperforming the worst by about 10:1.
Count on the best performer being about 2.5 times better than the median performer.
Count on the half that are better-than-median performers outdoing the other half by more than 2:1.
The best people outperform the average by 10x. | | | Probably
| Unemployable | ___ | Over-
| | ,' : '. | qualified
| | / : \ |
| |/ : \ |
| .' : '. |
| -" | : "-_ |
| __--"" | : ""--__
|____---""" 0| | : | ""--___
+------------------+-+-----+-----------+-----------
| | |
0.25 1 2.5 (10x)
Whenever someone exceeds base expectations to such an extent that they hit the ceiling for the position they are in, they either get recognized and promoted, they job-hop to the next rung up the ladder, or they throttle back their own performance to be proportional to their compensation.
There are a few jobs that are at the top of their respective career ladders, where there is no choice but to offer profit-sharing as a means of encouraging best performance. So you can get a 20x CEO, or a 50x celebrity performer, because they get paid a percentage, and there is nothing else to be promoted to, except young passive-investor retiree.
[1] Programming Pearls. Jon Bentley (Column 4)
This is one of the reason working in software sucks so badly these days. You'll inevitably be forced to work with lesser tools in more ceremonial ways, which takes away most of the leverage from experience and skill; effectively dragging everyone down to the lowest common denominator where everything is done according to some stupid, over engineered specification.
And one of the beefs people seem to have when I share my code publicly. Cutting corners and side-stepping complexity is where coding turns to art for me, where the fun begins; which means that many of my programs look like toys in comparison to "serious" software. Yet they still manage to get the job done for less effort, and a closer look reveals that the simplicity is carefully engineered. I just don't have much time or patience for ceremonies these days.
At the beginning of my career I've done comparable things. I once spent multiple weeks implementing a solution to a problem that would have been trivial if I had known about unification [1]. Thousands of lines of complicated C++ code, countless bugs,... If you don't even recognise the problem, how can you expect to find a reasonable solution in a time that is only 10x as long as it would take someone who recognises the problem and knows how to solve it?
[1] https://en.wikipedia.org/wiki/Unification_(computer_science)
In my experience, most competent programmers encounter problems they can't solve off the cuff frequently. Then they think about it, research a bit, formulate the problem, etc. They come back to solving it after stepping back because they realize they're in the weeds and just treading water.
At a certain point, your colleague must have realized this task was simply beyond his "off the cuff" abilities and gone looking for a more efficient way. Surely he had the presence of mind to realize he was beginning to be unproductive? How did he spend weeks on a problem that can be summarized as "retrieve a lot of records from a database"?
Furthermore, what was your organization like that someone that grossly incompetent wasn't checked in on about progress? There was no "mercy rule"? No referee to call it when it was clear it was taking weeks instead of hours or days?
I guess I'm just confused because I don't consider myself a particularly spectacular programmer, but I'm self-aware enough to search for a solution and RTFM for the tools at hand. I just don't understand how weeks were spent here. I've never encountered a team where it seemed like one person was that far off from the median (to be fair the companies I work with likely wouldn't use them as a point of contact though).
A 10x games programmer in a small studio could easily become a 0.1x web dev in a big web dev team.
20% - Not productive. They can't get their tasks done, and after awhile, no one even expects them to. They get routed around. 65% - Neutral. The quality problems and technical debt they incur matches their productive work. 12% - Net negative. They introduce hard to fix bugs and technical debt beyond their productivity. 3% - Gods. They do almost all the productive work. Without these types of people, no large project would ever get done.
1. Solving problems for the Nth time instead of the first leads to substantial gains in productivity, easily 10X gains on your first attempt.
2. Architectural decisions add another multiplier on the above: picking the wrong database type, structuring and reorganising your models, spending time to design ahead vs coding right away, all can /10 or 10X your project easily from fixes and re-dos alone - combine both 1 and 2, and you have potential 100X gains.
3. Risk-distributing the project work: eliminating the worst 5% as the author says, and/or writing the most complex parts first to reduce risk of massive rewrites in case something doesn't meet expectations in its most critical functionality.
4. Having competent business requirements providers who won't move the ground beneath your feet. You can be 10X or 100X more productive when writing new code, and that much slower when rewriting someone else's bad decisions. It's no different than trying to build a skyscraper on foundations built for a garage.
Stack the above as A x B x C x D and you can see why you might be able to beat your past self 10X or 100X and more between projects. Having teammates who can beat you is even better if you can learn from them and accelerate your own progress by skipping time consuming mistakes.
- Distractions
- Feature creep
- Poor code organization: coupling, action at a distance, cyclomatic complexity
- Noise: comments that do not get to the point. A tool to mitigate this is https://foxtype.com
- Hacks and lack of consistency
- Lack of automation: tests, builds, deployments
Regarding hacks, imagine what would physics equations would look like if a fundamental constant was wrong. All equations would need to compensate for it by including some arbitrary constant making everything more complicated. That is what messy code bases look like, layers of lies to compensate for lies. Clean code is more straightforward, easier to work with.
Regarding iterations... does the army run an exercise with soldiers and trucks and live ammo each time a general wants to test an idea? No. They use simulations, and only the ones that look promising are turned into exercises. So rather than asking engineers to prototype some throwaway idea, get your hands dirty and use Powerpoint and your imagination, stress the idea, then build it. And if it's built, keep it in a feature branch until you've actually decided to keep it for good.
When a car is built, engineers tell designers to modify their concepts in order to make the production more cost efficient. Same in software... be prepared to negotiate requirements if that is in the best interest of the project.
10 year novelists are often amateurs. That novel your next door neighbour asked you to read? He's probably been working on it for years.
Even notoriously slow George R. R. Martin takes less than 10 years to write a novel.
Because having different output has nothing to do with being more productive. It's just different, that's it. And productivity is very hard if not impossible to quantify. Relevant experience and knowledge might boost productivity on a specific problem, just like it might make code nearly defect-free with little to no effort, or make someone much better at quickly understanding large code bases. But it doesn't mean that a person is going to be motivated and rested enough to leverage it for the benefit of their employer or that another person is going to be just as unmotivated or that it's not going to change for a different problem, etc.
I've certainly worked alongside programmers who's output is so bad that I would consider myself both 10 times better and 10 times faster. And I wouldn't even consider myself a top teir programmer. They are often people who's contributions to the project are net negative in that they actually require additional work from someone else to go clean up their mess afterwards.
Stop imaging a mythical coder who is 10 times better than everyone else, and instead think of the worst coder you've ever worked with who is 10x worse than everyone else. There is your 10x'er. We are nearly all 10x'ers when compared to the bottom few percent.
It looks good at the present, but the team pays for it in the long run - long after Mr 10x (it's always a guy, right?) gets fed up with the process bloat and criticism and whining and leaves for greener pastures.
I've cleaned up after 10x programmers.
Interestingly, sometimes that cleanup was an intentional part of the process and looked more like maintenance and extension of rapid prototypes. It still felt like I was compensating for all those bad habits of Mr 10x.
I think Anders Ericsson does a good job of explaining the phenomenon in his book Peak: http://uk.businessinsider.com/anders-ericsson-how-to-become-...
What we should be doing is looking to create companies that can allow workers to reach and sustain peak performance in all areas, not just coding.
It's about the unintended side effects of trying to be a 'Natural Selector'. One example is selecting individual hens on egg output to create a breed of high-egg producers. The result was mean chickens which had gains b/c they were very aggressive. The breed needed to have their beaks clipped otherwise they would kill each other. When productive groups rather than productive individuals were selected though, they got the desired effect. (Though in another example I can imagine selecting for mean group behavior)
Another example was trying to selectively evolve animals that would self-limit reproduction. (to avoid overpopulation and resource over-consumption) The end result was selecting for cannibalism.
In organizations, the equivalent of propagating a feature are the hiring stage and the promotion stage. Whatever you hire for, or promote for, will be the trait that's optimized. Whatever the side effects may be... (e.g. Enron)
I can be 10x, even 100x when working on something I've already solved & have "big" set of components ready to plug in (with a little bit of tweaking). The more stuff you have, the "luckier" you are. It's also ability to spot patterns & good memory & being in a flow.
> Surprisingly the ability to use basic imperative programming constructs very efficiently in order to implement something is, in my experience, not as widespread as one may think.
Those words are spun better than I could do, and I'm a native English speaker. Bravo!
Maybe something missing from the list is hard work and long-term dedication ;)
In my mind, the mythical 10x programmer is the person that can complete business objectives while helping make those around them more effective. This isn't actually a myth, and "10x" is a completely arbitrary number that doesn't mean anything. It might as well be 2x or 1.1x -- they all mean the same thing to me. They can do their work at 1x speed, a baseline set by the developer in question and not their peers, but they can simultaneously help others around them be more productive.
Parnas’ ”On the Criteria To Be Used in Decomposing Systems into Modules” https://www.cs.umd.edu/class/spring2003/cmsc838p/Design/crit... [PDF]
Christopher Alexander’s Notes on the Synthesis of Form http://www.hup.harvard.edu/catalog.php?isbn=9780674627512
Both get deep into how a design emerges from the relationships among what Antirez is calling "sub-tasks". Antirez refers briefly to these relationships in the "Design sacrifice section." Parnas and Alexander put them, correctly I believe, at the heart of the craft.
Parnas was a software engineering authority. Alexander went on to write A Pattern Language, from which the software community derived "design patterns" as a foundational idea.
I mean at the moment I'm actually changing my code that was simple at first, but over time more and more things were added and it started to complex. The thing I'm doing right now is getting rid of the complexity to add another future. Well mostly I think a big problem is that many people actually think about the design too much, since the design of a program will eventuelly be changed anyway. What worked for me was design something that works in most cases and grow that path or throw it away if it sucks.
btw. I love what antirez did and does for the community of programmers.
I always use a redis client to teach people more about network programming in java. It's a extremly simple, but still powerful command set/protocol. I hope he can keep up his work.
For a simple example, if you're asked to implement something like a blog, you would naturally be prepared to be asked for authentication, authorization, contact us forms, commenting, etc. If you're aware that there's a high probability of such a change request in the early phases (but not NOW), then that anticipation will usually result in better code.
It's the essentially the same as optimizing a computer program: you can't make it do more work faster, you can only make it do less work.
And if 'less work' means the problem is solved anyway then you are a 'faster' programmer, even if you produce fewer lines of code than your 'slower' counterpart.
Probably the biggest aspect not dealt with in these writings along with the discussion around it (is there or is there not such a beast) is bias.
For example, selection bias: e.g. my view over what was the best / worst programmer was much different when working in different teams. I found out there could be much worse than what I thought is the worse. Then I learned that there could be much worse... It's like a fractal :) As you notice these differences a 10x difference doesn't seem that crazy. It's really things that should take a few weeks, which in turn take months or years or never get done.
Also like any other optimization problem, optimizing software development is about hitting a moving target. When the team is balanced, it may be the process that will become a bottleneck, etc.
https://www.facebook.com/notes/kent-beck/mastering-programmi...
Often when you find someone who's really good at what they do, they're the type of person who loves their work, and they've managed to find employment in an environment that suits them. The two are of course mutually helpful.
Also keep in mind it can be very hard to find more than one space for such a person. It's like how certain soccer teams are built around a particular star player; everyone else plays to suit that guy, and it would be hard to fit a clone if you had one. Others may well be suited to a star role, but happen not to have landed the role. Watch the Tour de France to see what happens when the lieutenant steps up to the captaincy. I can often be dramatic.
BTW I have always known that the 10x programmer exists.
A sufficient proof is that on good days (with proper motivation, concentration, no interruptions, enough coffee etc.) I'm 10x the programmer I am on bad days :)
In short, as the saying goes: Decisiveness is overrated.[0]
"Perfectionism and fear of external judice insert a designing bias that will result in poor choices in order to refine a design only according to psychological or trivially measurable parameters, where things like robustness, simplicity, ability to deliver in time, are often never accounted for."
Otherwise consider other human qualities such as communication skills, adaptability and critical thinking as more valuable than raw coding skill.
That requires identifying areas where you can deliver value. Frequent cost benefit analysis of potential features vs their estimated cost. And as antirez said in the article, designing these things so that less code gets you those features.
The difference is kind of like book smart vs street smart. If you are just book smart and you understand algorithms and data structures really well it can only get you so far. You need to be able to interpret the user's requests and design what will really help them. You need to understand what they are asking for and what they really mean. And you need to generate solutions and sell them.
..and an environment that fosters such low productivity norms, probably also gets it's developer productivity measure/metrics wrong as well, so you don't even need a 1.25x for the perception of a 10x...
Get your ass up from the chair and go outside to exercise if you wanna reach Antirez levels of mastery
In another migration measured the time to cut and paste and concluded a day of grind was better than a week of scripting.
Many tasks have a thin path to completion surrounded by cliffs on either side. Experience teaches when to focus on the critical path only vs when to take a wider view.
There's easily a 10x productivity boost there.
Which I think is bull, of course. You can't quantify things like that. Some people are better than others, but any claim of 10X or 200X is missing a much bigger picture of how humans contribute to each other's work.
My number one observation about productivity usually revolves around how an engineer attacks a problem and handles scope creep. There are some programmers who can get a set of requirements, and like a trained surgeon get in, fix the big bleed and get out. While they are in there they might fix a couple close issues but they are not re-architecting the whole application. Then there are others who see all the problems, they notice this problem there, and that problem here and keep asking what does this all mean and it eventually cripples them. They spend some much time seeing all the problems, that they never get around to solving the one they were tasked to fix.
Once you realize you won't understand it all from the beginning and you can't fix every issue you see. You become a much more effective engineer.
This is far too extreme and turns you into a counterproductive team member. Like everything in life, a balance demands to be struck.
"you can’t be good doing things you do not love"
If programmer productivity, or software developer/software engineer productivity, is measured as a linear function, then it really does no service to the field. Beyond looking at network effects from the impact developers have on each other, there is no universal measure of productivity. It would be more believable to say that certain developers have twice as many or five times the number of lines of code produced that are defect free, than to say that they achieve a certain level of productivity.
The two reasons that this should be immediately seen as nonsense to anyone in the field is that first of all, computer problems deal with asymptotic complexity. In the asymptotic world, linear functions are outshined by constant, logarithmic, polynomial, and exponential functions. Furthermore, the prevailing wisdom among programmers is that 'less is more'. That's why we talk about minimizing lines of code and trying to avoid the most bugs by leaving the least surface area for them to exist to begin with. Introducing a measure where 'more is better' is sort of at odds with this philosophy and should be viewed skeptically.
Finally, if you look at the great successful innovative products in software, and technology in general, you'll see that they often make use of new inventions. There's no way to compare an inventor in terms of productivity by saying one has 10 times as many patents as the other, or to compare a mathematician by the number of papers or pages published. The important difference is the quality of the invention or discovery. The engineers at AltaVista and Yahoo could have been extremely productive, but without a revelation like Page Rank, they never could have competed with Google back in the early days of search engines. Here, two college students writing a small amount of code outperformed larger companies. This has nothing to do with productivity and everything to do with talent.
This leads me to believe that the "10 X" slogan is a product of marketers, head hunters, and pop psychologists. It has no bearing on the field of computer science and it is a harmful concept because it perpetuates the idea that software developers are replaceable parts rather than unique contributors.
"can imagine one good at doing its work": "its" → "[his|her|their]"
"who says there is no such a thing as the 10x programmer, who says it actually does not just exist": "who says" → "some say" (At this point I guessed, wrongly, that your native language might be Russian)
"a lot less efforts" → "a lot less effort"
"to do a much better work" → "to do much better work"
"graduated programmers" → "programmers with graduate degrees"
Just a little help from one non-native English speaker to another
At least 1/2 of programming is learning. You can make a basic Android App, but have you learned how to do 'deep linking'. Well, it can take a full day the first time because it's awkward, and you have to understand a few things, and set a few things up server side.
Second time - it'll take 1 hour.
There's a lot of that.
If you're really comfortable with XMLHttpRequest, and know the ins and outs of post/form structures - well then you can do something quickly in it. If you don't well, it could take a bit to learn for a new dev.
Those things add up a lot. It takes several years to get comfortable with the variety of tools and tech necessary to be good.
Maybe you'd be 10x more productive if it didn't hurt everyone's eyes to read your writing.
Your comment could be a line from Sheldon in the Big Bang Theory :)
burden is on the you to show that "10x programmer" is "an expression, a saying or an image". Plenty people consider the term to be literal, and argue as such all over HN.
In fact, the management are often the last people to notice if someone in their company is a 10x guy.
“Right. I don’t believe in the idea that there are a few peculiar people capable of understanding math, and the rest of the world is normal. Math is a human discovery, and it’s no more complicated than humans can understand. I had a calculus book once that said, ‘What one fool can do, another can.’ What we’ve been able to work out about nature may look abstract and threatening to someone who hasn’t studied it, but it was fools who did it, and in the next generation, all the fools will understand it. There’s a tendency to pomposity in all this, to make it deep and profound.” – Richard Feynman, Omni 1979
Stop the pomposity. Please.