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".
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.
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.
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.
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.
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.
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.
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.
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...
> 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.
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 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.
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.
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.
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.
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.
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).
* 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 ;)