A simple question: What did you have for breakfast this morning?
Me? I had toast. 2 slices, white, with Flora and some great peach jam that we brought back from Spain.And a cup of tea, white with 2 sugars.
Another question: What didn’t you have for breakfast this morning?
Me? I didn’t have oatmeal. Or eggs. Or a hippopotamus, or lego, or chainsaw oil. The list of things I didn’t have is endless. Literally endless.
It’s impossible to fully scope the list of things that something doesn’t do, and yet as developers it’s important that we don’t just know what our code does, we also know what it doesn’t do.
This weekend I found and fixed a potentially nasty hole in the robotlegs SignalCommandMap – more details of the actual hole a little later, and if you’re using the utility already you should consider updating to get this fix.
I’d love to say that it was a piece of inspired insight on my part, but I think there’s more value in the truth – that it was a series of happy co-incidences.
Continue reading »
Over the last few months I’ve knocked up a few specialised ‘maps’ for working with robotlegs. I like the ethos behind these kinds of utilities – abstracting the meta-logic (the nature of the problem being solved) away from the detail-logic (the specific solution).
I’d planned to blog each one in turn, but the time runs away so quickly doesn’t it?
And so – all in one fell swoop – I offer you 3 variations on the CommandMap, a SignalMap and a race-condition beating EventMap. All on github and created through Read-Me-Driven-Test-Driven-Development, so you should find the ReadMe in each case sufficient to get going, but do check out the diagrams in this post as well:
Continue reading »
A representation of how we acquire new skills
In Part 1 of this post I gave you a damn good excuse to play facebook games in order to get acquainted with your Level-Up Cycle – a process of acquiring new skills where we move from awareness of a possible new behaviour, through the intention to implement that behaviour, spend some time gathering feedback in conscious practice, initially disruptive before becoming integrated, and then – the magic moment – we Level-Up and what was once the idea of a possible new behaviour is a habitual unconscious practice.
Great games – Tony Hawk Skateboarding is my favourite example – allow us to progress from novice to expert without ever really feeling like we’re ‘being skooled’. What can we emulate about how a good game stimulates learning, that we can put into practice as programmers? Continue reading »
To me, one of the most interesting aspects of game design is the shaping of the player’s learning curve.
I know of two brilliant pieces on what ‘Fun’ looks like – Pierre Garneau’s 14 Forms of Fun and Marc LeBlanc’s 8 Kinds of Fun - both of which include elements which show us that often part of the ‘Fun’ is the gradual aquisition of skills/knowledge in order to apply a new ability to overcome a challenge in the game.
As programmers, we’re a set of people self-selected to enjoy challenges. We love the feeling of beating the end-of-level boss, whether it’s a giant mechanised robot or a tricky-to-diagnose fatal bug in our application.
Good game designers go to great lengths to ensure that we acquire new skills and abilities just-in-time to make steady progress through the game. In my dream universe there would be a meta-game in which we could learn to program – to get from our first
hello world to complete mastery via a series of satisfying and perfectly pitched challenges that allowed us to pick up new powers without ever feeling like we’ve ‘been skooled’.
The brilliant Rails for Zombies and the Head First books series are a great step towards that fantasy. But what can we take from great game design to make sure that no matter what our current level of ability, we regularly get opportunities to ‘Level-Up’?
Yesterday I had to implement a common, simple bit of functionality in a view. The view is revealed and hidden by clicking a tab button which causes it to slide up or down behind a mask.
The view is behind a mask, clicking the button reveals the view, clicking again hides it.
It’s not rocket science. The only awkward aspect of the implementation is that it has to be responsive to the user changing their mind mid-move. If I click the tab and then quickly change my mind, the movement should be reversed, and if I click it again it should be reversed again and so on.
This is the kind of behaviour I’ve implemented hundreds of times over the years, and you probably have too. I do it without really thinking about it. Except that these days I’m trying to think more about every line of code I write – inspired by some stuff I read (and now can’t find) where Corey Haines was talking about challenging yourself to answer the “Why stop now?” question when refactoring.
Continue reading »