Archive for January 2011

Working with your Level-Up Cycle

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.

Get to know your Level-Up Cycle

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.

LinkedList Bonsai-State-Machine through Pointless Refactoring

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.
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.

Multiple Developer-Personality Disorder

In any software project there are at least five stakeholders in the technical development task:

The client, who has the vision of the finished features
The project manager, who has to organise technical resources and timetables
The architect, who designs the system at a macro level
The current coder, who implements each individual class and component
The future coder, who will maintain and enhance the software in the future

Working with your Complexity-dar

Managing complexity is what we do as programmers, right?

Whether you’re architecting a new application from scratch, or deep into writing a component or class or test method, complexity is the elephant in the room, and our job is to ignore it, or at least keep it in the corner, right?

I mean, complexity in software development is inevitable. Beyond “Hello World”, building and maintaining systems that solve interesting problems is like being in a boat full of holes. Every new thought the client has is another leak and we’re the poor sods standing in the middle with a bucket, scooping up the complexity and flinging it back into the sea as fast as possible, right?

You can tell by now that I’m about to say “think again”, can’t you?