A fake doctor or accountant is a scandal. A fake programmer is business as usual.
On the elitist over/under-tone stuff: I should have been clearer. I think PM roles, documentation roles, testing roles, etc are all extremely important. However, I don't think these are roles where you should stash incompetent and dishonest pseudo-developers; I think the odds are pretty good that someone who fakes their way through being a developer isn't going to be that good at anything else.
I generally agree with your points, but people don't die or go to jail because of bad code. With a few exceptions. And in those exceptions there are additional checks (checklists upon checklists, rigorous testing gauntlets) to prevent buggy code from causing safety issues.
Technically underqualified people typically result in missed deadlines and/or poor project velocity. That can be catastrophic for a business model, but it doesn't directly result in any kids growing up without a parent.
> Bookout and Schwarz v. Toyota emanated from a September 2007 UA event that caused a fatal crash. Jean Bookout and her friend and passenger Barbara Schwarz were exiting Interstate Highway 69 in Oklahoma, when she lost throttle control of her 2005 Camry. When the service brakes would not stop her speeding sedan, she threw the parking brake, leaving a 150-foot skid mark from right rear tire, and a 25-foot skid mark from the left. The Camry, however, continued speeding down the ramp and across the road at the bottom, crashing into an embankment. Schwarz died of her injuries; Bookout spent five months recovering from head and back injuries.
It's not just spacecraft that kill people due to crappy code. Even something as mundane as a _Camry_ can be fatal if the software team isn't diligent about their work.
http://www.safetyresearch.net/blog/articles/toyota-unintende...
And I wouldn't call safety critical software that can kill people "mundane". It's a minority of code out there and it tends to be really thoroughly vetted, in my experience. I can't comment on Toyota's quality assurance, though.
In 1999, when the US was engaging in a bombing campaign in Serbia against "military targets" that were staffed by civilians, the US bombed the Chinese Embassy, killing several and injuring dozens of civilians.
The US later "apologizied" by saying "sorry, we programmed the coordinates improperly."
Now, I'm not sure if that means some CIA intern college kid task monkey supplied the wrong coordinates to the bomb programmer, or if the bomb programmer typed the (correct) coordinates improperly.
But, software absolutely does kill people when wielded by lazy, incompetent, and often, diploma-holding programmers.
https://en.m.wikipedia.org/wiki/United_States_bombing_of_the...
The pilots themselves can't even enter the coordinates. These planes were programmed by the CIA.
Especially in 1999 and especially with legacy systems, the word "programming" means "providing computers with coded instructions for the automatic performance of a task".
This is similar to how a television network would "program" a list of shows to occur in order automatically.
I suppose my overriding point here is that there are credentialed people with smart sounding degrees whose maximum extent of interacting with computers is typing in instructions.
And therefore, we should be extremely wary when we use credentialing as the litmus test for "should they enter bomb coordinates that will be flying over civilian heads"
Meh. Hiring is expecting other people to train your employees for you.
It's important to hire smart, driven, forthright people, but if you really want them to, say, write readable code, assign them to read Clean Code, make code clarity part of the regular performance review, add it to the code review checklist, etc.
In my opinion, bigger than hiring practices is a lack of communication up and down the chain of command about the importance of good code, who is writing it, and what are the carrots and sticks involved in making sure good code happens. Most people able to hand out raises and job titles work off secondhand and hand-wavy information about technical prowess at best:
"Yeah, he's really good. Fixes lots of bugs and get asked for help a lot."
Of course, that could be because the code's a big mess and he wrote himself some excellent job security. A non-technical PM would know little about this very common issue.
The next company I worked at was very serious about quality. When I started working there, I was told that I was allowed one bug in my code. If there were a second one, I would be fired. I'm not sure if that was true as my code didn't have any (found) bugs. It was thoroughly inspected by two senior engineers before I could even run it on the test bench. We were some months behind schedule but there was not one word about reducing the quality to catch up.
The first company made communications equipment, the second one an air traffic control system.
I've had lines of code go through walk-throughs, inspections, paired programming, the works, and still end up failing somewhere down the line in integration testing.
During the work day, you'd join is in Slack for 8 hours. You'd need to ask probing questions to mock-up our infrastructure and pitch a feature based on "how we work".
One could try to cheat on the first part, but there is no chance one could have bamboozled us during the work day.
For our technical writing positions we had some instances of outright plagiarism, but no instances of anyone trying to cheat the coding sample.
That's amazing! For everybody else that shares my amazement, I found https://www.compose.com/articles/how-compose-uses-interviewe... that touches on said hiring practice, but I'd love to hear more.
"Why did you do this part this way? Would you do it differently if requirement X were different?"
It's immediately obvious if they cheated. Better yet, that's a much better, more relevant discussion than most whiteboard problems.
This isn't directly in response to your comment, but...
There's an elitist under(over?)-tone within HackerNews that asserts any less-than-engineer technical role is inferior and attracting of undesirable character. There's a particular disdain for project managers, often for good reason. Few things are more aggravating than a poor non-technical PM. But, in many organizations they're essential and valuable members of a team. Skilled people can have an immense degree of technical talent and no interest in programming or engineering culture.