Hacker News Reader

Comment by goodroot | Hacker News Reader

The solution is effective hiring. Work sample or project based hiring methods get people to demonstrate their skill-sets. I once had a candidate refer to resume/conversation based hiring as 'ritualized lying'. I think that's bang on.

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.

View on HN

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.

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

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

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

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.

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"

> The solution is effective hiring.

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.

TBQH, Management does not care about clean code so much as getting a project out by the deadline however unrealistic it may be. Clean code is very low on their list of priorities. Even among managers who used to be engineers it's very low on the list of priorities. They say they care about it. That's not the reality though.

It depends on the company. One place I worked at instituted a bonus system with the result that programs were released on time, buggy or not, as releasing them late would have reduced the managers' bonuses. I raised a stink about that by repeatedly saying "We really must inspect the code before the product ships." I was sidelined and let go early when the company shrank to a shadow of its former self, infested by people who were more interested in furthering their career than doing the job.

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 can understand a strong emphasis on quality for an air traffic control system and am glad that there was more weight put on getting out quality code than meeting a deadline (especially with some companies interpretations of DevOps/CI/CD). I'm curious what sort of defect penetration did you get once you got to the test bench?

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.

Is the work sample done in person or take home? If it's take home, then they can just cheat on that by hiring someone else to do it.

At Compose (YC, S11) we had a two part hiring method. The first was a blind work-sample. You had unlimited time to complete it. Identifying information was obfuscated and graders would yes/no objective criteria. The best samples proceeded to the "work day".

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.

> During the work day, you'd join is in Slack for 8 hours.

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.

Just out of curiosity, how many people applied vs. made it through the blind work-sample vs. the work day? I think this is a great system, but I'm not sure I could keep a team of engineers actively engaged in answering infrastructure questions while at the same time trying to get their own work done. Was that an issue?

Are you still working at Compose? I'm curious how the IBM mandate of all remote workers going back to an office every day has affected Compose.

How much did you pay people for the two days worth of work?

The trick is to then talk through the code with them in the next interview.

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

Reply on news.ycombinator.com