Companions in Grimrock

Legend of Grimrock, by Finnish developer Almost Human, puts you in control of four criminals trying to escape a mountain prison. Though rendered in full 3D, the gameplay uses grid movement and owes a lot to classic dungeon crawlers like Eye of the Beholder. At a glance, it’s easy to see Just-Another-Dungeon-Crawl. Don’t be fooled. Grimrock is playful, self-aware, and earnest. It is a heartfelt triumph by a small, passionate team.

I played Grimrock in February and March of 2013. I’m only now managing to write about it because it’s been hard to capture how it made me feel. Now, with a sequel approaching, I think I’ve got it: Rarely have I felt so accompanied while playing a game. That company (both real and fictional) transformed my experience.

Warning: This post contains spoilers for Legend of Grimrock.

Continue reading “Companions in Grimrock”

1000 Blank White Cards

A game where you make up the cards, and therefore make up the rules, as you go along, “The blank card game,” is heavily dependent on the people playing. With a few good seed players, this can pull enormous creativity out of otherwise reticent people, but by itself does not inspire the gaming spirit. This can be great fun for groups with lots of in-jokes.

Created by Nathan McQuillen Phoenix, 1995.


The Clean Coder

I just finished reading The Clean Coder: A Code of Conduct for Professional Programmers by Robert C. Martin.

Martin, affectionately known as “Uncle Bob” to many software professionals, is a well-known advocate of Agile development practices and software craftsmanship. A little more than a year ago my colleague Erik Rydeman recommended Martin’s Clean Code, and that book had a significant impact on my work.

Clean Coder (2011) is Martin’s most recent book. It’s a slim volume of lessons from his career, written so that others can learn from his mistakes. The book focuses less on code and more on the behavior of those who write it. I found this book less transformative then Clean Code, but it’s the best survey I’ve read of the real challenges faced by programmers at work, and I wish it had existed in 2009 so I could have read it as I finished my undergraduate degree. Here are my key takeaways today:

It should be no surprise that four whole chapters are dedicated to making and keeping commitments: “Saying No,” “Saying Yes,” “Estimation,” and “Pressure” all deal with the challenge of telling management what you can and can’t do, and sticking to it. I liked one part in particular: Martin demonstrates that a clear language of commitment (I will do something by this time) and eliminating language that eschews responsibility will prevent many commitment problems. When you unequivocally take responsibility, you are less likely to overcommit – it makes you look bad! This may seem like obvious, generic advice for any discipline, but it’s necessary in software when we are often so bad at estimation, and often so pressured to throw our estimates.

I was surprised by a small tirade against the flow state many coders experience while working. Martin takes just a page to say that flow is harmful – that it trades in rational thought for a sense of speed and focus, and furthermore that flow makes a person irritable when interrupted and slow to resume their work.

I had a positive attitude toward flow until Martin pointed something out that changed my perspective: Pair programming blocks flow, because it encourages constant communication. The last few months at work are the first time I’ve spent the majority of my time pairing, and I haven’t missed the flow experience at all. Instead, I have written better code at a steady pace and been less bothered by interruptions than ever. For a team, anything that breaks down communication is a problem. I’ve changed my perspective on flow (and maybe on headphones) because of this observation.

Acceptance Testing
The one discipline discussed that I still have not used is acceptance testing. It’s tempting to write this chapter off, especially since Martin promotes his own tool, Fitnesse. But I’ve had positive experiences with the other disciplines in the book, so I’m anxious to give this a try. I’m not sure how useful a solo trial would be though – I may need to wait until I can convince a small team to give this a shot before I can evaluate its usefulness.

At the end of the book, Martin describes a simple system of software apprenticeship where engineers can be identified as masters, journeymen, and apprentices. At this point in my career, I seem to fit squarely into the journeyman category – five years of full-time employment writing software (skipping some non-programming schooling in the middle), experience on four shipped products all using different technologies, and becoming familiar with key disciplines. This book brought the inexperience of my past into painful focus (many thanks to the employers and colleagues that have pulled me through my apprenticeship years!). But it also gives me hope that I’m on the right track and points out new directions for growth.

I think this book has earned a permanent place on my shelf, just to skim every couple of years as a reminder of professional conduct.

Abject failure and banana bread

I haven’t been keeping up my baking posts! My new hobby hasn’t gone away. Here are some of my recent adventures in baking:

I had a bad run of underdone breads. I was trying wheat breads, and lower temperatures, and it just wasn’t working out. You can see how heavy this one is.


And another bust – check out the doughy center of this loaf. It was barely edible. I took a break from baking after this.



Then, while house-bound on a particularly slow Saturday, I decided to go back to crispy white breads and try again. I mixed a large batch of dough with good bread flour, a little extra salt, and some olive oil, agave, and rosemary. I gave it plenty of time to rise. I determined to bake at 450° again. Unfortunately it flattened during the final rise and got folded on the way into the oven, and turned out looking like a giant croissant:


Silly shape aside, this was by far the best bread I’ve made! It had a crispy crust and a perfect bubbly crumb. The rosemary and salt helped create a nice robust flavor. I was glad it was a large loaf, it was a staple in our house for a couple of days. I’m also learning that a teaspoon of oil in your dough goes a really long way as a preservative.

The rosemary-mega-croissant was baked on a new baking stone my wife ordered. She also got a stoneware loaf pan for me to try, so I tried a white bread in the loaf pan. It was okay – a little like a fluffy salt cracker. I’ll probably use this pan next time I try wheat bread, since it can take a wet dough and might bake through better.


I also made a perfect vegan chocolate chip banana bread in my new loaf pan. Maybe it… disappeared… before I could reach the camera. I wish I had taken before-and-after photos though. As batter the pan was only half-full, but it rose so well that it blossomed over the top.

I do feel my intuition improving. I didn’t use a recipe for any of these breads, except for the banana bread where I cherry-picked ingredients from two different recipes. Next I’ll either make the banana bread again, or try to recreate the rosemary bread. It’s a pleasant rainy day in Seattle – I think I need to make some good soups to go with these breads.