It’s that time of year again. The time when passionate developers get together all over the world to learn from each other. It’s time for Global Day of Coderetreat!
Yet not everything is perfect. The main complain I hear from people attending Coderetreats, especially after a few of them, is that they get bored with Conway’s Game Of Life. I strongly believe that this issue comes from a misunderstanding of the coderetreat. And I have solutions for you.
But first…
The Problem Is Not Important
Coderetreats are about practicing skills. In order to practice, we need a problem and a set of constraints that push us outside the comfort zone, into the learning circle. If you know the problem by heart, great; try constraints you’ve never tried.
Some of you will say “but if the problem doesn’t matter, why not change it?”. OK, I lied a bit. The problem has to be picked so that there are many opportunities for you to explore design. Conway’s Game of Life is such a problem; its solution space is very wide and you can get to a lot of unexpected places once you start pushing yourself to think differently. Also, it has to be easy to understand, easy to start with (not by installing 3 different frameworks, one web server and twenty libraries), adaptable for any programming language and so on. And the best thing about Conway’s Game of Life: it’s proven. It works for coderetreats.
So forget the problem. Think about what you want to learn. I’m sure we can figure out constraints for you to learn that thing.
The Constraints Help You Learn. That’s Why They Are Annoying.
You know how to remove loops from your code? Try functional programming constructs. How to remove if statements? Try polymorphism, functional programming, or just reducing the 10 if statements to just one. You’ll notice that you understand your code better.
During this process, you will feel annoyed. You might hate the facilitator for not giving you answers. You might say that it doesn’t make any sense.
Try instead to embrace the constraint. If you find it too extreme, talk to your pair and reduce its scope. Figure out how to do one thing better. Find strategies. Discover.
Coderetreats help you discover things by yourself. At the end, it’s your decision what you take in your daily work. But if you do it right, you will get something. If not a technique, a revived curiosity to try out things. This is what it’s all about.
A Few Constraints Depending on What You Want To Learn
Here are some of the constraints that I used in the past based on what people wanted to learn:
Pair programming => one of the pairing games. “Yes, and…” is a good start because pairing is, at its core, about communication.
Clean code => focus on naming, no conditionals, no loops.
Software Design => a double session; the first is write code while you know that requirements will change; the second is when we change the requirements and you realize you made a lot of assumptions
TDD => “TDD as if you meant it”, if you have a bit of TDD knowledge. “Incremental design” session where you first identify the input and the output, then define the increments as pairs (input, output), then order them and then start doing them one by one.
Something Different => Yes, I was asked for something different. Here’s one idea: (almost) no method calls, classes communicate only through events.
A Few Original Constraints, Never Before Tried at a Coderetreat
These are constraints I thought about in the past year, but never tried at a coderetreat.
- Use only regular expressions
- Each cell runs in its own process / thread / microservice. Extreme version: each cell is an AWS EC2 instance. When it comes to live, the machine starts. When it dies, the machine is destroyed. Use Lambda for extra points.
- Driver-documenter pairing: the driver writes code and when taking a short break, the documenter asks questions to build the decision tree for the resulting design. Questions such as: “what alternatives have you considered? what was the advantage / disadvantage of the alternative?” or a trickier one, “have you considered alternative X?”.
- A trickster cell is randomly appearing and disappearing in the universe, at least once every 5 cycles but always near a group of live cells
- Generalized Relativity: the time passes differently in certain areas of the universe. For example, a tick takes 3 normal ticks or, conversely, 10 ticks make a normal tick. This is actually an older idea, never tried as far as I know, and I have no idea if this can be included in the rules of the game.
- At the beginning, there’s a vampire cell. Vampire cells turn other cells nearby into vampires. In every generation, there is a slayer that kills all vampire cells around it. OK, I completely made this up since I’m a huge fan of “Buffy the Vampire Slayer” 😀
OK, 6 completely new sessions. They would make a pretty cool coderetreat, don’t you think?
So, remember:
The problem is not the problem. The problem is how much you’re willing to explore.
