[dukodk]

Seems like a low risk test, it’s kinda a no-brainer. They used their free time and they had it running alongside the main program. Have to remember if they didn’t have the comparison, I don’t think it would be as good a story.

“Nobody Ever Gets Credit for Fixing Problems That Never Happened”

[wccrawford]

“Nobody Ever Gets Credit for Fixing Problems That Never Happened”

While I agree...

The first few years at my current company, they kept telling me I did really good work, but I was too slow.

Then we had a security breach, and then an audit. My code was the only code that they found no vulnerabilities in, and most of the rest of the code was riddled with them. (TBF, there have been security vulnerabilities in my code, they just didn't find them in that audit. I'm not perfect.)

Since then, they have never complained about me being slow.

While that's not credit for fixing problems that didn't happen, I think it's the closest thing out there.

[jon-wood]

I have a slightly different interpretation of this, and it comes down to the horrible manager-ese phrase "risk appetite".

As a small scrappy startup shipping is the absolute priority - get something out in front of customers, because the existential risk to the company is that you run out of money before you've got either a sustainable income or investment. Security might get some lip service paid, but ultimately who cares if your code is insecure when there's no customers who's data is at risk yet.

Over time the company will (hopefully) grow its customer base. Maybe you get some big B2B contract to fulfil. That's the point at which things like security audits land, and people start having to really care about security, because now there's half a million people in your databases, and if they get compromised you're going to be front page news.

You need different kinds of people as a company grows. The scrappy "get it shipped" engineers of the early days are going to find it increasingly difficult to function in a larger process focused organisation because its no longer just a case of sitting down over lunch to hash out a new feature before hacking something together in the afternoon. Process means that's now a multi-week process involving three different departments, followed by a month of waiting until the necessary people are available to actually build it.

I don't really have any good answers to that. I suspect small skunkworks like teams are probably a good first step to being able to retain those early engineers into the later stages of a company, but I've never had the chance to try it.

[wccrawford]

I don't disagree about the company's needs changing, but they'd already recognized that need when they hired me. But they didn't actually recognize how well I was fulfilling those needs until the audit.