The intent is to pair for around an hour at a time with a number of different partners. All code is thrown away at the end of each cycle, because the focus is on process and reflection, not progress. At the start of each cycle you begin again on the problem, as if the code you’ve written previously had never been written.

Whether or not you should keep the understanding you gained is a more complex question; it’s impossible to unlearn, but by cycle 6 you’re generally pretty certain that what you learned in cycle 1 was not that useful after all.

Pairs can vary language and approach – we used Ruby, Python and AS3 – but there’s an emphasis on some kind of test-driven process. Test-driving can happen through conventional TDD, BDD or – our favourite at try{harder} – “TDD as if you meant it”, in which all production code is written in the test case.

We like the “TDD as if you meant it” approach because it forces you to defer committing to a definition of the solution in terms of classes, and we find that the code we write is often very different from the code we expected to write at the start of each session.

Why change the exercise?

In the past we’ve used Conway’s Game of Life as the provocation. It works well, but in some ways it feels too meaty (especially in AS3) – offering so much scope that it’s easy to vary sessions simply by shifting between the domains of the problem (the rules, the display, rendering, cycle controls and so on).

For the purposes of reflecting on tdd-fundamentals, clean code, method and variable naming, and so on, the provocation-problem chosen is almost irrelevant (provided it can be understood and held in mind without taking up too many attention slots). We were all set to use Conway’s Game of Life as usual, when, during a seminar about ‘hard to test’ code, we stumbled upon a smaller problem that led to the opportunity to reflect in more detail on the “assumptions and understanding” axis of test-driven programming. We’ve nick-named the problem “Rhyme Harder” and it goes a little something like this:

Rhyme Harder

1. You are building a game to teach children (or second language students) about the alphabet letter names, in relation to simple phonics (sounds of letter combinations).
2. The player is offered a display which shows each of the 26 letters of the alphabet.
3. The player “wins” by clicking a sequence of letters which starts with A, ends with Z, and includes each of the 26 letters once and only once.
4. The sequence may not include any pairs of consecutive letters with names belonging to the same phonic group.

Phonic groups

Phonic groups pull together letters which have names which contain the same vowel sound – for example “A and K”, “B and C”, “M and N”. Phonic groups can potentially vary depending on country and region – “Zee and B” or “Zed and F”. In Scotland some accents would say “J and I” (so that the J rhymes with I) rather than “J and K”.

Opportunities for variation

In the first couple of cycles, most pairs were satisfied with exploring different ways of representing and checking “the rules”. Successive cycles revealed that the problem has plenty of scope for reflection and exploration – for example:

• Rules can be checked on a turn-by-turn basis, or only when the 26th item in the sequence is submitted
• Checking the move can return a “yes” or “no” result, or a result which contains all the next valid moves (which could be useful for hinting)
• It can be useful to explore how to open the way for sophisticated scoring options such as rewarding words spelled along the route

What I find most interesting about exploring these alternatives is that frequently we pass through an increase in complexity, while we unpick our assumptions, and come out the other side with a simpler solution. (Something I’ve also scribbled about before). The experienced reminded me that questioning my assumptions explicitly can lead me to more elegant, less unwieldy solutions.

Remembering to look down

I’ve talked before about “The MacGuyver Principle” in programming – in which the most important trait is the ability to just not look down. At the time I was thinking this way with regard to programming without tests, but pairing has led me to understand that even when I’m testing, I still spend a great deal of energy just trying not to look down. I’m wilfully blind to the assumptions that my tests make.

Robin Wilding, aka @redannick , gave a great presentation at try{harder} about the benefits of striving for less, not more, flow.

Flow - ‘wow, did 3 hours really just go past? I was totally in the zone, ah, wow, I really need to pee… ‘ – is how we get stuff done, but too much flow can allow us to stay suspended in wrong assumptions, Wile E Coyote style, only experiencing the crash to the floor when we finally, usually accidentally, look down.

Just… don't… look… down…

Pairing forces you to look down far more frequently. Which hurts. On the up side, often it allows you to notice that you’re about to run off a cliff, before it happens. The more conceptually complex the problem (or provocation), the more value there is in pairing, in my experience.

Suck it and see

If you’re heading to Beyond Tellerand – Play in Cologne in April (the conference that used to be FFK), come along to the post-conference pair-programming workshop on “Building intelligent applications” that I’ll be running on the 27th April.

It’s 250 euros for the full-day workshop (the price is not entirely clear on the workshops page, but if you click through to bookings you should see the correct price there).  I’ll be writing more about what you can expect from that workshop in the coming days – feel free to get in touch via twitter if you have any questions about it right now. I can’t wait to see you there!

Thanks to JetBrains, all participants will get a full Personal License for IntelliJ IDEA 11, which would normally set you back £155.

Can’t code withoutJava IDE with advanced HTML/CSS/JavaScript
editor for hardcore web-developers

try{harder} Level Up is a collaborative-learning conference aimed at mid-to-senior developers with a background in ActionScript. It’s taking place next week – 19th to 23rd of March, in Nottingham, UK.

try{harder} Level Up is a residential course – you’ll be sharing a luxury lodge with other participants, and the freelance-discount price of £699 (reduced from £1300) includes accommodation and some food, so your only other costs will be transport, beer money and dinner.

Numbers are limited to 16 – 8 try{harder} Mentors, including the people who brought you Robotlegs and Swiftsuspenders, and 8 new participants (one of them could be you!).

We only have a handful of spots left, so get in fast!

Why IntelliJ IDEA?

Many of the Mentors are IntelliJ addicts, and can run participants through the set up process, so that you’re up and running straight away.

We’ll favour using IntelliJ IDEA for our pair programming sessions because the high powered refactorings are particularly suited to “TDD as if you meant it”, in which new code is always written in the test case and only makes its way to production classes using refactoring tools.

IntelliJ IDEA 11 is an ideal IDE if you’re working in multiple languages – with support for languages from CoffeeScript to Ruby (and of course AS3). In addition to all the built-in features, you can bolt on workflow-specific power-ups such as John Lindquist’s Robotlegs and Signals plugins.

We’re thrilled that JetBrains have taken the time to consider and support what we’re doing with try{harder} – if you want to attend next week’s Level Up, you can get all the info here.

Newsflash: The price for freelance attendees of try{harder} – Level Up will now be £699.

How? The mentors originally agreed to do the conference for a nominal sum to cover expenses plus one day of pay, but in the interests of making try{harder} – Level Up accessible to more freelancers, we’re now running the conference on an expenses-only basis.

Although there’s only a week and a bit to go, we expect that at this price those last places will go fast – so, if you have an opening for the week of the 19th March and you don’t want to miss out, get in touch now. (Hell, make an opening for the week of the 19th!)

The winter try{harder} 2012 will be the first week of October, but at present there are no slots at that conference available – all of the original group from 2011 have said they’d like to keep their place in 2012. So this is the only opportunity for newcomers to experience try{harder} in 2012.

Should I really invest in flash-based learning, now?

If you’re thinking of shifting away from AS3 as your primary platform, Level Up couldn’t be more suitable:

Till Schneidereit (Swiftsuspenders) has been working in JavaScript for some time, and as he’s also now helping Mozilla to develop FireFox, he can blow your mind with the latest live-debugging / rapid-prototyping tools available for JS.

Plus, most of the mentor sessions are platform neutral, and many are geared towards our current development climate:

Till Schneidereit: Project Forensics
How to detect the clues that allow you to make changes in someone else’s codebase, fast.

Shaun Smith: Robotlegs 2
Architecting for extension.

Stray: Fluent code
Creating DSLs, fluent APIs, helpful builders and meta code, with examples in AS3, php, Ruby and JavaScript.

David Arno: You can be a polyglot too
How to efficiently analyse and adopt new programming languages.

Michal Wroblewski: Maximizing performance in mobile games
You’ll learn that optimizing performance on desktop and mobile require different strategies. Covering rendering options including the latest AIR SDK 3.2 possibilities and also which gaming frameworks will help you achieve this. Prepare for a ‘tricks&tips’ intensive presentation.

Robin Wilding: Maximising developer flow

Angela Relle: How useful are your user stories?

Bonus offer: Come to try{harder} – Level Up and get a free ticket to btplay

We’ve got one btplay conference ticket to give away to the next person to sign up for Level Up who wants to attend both.

The btplay conference: Play, Beyond Tellerand, is 25th – 26th April, 2012, in Cologne, Germany.

I’m speaking at the conference and also running an AI workshop on Building Intelligent Applications (Workshops are not included in the standard ticket we’re giving away).

But that also brings me right to the point: describing try{harder} has become much more difficult since the Adobe ‘incident’ in November.

The original strap-line, “collaborative learning for flash-platform developers”, now feels like it weighs us down. That flash-platform is being eroded daily – we’re stuck in our very own 2D adventure game, and the ground is breaking up around us. Perhaps it’s on fire in some places… with particle effects and everything! Can’t do that in HTML5 can you? Oh… but… anyway…

We will always be flash developers

Regardless of what tech we’re building our projects in tomorrow, if you and I have both spent three, or five, or even ten years building projects that were anchored by whatever incarnation the flash player was in at the time, that experience changed us. Our brains have been physically moulded by that process. We can’t un-make those connections.

Not to say that we’re identical, but the nature of the brain-wiring that the process creates gives us a good chance of being able to have efficient, high quality communication about a problem. I often have great conversations with developers who work in other technologies, but the most concentrated goodness comes from sharing with other advanced AS3 devs, and the buzz I’ve experienced at FOTB tells me that I’m not alone. (Not that AS3 devs are better, but that my brain can dig their brain more effectively).

Crucially, the label “flash developer” gives us a way to identify each other – to recognise each other as potential sources of support. We’re a tribe, and the “flash developer” label serves the same purpose as the Christian cross, or the rainbow – it allows us to find each other in the crowd (or on Twitter), even if we’ve never met before.

And now, without much warning, the buffalo have gone away and our tribe is breaking apart.

The pain you feel is not about technology

I’ve felt anxious on and off since that horrible week in November – how about you? And I know that my anxiety is not about the requirement to learn something new – I love learning new things, and I know that much of my understanding of development is language and platform independent. But I still feel anxious.

I suspect that the source of the anxiety is the breaking up of our tribe. It feels similar to the early-adulthood exodus. My friends who stayed behind in the town we’d grown up in feel that those who left thought they were stupid for staying behind. Those of us who left feel that we’re no longer welcome in the places most familiar to us.

The flash-platform community is going through the same process as a million tribes before it. After a period of prosperity and stability, something shifts. The population outgrows the resources, or those resources are randomly disrupted, or there are rumours of dragons in the forests or gold in the river beyond the mountain. And some people up and leave straight away, and others follow them soon after – perhaps unsure which trail to take, but figuring that any path out is better than staying behind, and some folk can’t leave, or choose to stay behind.

Sharing without judging

In these circumstances, it’s hard to share our new experiences in technology without sometimes feeling like we’re being judged. “Hey, check out this awesome js framework!” has an echo of “Quit hanging around where there are no buffalo, stupid!” for those of us who are still shivering at the thought of actually writing JavaScript as a day job. (Hold any feedback on whether writing JS is actually fun or not, that’s not the point!)

And those of us who are left behind are, no doubt, increasingly defensive in our responses. It’s not that we don’t value your advice that we should be moving on, it’s just that really, we don’t want to hear it – because it suggests that we’re just uninformed, and in need of persuasion for our own good. So we don’t even respond with our usual respectful curiosity, we either bat it away or make references to the emperor’s new clothes. We RT the people who agree with us and gradually unfollow those who don’t.

So communication in these situations becomes increasingly hard, but it’s necessary. If we want to continue to benefit from the larger tribe’s shared pool of knowledge and wisdom and technology, and not all be sitting in our little caves reinventing the wheel (or asynchronous process token) from scratch, we have to push through this phase. We have to try to keep the communication going between those who stayed behind in the village and those who are forging new trails, without judging each other for being in either position.

try{harder} is a tool for keeping our tribe together

I’m lucky to have found myself some amazing individuals who also happen to be flash platform developers – some of them now panning for js gold, some of them still in the flash village. try{harder} is an opportunity to share with each other in a style that is intentionally de-polarising. We aim for a balance between the concrete and the abstract in our seminars – it’s not just ‘inspiration’, but neither is it so technically specific that it’s only relevant to a subsection of the group.

We’re a small enough crowd that it’s inevitable that before the week is out, everybody will have asked at least one naive question, so we encourage and respond positively to naive questions as well as expertise. And our shared fluency in AS3 gives us a solid basis for communicating complex ideas, and collaborating in AS3 or other technologies.

But “collaborative training for advanced developers-who-have-a-shared-basis-for-understanding-as-a-result-of-having-spent-significant-time-working-with-flash” doesn’t really trip off the tongue.

My workshop is a deep exploration of the process of building smart systems that can solve complex problems. I like to think of the subject area as “Stop telling your software what to do!”

We’ll be building

• recommendation engines
• insight-extraction systems
• really good optimisation strategies
• neural networks that can learn to solve problems
• and throwing in some game theory too

The workshop is going to be held in Python, but you don’t need any experience with Python to attend. As long as you’re an experienced programmer, whether your primary language is ActionScript, JavaScript, Ruby, PHP, Obj-C, Java… you’ll find Python easy to read and quick to pick up.

The workshop numbers will be at least six, and not more than twenty, participants. As this is an advanced programming workshop, I’m expecting we’ll be on the smaller side.

To pair or not to pair?

My intention is to run the workshop as a pair-programming day. We will be shifting between teaching, group discussion and pair-programming or paper-solving the next step in the problem. You can expect to work hard!

Pairs will rotate through the day, so you will pair with at least four other people. Whether you want to truly pair (work on a single machine passing the keyboard between you) or shadow-pair (each type on your own machines, but produce the same code through discussion), will be up to each pair to decide.

I’ve had great experiences of pairing, and even group coding, with other programmers – especially programmers I’ve only just met. We do a full day of pair-programming at try{harder} and for many participants it’s one of the highlights.

But there’s no doubt that some folk don’t enjoy pairing quite as much. In fact, when I mentioned pairing in my workshop to some other, more experienced, workshop-leaders, they were surprised that I’d even consider it. So – here’s my attempt to explain why pairing up on problem solving is a winner. I’d value your comments, especially if you’re thinking of attending the workshop.

Pairing leads to deeper understanding

In solving the problem, you encounter not only your own responses to the problem, but also your partner’s responses, plus their responses to your responses, plus your responses to their responses. In my experience the value of each consecutive layer of response doesn’t diminish, but has a shape more like this:

Pairing leads to consecutive deeper insights

Pairing works best when there’s no ‘code ownership’

At try{harder}, our pair programming takes the form of a code retreat – the most important rule is that at the end of each cycle, all the code is deleted.

In the workshop, you’d keep the code for reference later, but you don’t need to take it any further. You’re not going to be tied to this code on a project – in fact, unless you work in Python, the code itself is of no value – so the real long-lasting outcome is understanding.

So if your partner suggests something that sits outside your normal programming protocols, you’re free to experiment. Either you’ll learn something new that you may use again, or you’ll learn something about why you don’t ever want to use it again.

I need your feedback

I understand that pair-programming can be uncomfortable for some people. I’m an aspie myself, so I experience the shy factor, but I’ve found pair-programing / problem-solving to be one of the least uncomfortable social experiences, because the rules are well defined.

But – I could be smoking crack here. Are you sold on the benefits of pairing for this kind of workshop? Would you see it as an added benefit or a real drawback? Is there anything that would tip the balance for you?

Please vote in this poll, and feel free to leave comments too. If you want more information about my workshop at Play / Beyond Tellerand, just ask.

Thanks for your input!

Are you ready to Level-Up?

March 19th-23rd: try{harder} Level Up is a conference with a difference:

1. 5 days, 4 nights.
2. 8 try{harder} mentors who took part in the original try{harder} and want to share it with…
3. 8 new try{harder} participants who want to level-up.
4. Everybody teaches, everybody learns.

You can read more about how try{harder} came about here, or skip straight to the Level Up conference details.

Why this, and why now?

We actually decided to run try{harder} Level Up almost as soon as we’d returned from the original event in October. All 16 members of the original meeting wanted to commit to a repeat event in 2012, and we felt that it would be ideal to run it as a ‘closed’ group – we’d been changed by an incredibly rich experience and wanted to pick up from the same place next time.

But the experience also felt too valuable not to share. try{harder} was the best conference we’d been to. We’d learned more in those 4 days than at every other conference we’d ever attended, put together.

So, it was suggested that perhaps the people who would benefit most of all would be those who are right on the cusp of becoming ‘advanced’ developers. People who will be the fresh faces on the conference circuit in a year or two, given the right mentoring and an opportunity to learn not just about their discipline, but also about learning itself.

And then Adobe murdered our baby

I’d intended to launch the Level Up conference in November. And then there came the week of the Adobepocalyse, and it felt like there were more urgent conversations for our community to be having.

In the weeks following, what emerged was a feeling not that the conference was irrelevant, but that it was more relevant than ever before: we need to be ready to deliver projects in different ways, with stronger meta-skills and a broader understanding of the problem space we operate in than ever.

We don’t know what we’ll be doing 2 years from now, except that it won’t be what we’re doing today. In that context, a conference that covers a wide range of advanced development subjects as seminars, where you also benefit from the insight emerging in the questions of fifteen of your peers from different backgrounds, feels like an excellent fit.

Do you want to try{harder}?

Pound (or dollar or euro) for pound and hour for hour, try{harder} will surpass any other learning experience available. You’ll also work with a try{harder} mentor to create your own seminar. So if you’ve ever wanted to speak at one of the major industry conferences, this is a chance to get the kind of experience that can make that possible.

We expect that you’ll become a member of the try{harder} family – with ongoing access to mentoring and advice from a diverse range of experts.

You’ll build relationships with other inspirational developers, and if you’re lucky then it can also lead to future work. Dominic (@devboy_org) recently moved to San Francisco to work with Alec (alecmce), as a direct result of the time they spent coding together at try{harder}.

One of the things that emerged out of try{harder} in October was that many of us feel driven to work on meaningful projects, and this is something we hope to be able to collaborate on in future.

But don’t just take my word for it – read for yourself:

What to tell your boss

If you’re selling this idea to your boss, they probably don’t want you dreaming about running away to join the try{harder} circus… but we do use each other for confidential consultation on technical problems; having a network of advanced developers who willingly lend their experience when you encounter something new or unexpected is invaluable.

Because of the size of the group, in every session you can ask the questions that make it relevant to the challenges you’re facing at work right now.

If you’re a mid-to-senior level developer you should leave try{harder} Level Up ready to lead projects. If you’re already a senior developer you’ll go back to work more effective, more efficient and more flexible than ever.

In his article “No Silver Bullet: Essence and Accidents of Software Engineering”, Frederick P. Brooks analyses the key factors in creating great Software Designers – the people who don’t just write code, but creatively determine what code should be written (we probably refer to them as architects or technical leads). It’s worth reading the whole article but the part you need your boss to read is this final summary:

How to grow great designers? Space does not permit a lengthy discussion, but some steps are obvious:
1. Systematically identify top designers as early as possible. The best are often not the most experienced.
2. Assign a career mentor to be responsible for the development of the prospect, and carefully keep a career file.
3. Devise and maintain a career development plan for each prospect, including carefully selected apprenticeships with top designers, episodes of advanced formal education, and short courses, all interspersed with solo-design and technical leadership assignments.
4. Provide opportunities for growing designers to interact with and stimulate each other.

try{harder} is a high quality, concentrated dose of point (4), picking up point (3) and creating opportunities for (2) along the way. All you need now is for your boss to identify you as advised in (1)!

[The article was written in 1987, but is cited in Peter Norvig's (head of research at Google) piece "Teach Yourself Programming in Ten Years" which is also worth a read.]

We understand that it’s a lot of money if you’re freelance

Shaves as close as a blade or your money back.

We’re self-employed too! We can see that although, on paper, it’s good value for 4 days of small-group learning (even before you consider the fact that it includes accommodation and some food), £1300 still feels like a big chunk of money. So here’s a deal: if you don’t feel that the conference has paid for itself within the six months after it, I’ll give you 2 days of my time, free, as a refund, working remotely on any AS3 project you choose.

The challenge is akin to playing a game – and many of the rules of good game design apply just as well to your code base as the product of your compiled application.

A golden rule: ‘Guess what I’m thinking’ is not a fun game

But it is! I can hear some of you shouting. What about 20 Questions! What about ISpy! Yes, ok, they can be fun, given certain conditions: ISpy requires a small enough possibility space. It’s more fun in a car than a supermarket. 20 Questions (a beautiful binary search of the whole universe!) relies upon having an agent that can accurately tell you which pile of hay your needle resides in.

Without those constraints, ‘Guess what I’m thinking’ is just frustrating.

Let’s try it:

Guess what I’m thinking of right now. I’ll give you a clue, it’s an actual concrete thing.

No, it’s not that.

No, it’s not that either.

A comparison search of the whole probability space of ‘things’ is going to take a pretty long time.

This is, in itself, the main reason why I have never shifted myself over the pain barrier to learn Flex. There are just too many moments in which I find myself being asked to guess what Adobe were thinking, without the mechanism to make that game much fun at all.

Instead I’ve chosen to play other games: learning ruby, python, particular domains of problem solving and so on. Games in which I regularly get to intuit an answer that I’ve never been explicitly told in order to solve the puzzle in front of me.

Intuiting new solutions is fun (and the opposite of guessing)

Game designers work hard on providing the minimum amount of information, just-in-time, for the player to progress in a game.

If you take something as simple as a Facebook ‘blitz’ time-waster game, there are often layers of complexity which are invisible to the novice player, yet the player who is unaware of the hidden complexities isn’t penalised for their incomplete understanding.

As the player builds their experience, they eventually get sufficient exposure to the game’s patterns that usually they can intuit the additional layers without being spoon fed them. We may build in ‘hints and tips’, but for the majority of players these are timed so that they confirm what the player had already intuited for themselves.

If we’re simply handed an answer that makes sense, or it is presented in a way that reveals a hole in our thinking, it can sometimes be satisfying, but usually the chemical impact of ‘given’ information is minimal. So we don’t retain it. So we end up having to look it up all over again next time. We also only understand it as a specific solution to a specific problem, making it more difficult to teach someone else, who might have questions that expose the shallowness of our understanding.

Robotlegs makes your codebase into a great game

I experimented with Robotlegs and found that it brought fun to my codebase, and many other developers make the same claim. Of course it’s not perfect, but once I’d grasped a few key principles it felt as if I could intuit new solutions, and they often turned out to be correct.

Robotlegs felt like the original Tombraider games. I got a kick out of solving new puzzles for myself. I quickly felt confident taking on ‘boss’ problems, and it didn’t feel like I was just mashing buttons until I happened upon the right combination.

Other frameworks and utilities have often felt more like the early Harry Potter games – you do a lot of wandering around and from time to time you have to resort to a cheat site to get any further because the solution to the puzzle is so unintuitive. Not fun.

If our codebase is a game, how else can we maximise the fun?

There are two major pieces of work on the question “What *is* fun?” that I’m aware of – Pierre Garneau’s 14 Forms of Fun, and Marc Le Blanc’s 8 Kinds of Fun.

I prefer Marc Le Blanc’s model, partly just because the list feels more applicable to a wide range of problems. I’ve worked with consultants on applying this list to job design – profiling people’s ‘fun preferences’ against roles, and it maps well to teaching and writing as well.

The 8 Kinds of Fun

• Sensation – Game as sense-pleasure
• Fantasy – Game as make-believe
• Narrative – Game as unfolding story
• Challenge – Game as obstacle course
• Fellowship – Game as social framework
• Discovery – Game as uncharted territory
• Expression – Game as soap box
• Submission – Game as mindless pastime

If we substitute the word Code for the word Game, I see that Code as mindless pastime is a little tangential – though I don’t doubt that there are times when we want to bury ourselves in code so as to escape the world around us. I think the Fantasy and Discovery elements largely collapse into one concept for coders – exploring new territory / possibilities, often without a specific goal in mind.

My 7 Kinds of Code Fun

• Sensation – Code as sense-pleasure
• Discovery – Code as experimentation
• Narrative – Code as unfolding story
• Challenge – Code as obstacle course
• Fellowship – Code as collaboration
• Expression – Code as soap box
• Submission – Code as distraction from the world

Sensation – Code as sense-pleasure

Aesthetically, nicely laid out, clean code can be beautiful. It’s worth knowing that in brain-chemistry terms, “Truth” and “Beauty” are largely the same. The most attractive solutions combine both, something that mathematicians have always known intuitively.

Discovery – Code as experimentation

Whether your terrain of choice is generative art, byte weaving or just the kind of ‘what if?’ that lead Robert Penner to come up with AS3 Signals, there is something immensely satisfying about experimenting.

One of the reasons I advocate TDD is that a really comprehensive test suite allows coders (including you) to ‘play’ in your production codebase safely.

Narrative – Code as unfolding story

The reason I trained as an engineer and not a pure scientist or mathematician is that I get a kick out of making *things* that enter the world as physical or virtual objects, and change people’s lives in small ways.

I don’t think it’s a coincidence that at try { harder } the group featured people who’d had prior careers as choreographers and in theatre. Many developers are in love with the process of bringing a story to life.

Agile processes with great test coverage allow us to add new ‘episodes’ to the narrative of our product regularly.

Challenge – Code as obstacle course

This is the area programmers are most likely to be drawn to and aware of. Fixing bugs and delivering features feeds our ego and our families, and also keeps us from eating, sleeping and spending time with the people we love!

We want any obstacles designed in to our codebase to be the kind that can be overcome using the tools and patterns that novice users of the code can quickly pick up. And we want to avoid priming the player (developer) with red-herring solutions.

Fellowship – Code as collaboration

We can ‘collaborate’ with other programmers in real time using pair or group programming, or in near-real-time, passing iterations back and forth between us. Probably just as frequently, we wind up ‘co-creating’ work without ever having an interaction with the coder who comes before or after us.

Sometimes picking up someone else’s code is just a joy, and other times it’s a nightmare. My belief is that avoiding “Guess what I’m thinking” games in our codebase is the primary difference between the two. And no, comments, and even documentation, don’t get around this, because if there isn’t a coherent pattern that the game player can use to intuit novel solutions then it’s still no fun to have to reference the “cheats” constantly in order to make progress.

Expression – Code as soap box

Our code expresses what we believe about code. Have you ever met a developer who wasn’t passionate about their particular coding style?

Submission – Code as distraction from the world

Euro crisis? Shh… I’ve nearly got this code figured out…

I only stayed a day and a half – partly logistics and partly that, being autistic, I find these situations very demanding and I wasn’t sure how much I could absorb before my brain started playing up. I think I found just the right balance for a first-time, but would definitely stay for the whole conference in future.

My only regret is that I was too shy to interact with many of the other speakers. Conrad Winchester is a god send! And Seb Lee-Delisle is a really, really, really sweet person who I instantly felt relaxed with. But I should have pushed myself to talk more with some folk – though partly I was just valuing the interactions I was having with smart people around Robotlegs and so on.

I had the opportunity to talk with Jon Howard, who had the session that clashed with mine, at the speakers dinner. If I wasn’t already doing exciting things I’d have been hitting him up for a job for sure – I’d love to work on his team!

It’s an incredibly well organised conference. I was a little nervous about logistics as nobody had officially said to me “Your session will be in the pavilion, you need to get there x minutes beforehand” – but the number of people who’ve got knowledge of how it all works from previous experience means that my peers were able to gently steer me in the right direction and it was all very smooth and felt like a very collegiate way to do logistics.

Respect to John, and all those who worked hard to deliver Flash on the Beach. A new name is in the pipeline but I won’t hesitate to go back, whatever they call it, as a speaker or as an attendee. It’d be great to see more techy women there in future, but the blissfully empty women’s toilets were a pleasant novelty!

Here’s my take on the sessions I got to attend…

DEVELOPER CONSOLE FOR FUN AND PROFIT - ANDREAS RØNNING

This was a really interesting presentation thwarted only by the fact that it needed to be at least twice as long – every feature Andreas Demonstrated just filled me with questions.

To be honest I had a slightly negative bias against the console as a debugger before Andreas began – I’d seen how technically impressive it was in the video of his 2010 Elevator Pitch, but I’m an ardent TDDer and only fire up the debugger a handful of times each year, preferring to write assertions to explore odd behaviours. As it turns out, the console is much more than just a debugger.

In essence, the Doomsday Console gives you a ton of levers for tweaking your application at runtime. This is the bit that feels exciting!

I totally agree with Andreas’s assertion that text is the best format for this (usually), and the power to do anything from shifting object positions to spawning new processes and objects opens up great possibilities.

I was eager to see examples of actual, non-visual bugs that the Doomsday Console gives you the power to squish, although dozens pop in to my mind already, but this would have taken a second session – so I’ll watch the project for examples over the coming months.

That said, Andreas’s presentation was running in flash, and a problem with the screen setup led him to use the console to hack the position of his content nearer into the middle of his screen. I once did a 3-screen projected animation for the ‘Gothic Nightmares’ exhibition at the Tate gallery, and the capacity to do these tweaks without having to recompile between changes would have made the very painful alignment process a breeze.

I expect that most attendees are, like me, still having regular ‘oh, and I could do *that*!’ moments fairly frequently.

Andreas is also a very lovely guy who generously lent me his Mac->VGA adapter for my session. Phew!

FLASH 11: GET READY FOR GAMETIME – ROB BATEMAN

NATURAL FEATURES TRACKING AND IMAGE PATTERN DETECTION / RECOGNITION – EUGENE ZATEPYAKIN

Sadly I didn’t manage to get in to either of these sessions – both of which had to turn away huge crowds. On the plus side, I got to have some interesting conversations with various folk about very geeky things. There were various ‘not good enough’ murmurings, but it’s hard to know how John could better organise it – and as a speaker I did appreciate that people weren’t coming in after my session started.

SCALING & ORGANISATION: MASSIVE FLASH-PROJECTS – HOW TO BUILD A TOP 10 GAME ON FACEBOOK? – WOOGA

I *loved* this session. I just absolutely *loved* it.

Wooga are pushing out great Facebook games and expanding at the rate of adding a couple of team members each week. How do they do it? Well, basically they run it like an open source project (though they didn’t describe it using those actual words).

There are no project managers – everybody is a maker and the team collaborate to make collective decisions.

They use a broadly Agile process – frequent releases, short meetings, constantly moving goals reflecting what they learn from the process and product feedback after each release. They’re using the Agile manifesto – the spirit of Agile, not a rigid set of instructions.

There are no ‘rules’ about project processes – except that they are using TDD, version control (even for artists), and continuous integration to keep the gremlins away.

I won’t lie, for me the best thing was that it called BS on the idea that game development is somehow special and different and that practices such as TDD, mocking, CI and so on don’t apply to games.

I grew up around jazz musicians and still do work with NYJO, the National Youth Jazz Orchestra where crazy talented people get their first taste of life as a professional musician. They get to improvise and shine and do all kinds of mind-blowing stuff, and they also spend a ton of time practicing scales and arpeggios. Good practices set you free – they don’t constrain (unless you’re doing them wrong).

I heard a few discontented murmurings – people felt they had been misled about the session content. But the title says it all. The audience might have hoped it would be about something cool and awesome and magical that they’d never seen before, a silver bullet or rainbow-crapping-unicorns. But it’s not. It’s about mocking your service layer, giving your teams respect and autonomy but also responsibility to follow practices that avoid software-lock, and not cutting corners.

Wooga – I love you.

THE TALE OF A TRAVELLING SALESMAN AND HIS FOUR COLOURS. – JOA EBERT

You may or may not already know this, but I used to be one of those people on TV. As a result I have shared space, done interviews and generally hung about with a lot of properly famous people. I generally don’t get star struck.

I am star struck by Joa. I was even standing next to him while I was talking to John (FOTB organiser), and I was too shy to thank him for his work on Signals, or even say hello.

Anyway – Joa is part math genius and part comedian. “Every morning the same disaster, how should I put on my clothes?” – followed up with one of the most brilliantly clear illustrations of a practical application of graph theory.

His session was just pure joy for me – no doubt partly because he feels joy himself when he implements beautiful solutions. It reminded me of the recent neuroscience data that has shown that ‘truth’ and ‘beauty’ feel very similar to our brains.

I came away wanting to graph the world. And specifically it gave me insight into a couple of Robotlegs 2 problems we’re tackling, and how these might translate into a graph problem that has probably had papers written about it in other fields.

I’m a math geek so in terms of pure mathematical theory there was little I hadn’t met before, but there was something in the way Joa conceptualised and illustrated it that felt very fresh.

Here’s to whatever FOTB reappears as in 2012.

I was lucky to get it out of the way early – and to have plenty of friendly faces in the audience.

It’s somewhat difficult to recreate the session purely as a set of slides, as the interaction (which the attendees were very generous about) was key to the experience, but I’ve produced an extended version of my slide deck which includes the main points that I covered verbally and the instructions for the exercises. Do give them a go.

If you’re brand new to Robotlegs then the slides won’t sufficiently explain the architecture – you’ll need to pick up a copy of our ActionScript Developer’s Guide to Robotlegs for that!

I’m also pondering doing a VO / screencast version, but it would run at over an hour and I’m not sure you’ll want to sit through it.

So – for now, here’s the Slide Share embed, and don’t forget to pick up your “man brain” file from this post.

man brain

I was totally blown away by Flash on the Beach. What a lot of smart, interesting people!

My full slides will follow tomorrow. I’m going to release a flick-through version that includes extra text, and a screen-cast version with voice. Thanks to everybody who made my first FOTB experience so rewarding – I’m very glad that I got out of my comfort zone and did it.

For now – a little something for the lovely people who attended my presentation on “Robotlegs 2 and your brain” – that vital missing ‘man brain’ entry file.

Tested on Mac OS X but it should work for Linux too.

Download brain.1.gz: brain.1.gz

Don’t unzip it.

Then open your terminal and type:

manpath

It’ll return something like

/usr/local/share/man:/usr/share/man:/usr/local/git/share/man:/usr/X11/man

Pick one of those paths (I use /usr/local/share/man), and check there is a man1 subdirectory.

Then type:

cp /path/to/download/brain.1.gz /usr/path/you/chose/man1/brain.1.gz
man brain

Ahhh…

(If you get a permission denied error, you may need to add ‘sudo’ to the front of the ‘cp /path/…’ line – it depends on the directory you choose to use.)