All programmers have different output. How is it even a debate? Some people are more productive than others. Just like one novelist takes 10 years to finish his novel another writes 2 every year.
Actually, I think it's the inverse. Most 2/year novelists are professionals, and it shows. Stephen King consistently wrote at about that rate. 6 months full-time is a good amount of time for a professional writer: 1-2 months for writing, and then another year or so of polishing and editing that happens in parallel with other efforts.
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.
Two novels off the top of my head with far greater significance that anything GRRM or SK have or ever will write that took ~10 years to write: Dispatches (1968-1977) and Infinite Jest (1986-1996).
Feel free to think that a novel is something one cranks out as if it's just an object that carries no meaning, requiring no sacrifice from the author. But that's an opinion, and not fact.
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.
To clarify what I meant by "how is it even a debate?": I just find it a bit "surprising" that many people in this industry refuse to believe that many programmers are 5x or 10x more productive than others (and write just as good code).
I should clarify too, that I do think it's incorrect to believe in so over generalized concept, these things are much more complicated to claim something like that. I also believe that nobody is going to be a very productive programmer working for an employer. It's just unhuman to work hard and make choices pursuing somebody else's success.
I thought the research that produced the legend of the 10x programmer showed that he was 10x better than the worst programmers who were still good enough to be employed, and only ~2.5x better than the "average" programmer.
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.
What nearly everyone who has read that remembers is the following:
I don't have the book ready here, and it's been a long time since I last read it, but wasn't that the productivity for specific, limited and well-specified tasks? How about the productivity of tasks that only a subset of developers would be able to solve (which don't have to be that hard, like a bug-free binary search, which according to Bentley[1], eluded 90% of professional programmers)? How do you quantify the difference in performance for that?
People with skill below 0.25 cannot meet the minimum requirements for the job, or cannot be productive enough to cover their labor costs. People with skill above 2.5 have likely been promoted beyond the parameters of that job.
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.
When considering the implementation of a new system, sometimes considering the relative value of the path is a better and more profound action than than taking it. Similarly, implementation of a system does not necessarily imply deep comprehension, correct or intuitive forward-looking design, composability, repurposability, security, or any other property.
In short, as the saying goes: Decisiveness is overrated.[0]
10x what, though? No 10x engineer would accept a unitless quantity from uncalibrated measurements of terrible accuracy.
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.
It's even harder when you factor in people who seem to get a lot done quickly, but at the cost of huge technical debt that will slow the project down to a crawl in the long run.
Or the other extreme, people who overengineer everything in anticipation of a future that will never come.
If the domai space is broad, complex, and immensely resistant to quantification, then a 10x engineer would probably prefer a unitless rough approximation over some precise yet useless quantified description.
Kudos if that's the case. An essay on soft skills is probably the most difficult genre to master for a non-native speaker, more so for a programmer. I'm ok with the piece, as long as there was effort involved and it's better than Google Translate.
I've been reading antirez's writing for a long time and he's been consistently getting stronger as a writer of English. I think this is some of his best writing yet in terms of grammar and use of the language.
That's a valid point! A quality of my poor english is that I write it at the same speed I write Italian. This blog post took me 10-20 minutes at max to write, even if the concepts I elaborated for much longer time when thinking/talking about these issues with people.
"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
I have a friend who is an amazing musician, fairly successful and quite inspiring. He's no Wolfgang Amadeus Mozart and he knows it. Everyone can accept that fact.
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.
I'd argue that it's greater than that these days, many programmers really just can't do what a lot of good programmers can do. Even if they're given all the time in the world they'll just never get a result. So whats that make them infinityX programmers?
Exactly. At my last job, a colleague of mine was tasked with creating a tool to generate a monthly summary report based on 100s of millions of records. It took him weeks of trying to get something working in Python (naively read in all the data into Python objects and then trying to iterate over them), coming up with convoluted algorithms trying to speed things up. His final solution took multiple days to run (too slow for the requirements). An equivalent solution using PostgreSQL (using the built-in COPY to parse the CSV records) and couple hundred lines of SQL (a day's work) could do the job in less than 10 minutes.
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?
yes exactly, funny when I was writing that I had the same thought about what I was like when I first started - I had a flashback to spending days writing out some C code for a linked list. I thought it was cool at the time, comparing that me to this me, then it would easily be a 10x difference. qed.
I don't understand this. I'm not saying I don't believe you, but it seems ridiculous to me. I actually feel vicariously annoyed just reading that story.
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).
> I don't understand this. I'm not saying I don't believe you, but it seems ridiculous to me. I actually feel vicariously annoyed just reading that story.
It was ridiculous, and I was annoyed at the time too. Especially because I had basically laid out how to solve it just before I left that company. Somehow that didn't get communicated to him. When I went back for one day 5 months later, I learned that he was basically still nowhere (he had been doing other things too). I spent an hour with him laying out the solution in detail. From what I last heard, he listened, and that is the solution they are currently using.
> 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"?
If you only have Python experience and no intuition about how much time/memory certain problems should take, you don't necessarily know when you're out of your depth. It was a Django shop. The only exposure most of the people in that company had to the RDBM was through the Django ORM. Multiple times I have seen them do things through the ORM which would be trivial and multiple orders of magnitude faster with a couple of lines of SQL.
That data also didn't come in a database, but in a series of CSV like files. If you don't have RDBM experience, you don't necessarily see how you would use a database for this problem. And Python conveniently has a csv module that will happily parse your files into objects... If you buy into the marketing that Python is 'fast enough', and 'you can always use Pypy if it needs to be faster', you might not realise when you get stuck.
> 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?
Management didn't know how long that task was supposed to take. The technical competence in that company was very limited, and they were used to deadlines slipping all the time.
> I'm self-aware enough to search for a solution and RTFM for the tools at hand.
That puts you ahead of the pack, in my experience. I had almost no experience with RDBMs before I joined that company, but reading the first 100 pages of the PostgreSQL manual the first week put me ahead of people who had been using PostgreSQL as their principal tool for more than a year (a different team, the metrics team which used PostgreSQL directly, not through the Django ORM). They had never heard of simple things like VIEWs and WITH queries.
> I've never encountered a team where it seemed like one person was that far off from the median
I don't think he was that far off from the median in that company, maybe just a bit below. To be fair, it was technically the worst company I've ever worked at. I was only with them for 6 months (and I never would have started there except for personal circumstances).
Consider yourself lucky never having worked at such a company. They are more common than you think.
Everything from the original post sounds reasonable, you should absolutely read it. Just some random thoughts to add to it:
* 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 have definitely been involved in teams where removing the "top programmer" made everybody more productive. Usually, these developers are "10x programmers", in the sense that they write 10x the lines of code as the rest of the team, it's just all bad.
Yes, I have seen that too, but that's not what I was talking about.
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...
Ah, I've also seen that situation. But both times it was because the lead programmer was an autocrat who would scream at people if they did things wrong or revert their code or fail their code reviews, etc.
They were, as individuals, very productive, but they suppressed the productivity of the rest of the team.
That reminds me of "The Metamorphosis" by Franz Kafka. The transformation of Gregor Samsa (who was the family's the primary breadwinner) into an insect turns out to have a few unexpected benefits for the family. The develop self-confidence, regain health and skill, all that was lost because of their dependance on Gregor.
Maybe this is the distinction that throws off these "10x programmer" threads: the idea that a 10x programmer produces ten times the amount of code in a given time. The best programmers I have worked with frequently replace thousands of lines of code with hundreds. Programmer productivity is about value delivered, not lines of code.
Exactly. Years ago, one company I was at proposed we start a bonus plan based on lines of code. I wrote a script that inspected the RCS commits (it was years ago) and generated a report that showed that most of our best developers were net negative lines of code.
1.) When I am stuck on hard problem, he is a good bet for help.
2.) History: was assigned tasks or project multiple people failed previously and was first to succeed.
3.) Tasks and projects assigned to him/her move with reasonable speed, does not need handholding. When other people take over, they don't complain all that much and are able to continue without encountering major wtgs.
The best programmer I have ever worked with used to be my boss. When I learned Perl, he had me write a very simple program to monitor some network printers. When I was finished, I showed him what I came up with and it worked pretty well.
I guess it was to show me that I was thinking too much like a C programmer, he rewrote my program in about 10 lines of Perl.
He was always willing to listen when I had design ideas that differed from his own. When my ideas were better, he'd incorporate them into our plans.
We had a four man team that was probably the most productive one of which I have ever been a member.
I have seen that with a guy that produced alright code, but was pretty bad leader - which was clearly his ambition. You either did everything exactly his way or had to argue for hours and days. The result was that whole project moved slowly, initiative people punished and parts of project he could not micromanage were mess anyway (since everyone else either left or was too passive).
Come on, Antirez is a x10 programmer, he coded one of the most brillant software of the last decade. It's so well done I use it as an example in my trainings, making people compile it to stop being afraid of building from source because I know it never fails and it's so damn simple.
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.
While I agree with almost everything you wrote - I found that original post awesome and there are many great lessons in it - I don't see what this has to do with my comment.
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...
> For most of my past clients, the skill / output of their programmers was not the bottleneck
Of course it was not. If you are antirez, you will mostly work with people on projects which, by nature, will involve talented programmers.
> Improving how the team works together / how work flows through the system probably has a bigger impact than raw programmer output
But only a person good enough can do that. This is catch-22
> Improving the quality of your software (minimizing defects and rework) will improve the output of everyone in the team
Yes, but it requires a really good dev to create and execute a plan to progressively enhance it. Instead of doing another from scratch which will also fail.
> I have heard of cases where removing the "top programmer" from a team made the whole team more productive
Yeah I heard of people stopping vegetables and living fine as well. And "top programmer" <=> "top dev". You can be very good at software and terrible with people.
My point is, the entire article is build on assumptions from the "top programmer" perspective.
All that goes to the water when your team is composed of:
- a senor waiting for retirement
- an apprentice fresh out of a community college
- a new dad who needs money and hates his job
- a legacy spaghetti code project coded by 3 different teams 10 years ago
- and no 10x programmer to be found
It will work. But say goodbye to best practices, and all the rules Antirez is stating.
> Come on, Antirez is a x10 programmer, he coded one of the most brillant software..
"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.
Oh yes. We tend to wrongly assume the goal of most companies is to do correctly their job. It's not. Their goal is to make money.
And a lot of businesses do so while providing terrible services or products. Plus people working for them have their own agendas : family, play, not get blamed, etc and won't do anything about it.
It's not specific to software. How many of you have experienced :
- a completely broken by design shower
- those "easy to open" packages that are impossible to open
- kitchen ware taking centuries to wash because obviously nobody designing them never bother to use them
- laptop with horrible sound
- shoes that destroy you feet after 2 hours of using them
?
Doing your job well is the exception, not the rule.
So you're saying that 10x developers definitely exist, it's just a disappointing state of affairs.
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.
Alright, my turn for anecdata, since I am having this... "discussion" right now. About 3 years ago, I was hired to write a program to partially automate an incredibly complicated engineering workflow. It was a total rewrite of a crufty program that had been running for about 5 years (written by my boss), but which couldn't keep up any more. It took me MONTHS just to truly understand the process, and about a year and a half (after a few experiments) to get to a stable, mostly-feature-complete version. Hundreds of people are now using it every day.
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 do you expect ? you are at HN, and the bubble is strong here.
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.
HN is a bubble for sure, but that may not be the reason why low-code tools are not discussed. Suffice it to say that my interest got less and less piqued with every single word in the URL you provided (I was already biased against it before even reading the report), and I couldn't get past the first few pages in the PDF before feeling bored.
I recently was looking for Java based open sourced wiki software for intranets. And I read about this software called LifeRay. To most people on these forums, LifeRay is not particularly interesting (based on searching HN for LifeRay related submissions and seeing how many comments a submission gets). The market size for LifeRay might be quite large, I don't know, but it is just not the kind of tech that people are excited enough to comment about. For example, I am fairly sure no one is going to go and read about LifeRay just because they read this blurb.
There are many different reasons for the lack of excitement as I am sure you can imagine. But the echo chamber is not the cause of the lack of discussion. Some topics are not just interesting enough, and probably never will be.
The link i gave is to a report. It's boring. But it's comprehensive and lists all the platforms and a good starting point, because someone asked about that.
But the issue itself is more interesting: first - it's a big and relatively common software design problem(for example see how often visual "coding" is discussed) - how to enable common people to build complex systems. So what are the approaches being tried ? How are the better/different/worse/etc ? what could we learn from them ?
Second - what does it mean to the software engineering profession ? to freelancers ?
Third - what are the implications to entrepreneurs ? what kind of new opportunities does this open ? could this make large corporations agile enough to make it hard for startups ? what are good strategies ?
On the other hand, often you see here discussed some toy programming language that someone made(which is a cool project), but the improvements are quite small, the implications are quite small, and the major reason people find it so interesting is the bubble.
Thank you for reminding me of this. I used to tell coworkers these same types of things to remind them to keep things simple, especially since we generally don't pay well enough and struggle to attract top talent. But we've managed to hire so many good devs in the last few years I've started to forget...
But a lot of what you describe is what most people here would describe as basic competence. We're not talking about something like continuously deploying to multiple regions with architectures that permit high scalability, availability, yadda yadda. We're taking about the ability to create a simple back-end that won't lose customer data (because it has tested backups), obeyed 80/20 rules on cybersecurity, and are reasonably maintainable (code isn't suffocating under centuries of tech debt).
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.
I used to be a tech lead/PM on teams where we came in as an outsider and delivered code where the organization itself couldn't.
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've worked with people who could be classed as almost a 10x programmer.
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.
The argument in the above post would not classify those as 10x programmers. antirez is claiming that high quality design and a commitment to simplicity is a big part of what makes some programmers do much more productive.
Oh I agree with the article. Whenever I lead a project I argue that the team should aspire to follow "lowest common denominator" principles. By that I mean they should work in a way that appreciates the abilities of the least skilled on the team or in a manner that would allow someone coming in off the street to get up and running with the project without needing any help from existing developers. That doesn't mean over simplistic code, it just means good simple design, lots of comments and docs and asking around for permission before implementing an obscure or exotic design pattern.
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.
Oh I agree with the article. Whenever I lead a project I argue that the team should aspire to follow "lowest common denominator" principles. By that I mean they should work in a way that appreciates the abilities of the least skilled on the team or in a manner that would allow someone coming in off the street to get up and running with the project without needing any help from existing developers. That doesn't mean over simplistic code, it just means good simple design, lots of comments and docs and asking around for permission before implementing an obscure or exotic design pattern.
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've worked with some too and they've always needed another 10 junior engineers to clean-up and thoroughly test their code later on. In some big corps, that might not be such a bad thing. If it weren't for them, most projects would be stuck in so called "design-meetings" forever.
The worst part of working with people like that is that they are usually rewarded, while the rest of us are criticised for not being able to keep up, or lack understanding.
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.
> Their code worked, but it was also incomprehensible to everyone else on the team.
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.
That is a big part of it. Unfortunately when the department manager looks at lines of code as a measure of productivity, guess who gets a pat on the back....
Do they develop a "very personalized workflow", or do they simply use abstractions and techniques that go beyond hashmaps?
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 programming community is extremely polarized about the existence or not of such a beast
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.
Not many people would take issue with the statement that Shakespeare was 10x better / more effective than the average playwright. If you consider that both are creative processes there seems no reason to reject the idea that a programmer could be 10x more effective than his peers.
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.
If publishers decided they were only going to publish Shakespeares, I imagine a multitude of authors would squander a great deal of ink over it, and we'd all be worse off for the cumulative waste of talent.
As now you need 10 times more developers to maintain the over-engineered Docker, Consul, ELK [...] stack while the 10x developer finds another victim to play resume-SEO?
Taking myself as a 0.5x programmer, I have sadly encountered some 0.01x programmers. In fact it might be better to characterize them as -0.01x programmers, who I believe can work indefinitely without ever producing a working piece of software. Usually the best indicator of this is when the initial snaglist for a piece of work grows after the snags have been "completed". Then each round of fixes becomes a kind of Hydra and finally we have to give up cutting off heads and start over.
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.
I've also seen negative impact developers. If they did not code, we'd be closer to the finish line than if they did not.
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).
Failing project: the tests were the impediment (too broken and costly to refactor, every change would cost more in unit test fixing than actual implementation).
> I've also seen negative impact developers. If they did not code, we'd be closer to the finish line than if they did not.
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!
We had a guy coming into every meeting demanding we produced some low-level internal document for him. We tried to explain to him that (A) our project was not related to his project and (B) we were not comfortable giving anyone an internal implementation document of something that was highly agile.
So this went on for a year and by then the managers were really pissed off that we didn't have the "proper documentation" in place. We spent the next year creating a stable internal API and writing the documents he wanted.
What I learned from all this was that the only way to fix a -10x guy is to fire him. Because despite all this we spent the third year defending internal design decisions from a guy who wasn't even part of the team. In the end he was fired for failing to deliver in his own project - by which time our productivity doubled.
Yes. If you add two -2x programmers to the project, you decrease its productivity by 4 programmers. You don't multiply it by 4.
I started my professional career in a project where the previous developer had been given incentives per lines of code produced. Her approach was to do
This was on a 8-bit microcontroller with 64k program memory. And, surprise surprise, I, a humble CS student, was given a task to "implement software to control our new HW with memory paging mechanism, so that the software, which is larger than 64k, can be put on a 128k EEPROM, and then add a network management interface".
Well, having taken a look at the code we didn't have to do any paging; soon after deploying a print function we could put everything on one 64k page and the other 64k of program memory was just sitting empty.
I absolutely loved this article. Don't get hung up on the "10x", read it as "good". All the characteristics Salvatore describes are the characteristics of every good developer I know, and that every developer should strive for.
They make you a better artisan, but also increase your productivity. Who cares if it's 10x, 100x or 2.5x? The important bit is growing to your personal full potential.
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.
- 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.
The whole 10x programmer thing is just interpreted wrong. The original statement was that the best are 10 times better than the worst.
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.
Provided your business will never need more than one and only one expert programmer who may not work in a team and this expert programmer will never leave your business and will always be trustworthy to do the right thing and they can support/maintain their own work in your production environment then a 10x programmer is a great idea.
Otherwise consider other human qualities such as communication skills, adaptability and critical thinking as more valuable than raw coding skill.
I think the point is that the 10x programmer has those other skills. That is the differentiating factor. It's not about typing 10x faster or generating 10x the lines of code. It's about creating 10x the value.
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.
10X? Steve Jobs said more than once in interviews that he saw a 200X difference among professional programmers.
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.
I think the phenomenon of the 10x programmer does have analogues in physical work. I feel a big part of this is having the ambition to absorb the entire problem domain. A 10x programmer does not work on just one part of a problem, they work on the entire product, each subproblem having a solution that simply flows from the constraints of the entire system. It's this full comprehension that allows the programmer to work without costly analyzing pauses, which I bet is the root cause of the delays associated with the 'regular' programmer.
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.
In this thread: mostly people responding to the headline, not the actual content of the article.
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.
Exactly. All the arguments that have the word "productivity" are probably off. It's not about "productivity" as in "which programmer produces more code" or even "more programs" or whatever. It's about the person being able to recognize what matters, on one side, versus those that can even make such decisions to finally cause the doom of the project. I have such experiences, and some huge failures can really be caused by the disconnection on the lower levels (programmers) and the managers who can't recognize what's going on (accepting the wrong arguments of these doom-causing programmers). Some of stories like that are also in the book "In Search Of Stupidity"
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.
My favourite programming anecdote[0]. How many lines of code did you produce today? -2000. Indeed it's not about lines of code. A 10x programmer might produce a solution that would take a team of three 1x programmers twice as long to implement and is twice as 'good' (fast, compact, stable, elegant, maintainable, etc).
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.
Thanks for a hint! Reading [1], there the "programmer actually making decisions" was called a "metaprogrammer":
"the metaprogrammer was the designer, decision maker, and communication controller in a software development group.... individual progammers were allowed to make no design decisions about the project. All they did was write the code as described by the metaprogrammer."
In that case, the differences between programmers can't be too big and surely matter little. It's the "metaprogrammers" that are important and influence the faith of the project. And those that Jobs praised were, by that definition, surely "metaprogrammers" who also did the tasks of "programmers."
The meta programmer model is very different though. How the programmers implement their code is not addressed. Fast? Compact? Memory efficient? Maintainable? Doesn't matter, perhaps as long as the code meets some pre-determined criteria.
In the metaprogrammer model, as far as I understand, the programmers don't even decide "how the programmers implement their code," that's what the metaprogrammer decides: if what they produced is acceptable and according to his exact instructions or is to be rejected. So they don't decide: "Fast? Compact? Memory efficient? Maintainable?" they do it exactly the way the metaprogrammer said.
What I wanted to point is that as soon as we define that the programmer doesn't decide, we have a system where the "quality" of the programmer doesn't matter much as the programmers by that definition do more-or-less a mechanical task.
However that "metaprogrammer" term is probably not so common.
How are metaprogrammers called otherwise? What are their job titles?
> However that "metaprogrammer" term is probably not so common. How are metaprogrammers called otherwise? What are their job titles?
In places that use this approach the people filling that role are sometimes called Architects, Principal Engineers, and sometimes Product Managers or Technical Product Managers.
I'm sorry, for the kind of things I tend to blog about, monospace font was the simplest way to have a truly what-I-write-is-what-appears without using any markup. If I could start from scratch I would use MarkDown, however at this point if I switch all the past blog posts will be broken, or I should switch conditionally from a post ID >= but then the blog will be a bit inconsistent. I'll try to figure out a solution.
You could make it so new posts have markdown, but your old ones are untouched?
Honestly, your site is probably the very hard to read, but some of the problems it has are just omissions on your part If you want to see how to make monospaced fonts readable in bulk, pattern your layouts after phrack.
Personally it wasn't the font for me but the way it wraps. I have some annoying vision issues that pop up from time to time. My solution is to use Safari reading mode on iOS, but that made it worse in this case.
The site's layout and typography is actively hostile to readers in general, mobile or no. The choice of a monospaced font in spite of all readability, the letter spacing, the lack of headings, list marking or indentation, the extremely wide lines...
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.
one million time this. as the resident tech lead I spend more time trying to get people focus on things that matters than actually designing and documenting
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.
> 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.
Wouldn't an even simpler solution be to just use the scrolling built into browsers?
If you need smooth scroll you can't rely on browser support and need to use a library or cook something up yourself. It's surprising how few browsers work with smooth scroll. Today it's basically only Firefox; not even Chrome.
Not to be a fanboy but I use a Mac and one of the things that they clearly did a huge amount of research and fine tuning on is the scrolling. I can always tell when there's non native scrolling on a site and it always sucks. Maybe I'm out of touch, but IMO the smoothness of the scrolling is an OS or hardware level feature. If somebody's OS or hardware does not scroll smoothly, then clearly it's something that they're used to from every other site they visit.
Putting a "smooth scrolling" library in makes about as much sense as rendering all of your site's text on canvas because some computers have font aliasing issues. It reeks of a micromanaging CEO getting fixated on some arbitrary requirement that makes stuff look better only on his computer.
I'm not talking about manually implementing a virtual scrollable canvas. I'm talking about "make item 19 in that list box visible in the middle of It's display area."
I agree that scrolling virtual spaces should be native and hardware accelerated whenever possible, but I think we are talking about different use cases.
Imagine there's a scrollable list of items and you want to scroll one particular item into view when some event happens. Without smooth scroll the item just pops into view and the user may not see it happening. It's a usability issue-- when the user interface jerks instantly, the user can lose context about what's happening. When it's smoothly animated it's easier for the user to keep track of what's happening in the user interface, and to see how one interaction triggers the next.
Done right, animation isn't just snazzy, it produces a more usable, more approachable user interface. It helps the user keep a good mental model of what's going on. It's easier for them to mentally track "ah, when I select this item, it also selects that other item in the other list".
It's the same reason why when you click an app on your phone it animates up from the app icon when the window opens. The animation wordlessly tells the user "I'm opening this app, and the window that's appearing is born of the icon you just clicked." Necessary? Not exactly. More natural? Absolutely. Nothing just snaps into existence in the real world, except for maybe things like lightning.
When things appear out of nowhere it can be jarring. Animation is especially called for when it might not be intuitive why you're making a change to the visual state, or when you want to call attention to something.
Keep in mind that a generation ago, pretty much every piece of software (even games!) came with a printed manual that the user needed to read first before expecting to be able to accomplish anything. Today users expect to be able to figure things out for themselves, and animation is part of the user experience that helps users learn their applications naturally by exploring the user interface.
Exactly, and just we wait for mainstream VR/AR. I believe we'll see quite a lot of animation skeumorphism (is that a thing? I mean realistic animation/appearance relatively to a real world setting, e.g. gravity on objects, diffraction on transparency, etc). For a few years at least, time for users to learn new interaction paradigms and positioning within a virtual/hybrid environment.
This is what I use right now for cross-browser smooth scrolling. It's native first with a jQuery fallback.
<style>
html, body {
scroll-behavior: smooth;
}
</style>
<script>
// Uses native smooth scrolling if available, otherwise uses a jQuery fallback
// Just add data-scroll attribute to any anchor you want to make smooth
// Add data-scroll-header to a sticky nav / header to offset the window top
if (!('scrollBehavior' in document.documentElement.style)) {
// jQuery fallback
// Taken from https://css-tricks.com/snippets/jquery/smooth-scrolling/
$('[data-scroll]').click(function() {
if (location.pathname.replace(/^\//,'') == this.pathname.replace(/^\//,'') && location.hostname == this.hostname) {
var target = $(this.hash);
target = target.length ? target : $('[name=' + this.hash.slice(1) +']');
if (target.length) {
$('html, body').animate({
scrollTop: target.offset().top - $('[data-scroll-header]').height()
}, 600);
return false;
}
}
});
}
</script>
Because while default scroll is fine for scrolling pages whole, in any scrollable div that's not top level it looks out of place like a blacksmith on an iceberg.
It's a gray slab that looks like a tombstone riding a straight, dull rollercoaster and unless your site makes a point of having a '90s inspirational look there's no way to integrate them in a page so that it doesn't feel completely detached.
> 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.
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.
I had the same reaction as you to this post, so thank you for nicely summarizing my thoughts.
I'll just add:
To me, the main distinction is this: you must at the very least figure out the reason for the unwanted behavior. If you don't, then you really have no idea whether your quick little fix covered up something important or not.
It's one thing to investigate, find out the cause, and then say "meh, that's way too expensive/time-consuming to fix, so we'll switch libraries/3rd party code or just remove the requirement for the special scrolling". It's quite another to just say "meh, display: none, look at how productive I am !".
I've had other developers do this in front of me, and it freaks me out to no end. One sat there and told me that if he changes a month calculation to subtract a month, then the total comes out correctly. I asked him why that was and he said "Why does it matter, I'm getting the right result ?"
We all need to remember that we're not being paid to type, we're being paid to think.
In a third party library which already touches a sensitive area that shouldn't messed with in the first place? That'd be a week of two of work, easy. Means reaching a client less. No way I'm gonna chase the white rabbit in its hole to fix something that has no side effects and zero ripercussion on other components.
> ultimately we aren't paid for technical excellence but for working programs
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.
> ultimately we aren't paid for technical excellence but for working programs.
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.
ultimately we aren't paid for technical excellence but for working programs.
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 this thread: mostly people responding to the headline, not the actual content of the article.
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.
Another great thing here: "Design sacrifice: killing 5% to get 90%."
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.
Perfect is the enemy of good enough. If you never ship a "perfect" product, it has 0 value.
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.
I had a similar experience while trying to devise an algorithm to fill up n spots having n-1 soldiers available in the military. So after losing few hours, not being able to come up with any combination that satisfied all conditions I run to the sergeant, explained the problem and he just erased a spot for 24h, changing spec. Suddenly everything fell in to place.
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).
I think you'll like George Pólya's How To Solve It. That's one of the methods he prescribed on solving a difficult problem; by gently removing the most difficult part and look at it again.
Check "The Art of Unix Programming" by Eric Raymond. It's full of exciting stories from computing pioneers epoch, and more than that, it's just filled with empowering inspiration about simplicity. To quote just one story from this book:
> One epochal example not mentioned in Gabriel's paper is from distributed hypertext systems. Early distributed-hypertext projects such as NLS and Xanadu were severely constrained by the MIT-philosophy assumption that dangling links were an unacceptable breakdown in the user interface; this constrained the systems to either browsing only a controlled, closed set of documents (such as on a single CD-ROM) or implementing various increasingly elaborate replication, caching, and indexing methods in an attempt to prevent documents from randomly disappearing. Tim Berners-Lee cut through this Gordian knot by punting the problem in classic New Jersey style. The simplicity of implementation he bought by allowing “404: Not Found” as a response was what made the World Wide Web lightweight enough to propagate and succeed.
Finding a better solution by changing the problem is great, especially as the problem stated is often not the problem faced.
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.
Interestingly this is pretty much "valuing individuals, working software, and customer interaction" - the core of the agile manifesto, but the bits that never seem to ever show up in "Agile" workplaces where way too often rigid compliance with standups, scrum meetings, and evenly sloped burndown charts (and foosball table, bean bags, and free energy drinks) are all "critical to the process", and fixed price engagements and hard deadlines are "the business reality"...
"The problem is not the problem, the problem is your attitude towards the problem." - Jack Sparrow
So many times I've seen someone struggle to implement a poorly written spec rather than just say 'hey can we just do X instead?' If X solves the REAL problem then sure you can.
> the problem stated is often not the problem faced.
100% true! So many times I was assigned to the task in issue tracker, where requirements was written, estimation was made, but after I sat and tried to solve given problem, it turned out that 80% of issue description was false - real problem was totally different than it was written in task.
What seemed right on planning meeting, turned out to be quite false in the process.
But quite often managers/product owners etc. don't understand this. They often believe 100% in planning ahead and issue tracker/backlog descriptions... And when something is going off the track (like it sometimes does - when problem needs extra time for thinking through) they aren't so glad because thinking and design process was not budgeted in issue tracker (even if it could lead to the better design on the long run).
"great design is the key to increased productivity"
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.
I'm proud to say that I've accomplished that, at least once. My company was developing a new feature, hundreds of medical textbooks that would be searchable and readable online. The source content for each textbook consisted of a huge xml file and a bunch of images. The problem we faced was that many of our customers were government-funded libraries, and they required a physical product for anything they purchased. (We wanted to sell renewable access licenses for the online product.)
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.
Hundreds of thousands, probably, and my work on that textbook feature brought in millions in revenue. Another aspect of the project is that I wrote a custom XML content storage and retrieval database, and spending a couple of months proving that my solution was far more scalable and performant than either the Oracle-based solution or commercial XML database solution that the director of development and CTO preferred. So I saved the company a 6-7 figure annual licensing cost as well.
My reward was short-lived immunity to the corrosive political environment that the CTO and director of development had created. The director came from a competitor we had acquired for their customers (not their tech), and right from the start he was open about wanting to eliminate our development team so that his old team could be in charge. They failed due to incompetence, and he and his entire team were let go some years later. The CTO lasted longer, eventually firing my manager without cause, and I quit a few months later. The overall product we were responsible for (which the textbooks were a part of) is still running, and it is still their flagship. But very little has been done to it in the past seven years since I left. The CTO was let go a year or two after I left.
Handsomely rewarded? Hardly. That's not how it goes in big corps. Presiding over the hand-off from the team that was let go was satisfying, and knowing that my software is still running strong after many years of neglect because everyone who was capable of maintaining it quit is also somewhat rewarding.
Heh - did pretty much the same thing (not for medical textbooks) but included a title/keyword/first few hundred works text search thing as a Java applet, for this "Best viewed with Netscape 3!" was actually relevant! ;-)
At one of my first jobs, my employer had $1.2MM and 10 people budgeted full time for 2 years to build a project that would allow managers to make queries on a very large dataset.
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.
This was an excellent read. There are people who are great a design. There are people who are great at architecture. There are far fewer people who are great and making the tradeoffs needed to sacrifice part of a design or part of a "perfect" architecture when they aren't necessary to a project.
You've really got to have people who have a culture of celebrating trimming the fat at both ends to get to that.
> In this thread: mostly people responding to the headline, not the actual content of the article
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.
> 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.
In optimization, if you make an analogy between speedup / improvement with advantages / effort, you get 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."
Great article, as I'm a bit of an old hat myself I'd like to add a few extra categories -
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).
Is that really a long-term productivity boost? I wager the cost of maintaining and debugging the vomited code destroys any total productivity advantage.
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.
It's true the resulting code isn't perfect. But there are design advantages to holding the code in your head that make up for sloppiness at least that was my observation. A code review for error checking is certainly advisable and good practice to boot!
but the thing is the poor person finding bugs or adding features in the code is going to spend 2x as long. and then 2x as long the next time, and the next time... "no we can't re-write it, it's working code! just add the feature...".
If Mr. 4x had slowed down a bit and written something more structured, the overall cost would have been less, surely.
No nothing like that at least the couple I've worked with. I think you are confusing these people with "coding minds" with people that can churn out working code quickly (they are a different beast). The code produced by the 4x people is very elegant structurally because they can see how it fits together, this is the strength but it may be missing some edge cases / functionality and or validation in the first pass.
That second addition is not nearly as valuable for creating code as it is debugging it. When you see an error and can pretty much pinpoint where the problem is, just because that's the only place where that error makes sense... That's a lot of time you just cut out of the entire process.
320 comments
[ 6.2 ms ] story [ 290 ms ] thread10 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.
All I wanted to do was point out that quality matters as well, and not draw a correlation between frequency and quality.
(I do agree that 10 years sounds too extreme for a professional writer of course ^^)
Feel free to think that a novel is something one cranks out as if it's just an object that carries no meaning, requiring no sacrifice from the author. But that's an opinion, and not fact.
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.
In Peopleware, DeMarco and Lister write:
What nearly everyone who has read that remembers is the following:[1] Programming Pearls. Jon Bentley (Column 4)
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.
In short, as the saying goes: Decisiveness is overrated.[0]
[0] https://github.com/globalcitizen/taoup
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.
"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
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.
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).
It was ridiculous, and I was annoyed at the time too. Especially because I had basically laid out how to solve it just before I left that company. Somehow that didn't get communicated to him. When I went back for one day 5 months later, I learned that he was basically still nowhere (he had been doing other things too). I spent an hour with him laying out the solution in detail. From what I last heard, he listened, and that is the solution they are currently using.
> 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"?
If you only have Python experience and no intuition about how much time/memory certain problems should take, you don't necessarily know when you're out of your depth. It was a Django shop. The only exposure most of the people in that company had to the RDBM was through the Django ORM. Multiple times I have seen them do things through the ORM which would be trivial and multiple orders of magnitude faster with a couple of lines of SQL.
That data also didn't come in a database, but in a series of CSV like files. If you don't have RDBM experience, you don't necessarily see how you would use a database for this problem. And Python conveniently has a csv module that will happily parse your files into objects... If you buy into the marketing that Python is 'fast enough', and 'you can always use Pypy if it needs to be faster', you might not realise when you get stuck.
> 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?
Management didn't know how long that task was supposed to take. The technical competence in that company was very limited, and they were used to deadlines slipping all the time.
> I'm self-aware enough to search for a solution and RTFM for the tools at hand.
That puts you ahead of the pack, in my experience. I had almost no experience with RDBMs before I joined that company, but reading the first 100 pages of the PostgreSQL manual the first week put me ahead of people who had been using PostgreSQL as their principal tool for more than a year (a different team, the metrics team which used PostgreSQL directly, not through the Django ORM). They had never heard of simple things like VIEWs and WITH queries.
> I've never encountered a team where it seemed like one person was that far off from the median
I don't think he was that far off from the median in that company, maybe just a bit below. To be fair, it was technically the worst company I've ever worked at. I was only with them for 6 months (and I never would have started there except for personal circumstances).
Consider yourself lucky never having worked at such a company. They are more common than you think.
* 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 ;)
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...
They were, as individuals, very productive, but they suppressed the productivity of the rest of the team.
2.) History: was assigned tasks or project multiple people failed previously and was first to succeed.
3.) Tasks and projects assigned to him/her move with reasonable speed, does not need handholding. When other people take over, they don't complain all that much and are able to continue without encountering major wtgs.
I guess it was to show me that I was thinking too much like a C programmer, he rewrote my program in about 10 lines of Perl.
He was always willing to listen when I had design ideas that differed from his own. When my ideas were better, he'd incorporate them into our plans.
We had a four man team that was probably the most productive one of which I have ever been a member.
This is what makes someone a good Tech Lead and/or manager.
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.
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...
Of course it was not. If you are antirez, you will mostly work with people on projects which, by nature, will involve talented programmers.
> Improving how the team works together / how work flows through the system probably has a bigger impact than raw programmer output
But only a person good enough can do that. This is catch-22
> Improving the quality of your software (minimizing defects and rework) will improve the output of everyone in the team
Yes, but it requires a really good dev to create and execute a plan to progressively enhance it. Instead of doing another from scratch which will also fail.
> I have heard of cases where removing the "top programmer" from a team made the whole team more productive
Yeah I heard of people stopping vegetables and living fine as well. And "top programmer" <=> "top dev". You can be very good at software and terrible with people.
My point is, the entire article is build on assumptions from the "top programmer" perspective.
All that goes to the water when your team is composed of:
- a senor waiting for retirement
- an apprentice fresh out of a community college
- a new dad who needs money and hates his job
- a legacy spaghetti code project coded by 3 different teams 10 years ago
- and no 10x programmer to be found
It will work. But say goodbye to best practices, and all the rules Antirez is stating.
"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.
..., frustrating them, leaking their data, and wasting their time.
And a lot of businesses do so while providing terrible services or products. Plus people working for them have their own agendas : family, play, not get blamed, etc and won't do anything about it.
It's not specific to software. How many of you have experienced :
- a completely broken by design shower
- those "easy to open" packages that are impossible to open
- kitchen ware taking centuries to wash because obviously nobody designing them never bother to use them
- laptop with horrible sound
- shoes that destroy you feet after 2 hours of using them
?
Doing your job well is the exception, not the rule.
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.
*old song, according to Youtube comments is every song recorded before 2016 AD.
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.
And you are on HN.
And you did live in the real word where people are not 10x.
:)
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.
For the IOT, i believe thingworx is the leader.
I recently was looking for Java based open sourced wiki software for intranets. And I read about this software called LifeRay. To most people on these forums, LifeRay is not particularly interesting (based on searching HN for LifeRay related submissions and seeing how many comments a submission gets). The market size for LifeRay might be quite large, I don't know, but it is just not the kind of tech that people are excited enough to comment about. For example, I am fairly sure no one is going to go and read about LifeRay just because they read this blurb.
There are many different reasons for the lack of excitement as I am sure you can imagine. But the echo chamber is not the cause of the lack of discussion. Some topics are not just interesting enough, and probably never will be.
But the issue itself is more interesting: first - it's a big and relatively common software design problem(for example see how often visual "coding" is discussed) - how to enable common people to build complex systems. So what are the approaches being tried ? How are the better/different/worse/etc ? what could we learn from them ?
Second - what does it mean to the software engineering profession ? to freelancers ?
Third - what are the implications to entrepreneurs ? what kind of new opportunities does this open ? could this make large corporations agile enough to make it hard for startups ? what are good strategies ?
On the other hand, often you see here discussed some toy programming language that someone made(which is a cool project), but the improvements are quite small, the implications are quite small, and the major reason people find it so interesting is the bubble.
What kind of dev do you suppose know what you listed? A 1.5X, 2X, or 5X programmer? Surely not a 10X/Free Electron.
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.
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.
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.
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.
The kind of developer you describe literally almost the complete opposite of what antirez was talking about!
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.
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.
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.
https://www.facebook.com/notes/kent-beck/mastering-programmi...
In fact, the management are often the last people to notice if someone in their company is a 10x guy.
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...
[2]https://en.wikipedia.org/wiki/Standard_deviation
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 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!
We had a guy coming into every meeting demanding we produced some low-level internal document for him. We tried to explain to him that (A) our project was not related to his project and (B) we were not comfortable giving anyone an internal implementation document of something that was highly agile.
So this went on for a year and by then the managers were really pissed off that we didn't have the "proper documentation" in place. We spent the next year creating a stable internal API and writing the documents he wanted.
What I learned from all this was that the only way to fix a -10x guy is to fire him. Because despite all this we spent the third year defending internal design decisions from a guy who wasn't even part of the team. In the end he was fired for failing to deliver in his own project - by which time our productivity doubled.
I started my professional career in a project where the previous developer had been given incentives per lines of code produced. Her approach was to do
instead of having a print function and saying This was on a 8-bit microcontroller with 64k program memory. And, surprise surprise, I, a humble CS student, was given a task to "implement software to control our new HW with memory paging mechanism, so that the software, which is larger than 64k, can be put on a 128k EEPROM, and then add a network management interface".Well, having taken a look at the code we didn't have to do any paging; soon after deploying a print function we could put everything on one 64k page and the other 64k of program memory was just sitting empty.
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 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.
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.
- 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.
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.
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.
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.
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.
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.
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...
"the metaprogrammer was the designer, decision maker, and communication controller in a software development group.... individual progammers were allowed to make no design decisions about the project. All they did was write the code as described by the metaprogrammer."
In that case, the differences between programmers can't be too big and surely matter little. It's the "metaprogrammers" that are important and influence the faith of the project. And those that Jobs praised were, by that definition, surely "metaprogrammers" who also did the tasks of "programmers."
What I wanted to point is that as soon as we define that the programmer doesn't decide, we have a system where the "quality" of the programmer doesn't matter much as the programmers by that definition do more-or-less a mechanical task.
However that "metaprogrammer" term is probably not so common. How are metaprogrammers called otherwise? What are their job titles?
In places that use this approach the people filling that role are sometimes called Architects, Principal Engineers, and sometimes Product Managers or Technical Product Managers.
-10x for readability.
Honestly, your site is probably the very hard to read, but some of the problems it has are just omissions on your part If you want to see how to make monospaced fonts readable in bulk, pattern your layouts after phrack.
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.
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.
Wouldn't an even simpler solution be to just use the scrolling built into browsers?
Putting a "smooth scrolling" library in makes about as much sense as rendering all of your site's text on canvas because some computers have font aliasing issues. It reeks of a micromanaging CEO getting fixated on some arbitrary requirement that makes stuff look better only on his computer.
I agree that scrolling virtual spaces should be native and hardware accelerated whenever possible, but I think we are talking about different use cases.
Looking cool at the request of some manager does not constitute a need.
Done right, animation isn't just snazzy, it produces a more usable, more approachable user interface. It helps the user keep a good mental model of what's going on. It's easier for them to mentally track "ah, when I select this item, it also selects that other item in the other list".
It's the same reason why when you click an app on your phone it animates up from the app icon when the window opens. The animation wordlessly tells the user "I'm opening this app, and the window that's appearing is born of the icon you just clicked." Necessary? Not exactly. More natural? Absolutely. Nothing just snaps into existence in the real world, except for maybe things like lightning.
When things appear out of nowhere it can be jarring. Animation is especially called for when it might not be intuitive why you're making a change to the visual state, or when you want to call attention to something.
Keep in mind that a generation ago, pretty much every piece of software (even games!) came with a printed manual that the user needed to read first before expecting to be able to accomplish anything. Today users expect to be able to figure things out for themselves, and animation is part of the user experience that helps users learn their applications naturally by exploring the user interface.
Why would I need smooth scroll? All it achieves is slows down the scrolling so it takes me longer to get to where i want to in the page.
It's a gray slab that looks like a tombstone riding a straight, dull rollercoaster and unless your site makes a point of having a '90s inspirational look there's no way to integrate them in a page so that it doesn't feel completely detached.
I am always looking for excuses to get rid of stuff.
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.
I'll just add:
To me, the main distinction is this: you must at the very least figure out the reason for the unwanted behavior. If you don't, then you really have no idea whether your quick little fix covered up something important or not.
It's one thing to investigate, find out the cause, and then say "meh, that's way too expensive/time-consuming to fix, so we'll switch libraries/3rd party code or just remove the requirement for the special scrolling". It's quite another to just say "meh, display: none, look at how productive I am !".
I've had other developers do this in front of me, and it freaks me out to no end. One sat there and told me that if he changes a month calculation to subtract a month, then the total comes out correctly. I asked him why that was and he said "Why does it matter, I'm getting the right result ?"
We all need to remember that we're not being paid to type, we're being paid to think.
https://en.wikipedia.org/wiki/Wikipedia:Chesterton's_fence
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.
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.
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.
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.
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).
[1] https://www.wikiwand.com/en/Gordian_Knot
> One epochal example not mentioned in Gabriel's paper is from distributed hypertext systems. Early distributed-hypertext projects such as NLS and Xanadu were severely constrained by the MIT-philosophy assumption that dangling links were an unacceptable breakdown in the user interface; this constrained the systems to either browsing only a controlled, closed set of documents (such as on a single CD-ROM) or implementing various increasingly elaborate replication, caching, and indexing methods in an attempt to prevent documents from randomly disappearing. Tim Berners-Lee cut through this Gordian knot by punting the problem in classic New Jersey style. The simplicity of implementation he bought by allowing “404: Not Found” as a response was what made the World Wide Web lightweight enough to propagate and succeed.
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.
Coding monkeys consider the spec the problem and try to write code that solves it.
Programmers consider the spec a part of the solution and evolve it as necessary.
So many times I've seen someone struggle to implement a poorly written spec rather than just say 'hey can we just do X instead?' If X solves the REAL problem then sure you can.
100% true! So many times I was assigned to the task in issue tracker, where requirements was written, estimation was made, but after I sat and tried to solve given problem, it turned out that 80% of issue description was false - real problem was totally different than it was written in task.
What seemed right on planning meeting, turned out to be quite false in the process.
But quite often managers/product owners etc. don't understand this. They often believe 100% in planning ahead and issue tracker/backlog descriptions... And when something is going off the track (like it sometimes does - when problem needs extra time for thinking through) they aren't so glad because thinking and design process was not budgeted in issue tracker (even if it could lead to the better design on the long run).
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.
That's exactly it.
My reward was short-lived immunity to the corrosive political environment that the CTO and director of development had created. The director came from a competitor we had acquired for their customers (not their tech), and right from the start he was open about wanting to eliminate our development team so that his old team could be in charge. They failed due to incompetence, and he and his entire team were let go some years later. The CTO lasted longer, eventually firing my manager without cause, and I quit a few months later. The overall product we were responsible for (which the textbooks were a part of) is still running, and it is still their flagship. But very little has been done to it in the past seven years since I left. The CTO was let go a year or two after I left.
Handsomely rewarded? Hardly. That's not how it goes in big corps. Presiding over the hand-off from the team that was let go was satisfying, and knowing that my software is still running strong after many years of neglect because everyone who was capable of maintaining it quit is also somewhat rewarding.
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.
I hope you ended up seeing some of that $1.2M, yet somehow I doubt it.
You've really got to have people who have a culture of celebrating trimming the fat at both ends to get to that.
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.
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."
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.
If Mr. 4x had slowed down a bit and written something more structured, the overall cost would have been less, surely.
The point is they are able to in their head: compose the program, notice bugs, fix those bugs, possibly tweaking the design in the process.
Basically, they can prefect the design in their head and fix a lot of bugs all before starting type.
Sorry, doesn't fit in a two week sprint.