I want to tell the story of one of my favorite diffs I’ve ever committed. It’s probably not the “best” by any objective measure, but it’s a personal favorite and makes for a good story to boot.
Several years ago, I was on a small team building a static analysis and typechecking tool; the idea was that its analyzes would help the rest of our large engineering team reduce defects in our flagship webapp, written in PHP. Despite being somewhat unfinished, our tool had already improved developers ’lives enough that it had made its way into our commit hooks and core workflows.
One afternoon, a few of us on the team were grabbing lunch together, and the conversation turned to a recent bug where our webapp had started writing certain kinds of data onto the wrong database. While that wasn’t a huge problem yet, it had the potential to be a serious security issue in the future, and so a bit of effort had to be expended to clean up the data beyond just fixing the bug itself. None of this was in our domain and so didn’t directly affect us. But the thing that really got us going was the source of the bug: switch fallthrough.
And this wasn’t the first time something like this had happened! I recalled a similar incident from a year or so before, where code started doing something subtly wrong due to a bug where switch fallthrough was involved. And those were just the ones we had heard about; for every bug which made it to production, there had to be several more which were caught and fixed before that.
What a silly language mis-feature, we complained to each other. Maybe it kind of made sense in C, but in a very high-level language like PHP, there’s really no reason for switch to fall through at all. Well, it’s yet another PHP design mistake, we told each other. It would be great if someone could change the design of the language, but until then, we’ll just have to live with it.
But wait. The people who decide on the design of the language are … us . Here, right now, at this table. Who just agreed this was stupid and should be fixed. Okay, fine, we don’t have any influence over the design of PHP itself, but via our typechecking tool, we absolutely have de facto control over how PHP is used in practice at our company. We didn’t have infinite social capital to abuse that control to do unpopular things, but switch fallthrough isn’t exactly a beloved feature of PHP; banning it would likely be seen as another major win for our tool.
Somehow, that didn’t seem to have occurred to anyone; everyone was complaining but no one was suggesting any real action. I realized that I’d recently been playing around with some of our control flow detection, so I knew exactly how to implement this change. I declared, “Switch fallthrough. It’s done. I’m going to go back to my desk and remove it from the language. ”
I knew that, after building the new module, I’d have to use it to do a tiresome cleanup of existing usages of it in our webapp, before deploying it to finally ban the construct. But I was mad about the recent bugs, and so I just rage-coded it all out over the course of the afternoon. (The cleanup was annoying, but things can go faster than expected when you can channel your fury to power through all the changes without stopping!)
Everyone on my team was supportive – unsurprising given our previous conversation. The cleanup diffs I’d written that afternoon mostly just annotated clearly-intentional fallthroughs, but some of them fixed very real bugs my new module found; when I started pushing those diffs out, everyone else I interacted with working on the main webapp was supportive too (and sometimes a little horrified). My initial diff to ban switch fallthrough shipped in the next release of our tool a few days later, ending the feature – and its resulting bugs – forever.
Anyone could have done this. (Our tech lead could probably have done it faster .) But no one had, and no one was going to. It simply hadn’t occurred to anyone that we were in a position, both technically and organisationally, to fix this.
Often my biggest contribution isn’t being the only one who is able to fix something, but being the only one who realises something is fixable . This diff is my favorite because it is one of the first, one of the most impactful, and still one of the most clear-cut, cases of this in my career.
Be the change you want to see in the world.
GIPHY App Key not set. Please check settings