Updated: Apr 7, 2019
I built a successful career thanks to the incompetence of others. Earning my first stripes in software quality assurance by tracking down mismanaged pointers, boundary condition violations, poor or nonexistent memory management and such, managers began turning to me to track down software defects none of their high-powered developers could accomplish on their own. At first I thought it was because the software problems they were tackling (e.g. raw telemetry collection, conversion and data post processing) were so complex they simply could not manage all of the loose ends of the software they churned out at breakneck speeds management and marketing always demanded. But gradually it became obvious the majority of software developers were just downright incompetent. Hell, most of them didn't even know how to run debuggers on single-process, synchronous-transaction code, much less multi-process asynchronous-transaction code. Upon discovering this and eventually being assigned as team lead of software development groups where I had to do performance reviews and decide whether or not someone deserved a raise in salary, I was shocked to see what companies were paying some of these inept bozos to write such crappy code.
Management loved me but software developers hated me, for the most part, never convinced that their code could be so defective until I sat down with them and showed them in a debugger precisely when, where, how and why their code so obviously crapped out. As my QA experience and skills expanded, management wanted me to increase my own productivity so I began working on test automation. Fortunately, greater minds than mine had already been at work on this approach and I began utilizing excellent software testing automation tools to keep up with the never ending flow of sloppy code being churned out (thank you PARASOFT!) and use of those tools elevated my status as a top QA specialist.
Settling into the QA niche as I moved from company to company, the story was the same in each and every job assignment. At first I howled about it, a lot, to management, urging them to seek more highly skilled developers. These pleas landed on deaf ears more often than not, and in the end running QA to force teams of low-skilled developers to clean up their sloppy code always improved the bottom line and I always became a hero in the eyes of management if not those of the software development teams I worked with. So much so that I was eventually placed in charge of software development project management and the projects I managed were invariably a success, sometimes to great surprise of all involved (e.g. my final software project product as an employee for the State of New Mexico's Office of the State Engineer IT department released in 2003 was the last successful software development project that agency has turned out since then. All others, costing millions in taxpayer funds, have failed, and I expect that trend will continue for decades). But then, failed software development projects in government agencies is the norm, not the exception.
I don't know how it is these days in the commercial world, wondering what it's like in software dev groups at the big tech giant's like Apple, Google, etc. I like to think the majority of slop coders of old have been eliminated from the workforce. Then I run into a bug in an app that seems so damned obviously in need of attention and hope someone out there working on that app's QA is at least building their career upon the incompetence of others as I was able to.