Hacker News Reader

Comment by glangdale | Hacker News Reader

The whole "effective hiring" answer doesn't scale. I am absolutely appalled at the idea that I would have to do a 'fizzbuzz' test for a purportedly senior developer listing 'strong C/C++ skills', for example. However, that's the reality we face, and part of that reality comes from having people be comfortable with lying their way into our "profession" and us not be completely aghast when it happens.

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.

View on HN

> A fake doctor or accountant is a scandal. A fake programmer is business as usual.

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.

As a foil to your claim that people don't die from bad code:

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...

Pretty sure operational missile targeting isn't done by programmers.

Do you think a typographer can enter coordinates into a system from the late 80s?

The pilots themselves can't even enter the coordinates. These planes were programmed by the CIA.

I believe they are entered by authorized service officers using methods typical in other industrial data entry applications (e.g. serial console). Entering waypoints and target coordinates has nothing to do with computer programming. Just like when you bum an extra trailing zero in your Excel spreadhseet it's not a programming error.

While I can agree with you that entering waypoints is not quite analogous to software engineering, I think we are arguing over semantics.

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"

One of the problems with GPS designators was when you changed batteries it reset to your current location which has lead to more than one blue on blue

Wow, that's brutal. I wonder if those American lives are considered collateral damage too to those pushing for war

Yes it was a bug in the embedded software as I recall - the testing did not make it squaddie proof.

> After reviewing Toyota’s software engineering process and the source code for the 2005 Toyota Camry, both concluded that the system was defective and dangerous, riddled with bugs and gaps in its failsafes that led to the root cause of the crash.

> 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...

I was thinking of car control systems, among other things, when I mentioned "exceptions". If this sort of catastrophe happens, there are bigger issues than technically underqualified people making it past technical interviews.

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.

Reply on news.ycombinator.com