Hacker News new | ask | show | jobs
by twoodfin 4571 days ago
I'd add the Doomsayer: The programmer who is constantly pointing out the ways in which any design could fail, no matter how likely or relevant to the task at hand such failure scenarios might be.

Healthy skepticism is beneficial, but I've seen teams paralyzed because one member has perfected the technique of raising unanswerable or irrelevant objections, often seemingly to present the appearance of being the smartest guy in the room.

8 comments

You can usually turn these people into productive versions of themselves:

First, teach them how to do informed estimates for the probabilities of these negative factors coming into play.

Then, ask them to point out the probability-estimate below which they won't even bother to bring something up.

Finally, explain that your bar for this is higher than theirs, and request that they only bring things up if they meet your higher bar; for things that meet their bar but not yours, you'll just be discarding what they say anyway, so they'll just be wasting their breath.

I'm always torn about this one. As a manager, I hate this guy. They can completely undermine a team's motivation.

As someone who's been in this business for 30 years I've come to recognize that "unlikely failures" is just a synonym for "pretty sure it's going to happen at some point".

Also, there are way too many programmers around that are the exact opposite, and don't see any of the obvious ways in which a design will fail, so I tend to be kind of protective of those that do.

Haha, I call them "Cassandra" usally. :)

I like working with them and having at least one on the team, because they're a great addition to the "naive optimist" or the "carefree hacker-fixer" who always see the solution around the corner - in a couple of minutes of course. ;)

And: There's a lot of tech scenarios where being overly careful and actually seeing the impending technical doom in every corner is an advantage.

Similar to the pedantry you get by the human robot, Cassandras have their place - and good management and coworkers know exactly where and how to take them.

Oh wow. A few names immediately came to mind as I read this.

I remember the first time I encountered this, and thinking the guy had to be on crack.

His quote: "A changed comment in code could possibly cause a problem, if the file were to become corrupted as its uploaded"

Maybe I'm just That Guy, and maybe your example is from a non-critical system, but if you are dealing with a highly available mission critical system, any change carries a risk, even the act of deployment.

The tension probably arises from disagreement over what is critical.

I wonder if I am one of these people. I have been trained by now-countless instances of things happening that I was told would never happen. I'm not "what-if-a-SHA1-collision-is-found" though.
These guys drive me nuts, but they are sometimes useful for identifying worst case scenarios that no one in their right mind would think of, but sometimes should.
I like these guys - they are totally unfit for programmers but make awesome admins.
So true. The guy that is currently driving me nuts this way is a former sys admin who is now doing programming.
Oh yes I so agree! These guys are a key mechanism for how a simple program that used to read a csv file ended up depending on a multi-site replicated database managed by an external team of DBAs, burdened with a 6 month release cycle. Rallying cry: "but that's not fault tolerant!"
"But what if a meteor shower hits both of our US datacenters simultaneously?!"
Technically meteors are small objects that do not impact the earth (the ones that do are called meteorites), and meteor showers are completely harmless to both people and datacenters.
What if the entire staff at both data centers are so captivated by the shower that they ignore a real disaster? ;)
What I meant was asteroids simultaneously destroying both data centers :(