Writing code like a good joke

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:

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.

I love mess

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.