Posted on by

Override all the safeties (SIGAVDI #28)

Hello friends,

It’s been a warm week here the foothills of the Smokies. The snow is gone as quickly as it came. There are those who call Tennessee weather “unpredictable”. I like to think of it as “agile weather”.

It’s warm enough that the salamanders have come out, to the great delight of the chickens. This one was preserved from a fowl fate by a concerned child.

I’m noticing that the topic of empathy is starting to be discussed more and more and developer circles. In retrospect, it’s strange that it has taken so long to come to the fore. After all, in a way it’s the core skill determining our success or failure on a project. Our job is to teach an inanimate object to behave as if it cares about a user’s desires, and can anticipate their needs. How can we do that without empathy?

Morten Rand-Hendrickson gave a wonderful talk about this at WordCamp Europe this past year. He points out that there are some nuances to empathy that get glossed over in a lot of discussions: notably, the fact that we often believe we feel what someone else feels, but we have no way of knowing for certain if that’s true.

If you follow Kevlin Henney on Twitter, you know that he has a fascination with public software failures. He gave a talk about errors at GOTO 2016. One thing he talked about was the problem of “dead” code:

Dead code has a problem: it is the “dark matter” of your system. It shapes your system. Even though you can’t really see it—you don’t notice it—it is still there. And it exerts a very strong force on your system.

And the problem is there is no code that is truly dead. It turns out all you need to do is make a change of an assumption. And then suddenly, it’s no longer dead. It’s Zombie Code.

He also discusses some sobering research about how most catastrophic software failures are the result of nonfatal errors which then trigger bugs in un-tested, under-developed error-handling subsystems.

But that wasn’t the key point of his talk. He goes on to talk about the much greater danger of errors which do not result in catastrophic failures. These are the errors which go undetected for years, and feed back into human decisions: incorrect algorithms whose results are used as the basis for public policy.

Closely related: Chelsea Troy has a new blog post summarizing the book Weapons of Math Destruction:

we trust machines to build algorithms based on incomplete or biased data that we feed them, and they perpetuate poor and unfounded decisions under the guise of ‘scientificness’ because a computer made the decision.

Bob Martin is grumpy about over-prescriptive type systems in recent languages, specifically Swift and Kotlin.

because of all this presumption, they punish you when you are wrong. They force you to go back and change massive amounts of code, adding try! or ?: or open all the way up the stack.

And how do you avoid being punished? There are two ways. One that works; and one that doesn’t. The one that doesn’t work is to design everything up front before coding. The one that does avoid the punishment is to override all the safeties.

And so you will declare all your classes and all your functions open. You will never use exceptions. And you will get used to using lots and lots of ! characters to override the null checks and allow NPEs to rampage through your systems.

I know that there are a lot of people whose instantaneous reaction to this is going to be: those “safeties” are therefore your, well, safety. If you override them, you get what’s coming to you.

There was a time when I would have been one of those people. I would have said: every one of those instances of having to explicitly permit or acknowledge some future consequence is a prompt for important thought and consideration. Making these decisions is part of your responsibility as a developer, and if you gloss over them the outcomes are on your own head.

But as I think about it today, I think Uncle Bob may have a point here.

When was the last time you clicked through a EULA without reading it all the way through? How many times do you do this in an average week? Do you know what rights you signed away recently? Do you deserve what’s coming to you?

Here’s the problem: every prompt for thought is also a mental tax. And we know from research that energy for making decisions is a finite resource, which is depleted throughout the day.

With any system which demands your constant, consideration of repetitive choices, there comes a point where the only rational, pragmatic choice is to brush past the questions so you can preserve your scarce faculties for the really important decisions.

By the way, Martin also has a follow-up in response to feedback, explaining that types are not tests. Which, again, I largely agree with.

Kenneth Reits writes on The Reality of Developer Burnout:

I decided to fix the root of the problem. I realized that I was letting too many people into my world, not delegating enough, and needed help maintaining my projects. I didn’t want to lose what I valued most about my position within our community—being able to influence the world I cared so much about.

So, I unfollowed everyone on Twitter. Every single person. I stopped paying attention to tech trends and reading hacker news. I went into publish-only mode.

This was a great move, and something that I’ve seen many other developers do (although often implicitly, not explicitly) and is a great way to recover from the stresses of open software development. Take a break from the noise. Be gentle with yourself.

I’ve never gone full publish-only, but I have unfollowed everyone on Twitter and emphasized longer-form reading and writing.

And one-to-one discussions, which is what this newsletter is all about. Which brings me to a nice point of closure for this letter, I think. If anything here has sparked a thought, please hit “reply” and let me know.

By the way, I don’t think I’ve ever come out and said it, but: if you like SIGAVDI, please do tell your friends about it. Feel free to forward copies to them, or send them to http://sigavdi.email. Tweets are always appreciated as well 🙂

Some very brief notes on what I’ve been up to, before I close this:

As always: thanks for reading, and happy hacking!

Avdi