One of the things it has taken me the longest to understand in my career is that you can build incredible things with sufficient effort, even if everything at every level is done half-assed.
You can, but those "incredible things" have a shit lifespan and they die at unpredictable times, and it costs enormous amounts of money to fix or replace them (in part, because business requirements devolve into the "make it work exactly like the old system" style of project that makes good hackers leave and consultants ask for $50,000-per-week budgets-- in part, because they recognize the unpleasantness of the work and need to hire a team to do it; anyone savvy is going to find a way to collect the benefits while managing rather than doing that kind of work).
Mediocre programmers generate write-only code and systems that work well on launch but start to shake shortly after, like American cars in the 1980s.
Here's another thing. You can get seriously good (1.6+) engineers to maintain Postgres or the Linux kernel, because even though the work is hard and painful (and in the OS world, often gratis) it's an opportunity to learn from excellent (2.0+) programmers who built the thing. What were their concerns, and why'd they solve the problem this way? It's a learning process. But no one good is going to maintain the complexity sprawl generated by mediocre programmers for a typical programmer salary. The market rate for a good engineer to do that kind of work is $500-1500 per hour (because there's no career benefit to the work). Pay less and you'll deal with rapid turnover and evaporative cooling (i.e. the good leave and the bad stay). Or, the typical corporate solution is to put powerless junior programmers (who are not competent enough to maintain a system that is falling apart faster than they can fix it) on that type of work, which prolongs the death spiral only slightly.
I voted you back up because I don't think it deserves the downvote, but here's the thing: mediocrity exists and it gets things done. For you and I who do not wish to tolerate mediocrity our only option is to find work environments that suit our tastes, but we're not going to stop the machine through our indignation.
Plus, even if a company rejects mediocrity in its DNA, a non-technical organization is most likely going to have structural issues that will drive out good programmers anyway. It's possible for a non-technical organization to learn to value and retain good programmers, but there are many factors that need to come together, and statistically I think the majority will never figure it out.
Finally, there's an amazing thing about code is that once it works, it can continue to work in the exact same fashion indefinitely as long as nothing changes. From experience we both know that it's much better to do things right so that you have a maintainable and flexible system that can grow with an organization, but that is not a strict requirement for code to generate value in the short to medium time frames that most companies operate. Just because code is completely unmaintainable, and the cost of comparably trivial maintenance becomes exorbitant, doesn't mean that it doesn't have real business value. We privileged alpha programmers have the luxury of avoiding jobs that have to deal with this, but it's out there and it's a huge proportion of production code (I'd wager it's the majority). In the grand scheme of things it's all good though, nothing lasts forever anyway. Bad code could be one more thing that hastens the demise of an atrophying company, or it could be quietly deleted and replaced by newer systems once it's outlived its usefulness.
there's an amazing thing about code is that once it works, it can continue to work in the exact same fashion indefinitely as long as nothing changes
No business stays the same. All systems have to change, either due to evolving business needs or because the data inside them are growing. The first means bad code getting changed, generally at incredibly high cost. The second puts stress on critical points in the bad code, generally causing unexpected and intermittent failures.
A pleasing fantasy, but a fantasy nonetheless. The world runs on software these days. Everything around you has software in it, at every level: firmware, micro-code, operating system, drivers, server, client, network, etc. And the vast majority of it was written by mediocre programmers. There's simply too much production code in the world for it to be any other way.
Yes, mediocre programmers create mediocre code, and they have a harder time maintaining that code, but they still manage. Often times they have the advantage of money, resources, and people. With enough devs and a reasonable process it is possible to "polish a turd" into something that is functional and feature rich, even if it has a great many flaws.
This is the scary realization that most devs, including myself, have a hard time accepting. The software that your bank runs on? Yeah, that was written by hundreds of devs and if you interviewed each one you would probably only recommend hiring a tiny handful. The firmware your hard disk runs on? Same deal. Also your car's EFI module, your cable modem, your DVR, etc.
I was thinking on this a bit today and I realized that we're actually a little bit better off in the software world, since good software can be copied infinitely. So well written operating system kernels, server applications, libraries, etc. can have a huge impact on the overall software landscape, regardless of how few people contributed code.
But even so, there is still far too much code out there which is the culmination of mountains of mediocrity. It is rather frightening to think about, considering that everything these days relies on software.
You're arguing that the median quality output of programmers isn't raised by good practices, good tools and good management by using examples that feature poor practices, poor tools, and poor management.
Some questions to consider:
Practices: Is the output of the median programmer raised or lowered when all code is reviewed by a senior programmer?
Tools: Is the output of the median programmer raised or lowered when the language includes memory management?
Management: Does management that insists on quality output and backs it up with time or resources raise or lower the the output of the median programmer?
I feel like I miscommunicated and we're talking past each other, so let me try to fix that.
I guess I was reflexively reacting to a certain culture that tolerates mediocrity. Yes, tools are important. Code review, source control (Git, not that Perforce monstrosity), and continuous integration are necessary. For every level of programmer, such tools are necessary, but they shouldn't be used as an excuse to keep trying to nail 100 mediocre programmers together and make them build something. It still won't work.
Modern tools should be used because even great programmers have lapses into mediocrity or even stupidity. Version control has saved my ass on multiple occasions. I would, frankly, just assume that every decent programmer is going to insist on using a version control system.
Practices: I agree with you that code review is beneficial-- necessary, even. It's not enough, sadly.
Tools: Usually, tooling wars end up involving the command-line-vs-GUI debate, so I'll address that and ignore the others for now. IDEs are a double-edged sword. Use them when they make you more productive, but if I can tell that your code was written using an IDE, that's bad on you. I like Google's read-only IDE. IDEs are indispensable for certain types of forensic work but IDE-dependence is just awful.
Management: ok, I agree with you here. Managers who insist on quality and are willing to pay for it are a godsend (and also rare).
You can, but those "incredible things" have a shit lifespan and they die at unpredictable times, and it costs enormous amounts of money to fix or replace them (in part, because business requirements devolve into the "make it work exactly like the old system" style of project that makes good hackers leave and consultants ask for $50,000-per-week budgets-- in part, because they recognize the unpleasantness of the work and need to hire a team to do it; anyone savvy is going to find a way to collect the benefits while managing rather than doing that kind of work).
Mediocre programmers generate write-only code and systems that work well on launch but start to shake shortly after, like American cars in the 1980s.
Here's another thing. You can get seriously good (1.6+) engineers to maintain Postgres or the Linux kernel, because even though the work is hard and painful (and in the OS world, often gratis) it's an opportunity to learn from excellent (2.0+) programmers who built the thing. What were their concerns, and why'd they solve the problem this way? It's a learning process. But no one good is going to maintain the complexity sprawl generated by mediocre programmers for a typical programmer salary. The market rate for a good engineer to do that kind of work is $500-1500 per hour (because there's no career benefit to the work). Pay less and you'll deal with rapid turnover and evaporative cooling (i.e. the good leave and the bad stay). Or, the typical corporate solution is to put powerless junior programmers (who are not competent enough to maintain a system that is falling apart faster than they can fix it) on that type of work, which prolongs the death spiral only slightly.