Writing code like a good joke

2023-06-27

Often, a code problem is predictable. You know the starting point, the path and the target. You might even know how long it will take. But sometimes, you just don't know how to do it? There's no known path, and your usual tools don't fit. In that case why not have a little fun with that problem?

Disclaimer: I have built my entire career around problems that I find interesting and challenging, and avoided the predictable ones as much as possible. So this advice is targeted precisely at research type problems, where it works wonderfully, but might not be received as nicely for better known topics.

There are uncountable ways to tell a good joke, as many ways as there are combinations of comedians, audiences and particular moments in time. But there are general principles we can follow. Personally, I build jokes from:

• the audience: I need to know who is in front of me, and which topics they relate to. Easy for me when talking with developers, much harder in front of a more diverse audience. I have a lot of admiration for improv comedians who can quickly gauge their audience. This is typically what the "we can't say anything anymore" crowd does not understand: the sexist and racist jokes you tell with your buddies won't land elsewhere
• the relation with the topic: the more I know about a topic, the better I can laugh about it. But there's more to it: joking about a topic you are not related to can quickly become mean, and won't be well received. Also, the more I know, the more I build trust about it, the better it gets when I subvert this trust
• the uneasiness: a lot of jokes rely on an element of surprise, like using a word but with an unexpected meaning, building a coherent story then unraveling it quickly, or on the contrary, going on an absurd journey and try to land safely. That uneasiness is key: you target that "wait this makes no sense" reaction and quickly move back to the real world, and back to awkwardness again, etc

When you are suddenly tasked with an interesting problem, you are in the perfect place to start a good story. It might even be an actual user story, the kind with 2 points that will span 2 months. You were minding your business, but now you face a conflict, none of your usual tools work, and you must go on a journey of discovery.

You already have the perfect audience: your teammates, that you know well enough to understand their skills and what they can stomach to review in a pull request.

You are related to the topic, it's about a project and/or technology you know, you are the perfect person to tackle it, and let's be honest, you willingly seek out those messy problems.

Now let's get to the uneasiness! Your usual techniques don't work. The problem does not fit the nice little framework. SO LET'S BREAK IT. This is the moment where you take your tools (language, framework, protocol, database, etc.) and find unsafe, creative, fun ways to use them. Do not put any limits, you just want to see how far you can go.

If you are working on a protocol or API, find out how much you can break the specification without breaking the software at the other end. Specifications only bind the people who believe in them anyway, the running code is the real world.

If you have a performance issue: instead of making the code faster, see how long can you get away without actually running it.

If you have an architecture problem, and there's a potential solution that looks ugly, like downright revolting for a developer of your caliber, then by all means, try it!

If you just read about how engineers in another area design things (that could be video games, databases, frontend, embedded, bash scripts, whatever), you just know there are good reasons people don't work like that in your job. Test it anyway!

While doing that, you'll get into a lot of dead ends. It's ok, you're just having fun with it, you are not expecting any results. But after a while, you realize that you have a much better understanding of the problem, which approaches can never work and why. And you aso pushed the boundaries of your knowledge about your tools. Now you know how to get juuuuuust a little bit over the edge of what's acceptable, and come back safely. You might even know how to make that easily reproducible.

And from there you might find a path, an actual solution to your problem! Because finding a solution is often like recognizing a bug exists. You have to get out of your head and back into the real world. You're sure you wrote that code perfectly so there's no way that bug can happen. You know your tools perfectly so there's no way to solve that problem. Nope! The solution often exists, right outside of your comfort zone.

Landing the punchline

Okay so now you got a funny but bad solution to your problem. Time to refine it, in the same way you would work on a joke: remove the unused parts, everything that would slow down understanding, everything that can fail. You figured out how to make the code do something stupid, now it has to be stupid reliably. Since it is way outside of everybody's comfort zone, you know it will be scrutinized extra hard.

This is where you have to know your audience. If it goes too far, you just know it will never be accepted, or it will take time to convince people. That's why you polish it until it's perfect. And you attain perfection when the solution irks people but they find nothing wrong in it.