convex.human

My wife and I are fans of escape rooms and we go to it often. The idea of it is that you get locked in a room and you have to solve puzzles (visual, word, cryptography, audio, etc.) within ~60 minutes in order to find your way out of the room.

Recently, we’ve been playing the game Escape Academy, an escape room simulator where you have to solve very similar puzzles to what you find in a real room in order to win.

At the end of each level, a “puzzle review” appears that shows how the puzzles in the level were solved (and sometimes, the optimal solution). This very simple addition at the end of each level was extremely helpful in understanding your thought process and putting things into perspective. Especially that these puzzles had to be solved very quickly, and you wouldn’t have time during the solving process to reflect on the how.

This made me think of how important it is to look back at a project or a problem once you found/implemented the solution. In programming (and other fields as well), a lot of problems take some time to be solved, needs you to try a couple of solutions before landing on the most optimal or the working one, and in many cases there are deadlines where problems need to be solved quickly. At the end of the process, you find yourself distant from the generic problem you started with, and it is hard to figure out how you reached the final destination.

So I started following the game’s approach in my work! Every time I get a relatively large project assigned, I focus on the solution - this enables quick delivery - and at the end? I do a small retro with myself. What were the problems I solved? Surely, a large project means smaller sub-projects. How did I solve these problems? What approaches did I try? And why? etc.

How can you do this retro?

There are multiple ways that I can think of, and here are some options:

• Create a chart or a document very similar to how the game does it (refer to the screenshot above). Put each sub-problem in a box and maybe attach some metrics that you want to measure for each problem.
• Present your solution in a demo or a tech guild! (Or for personal projects, record a Youtube video going over your project, or write a blog about it). This forces you to think deeply about your solution, and to think about possible questions coming from the audience about it.
• Write a runbook/guide/documentation about your solution and how to properly utilize it. This would also make you think very deeply about possible use-cases and how the system interacts with it.

There are obviously more ways to do this, so find the way that suits you and the problem you solved. But make sure to not delay this process for long and to do it quickly after a problem is solved so that it is fresh on your mind.