“Building Intelligent Applications” workshop: to pair or not to pair?

I’m really excited to be speaking and giving a workshop at the Play / Beyond Tellerand conference in Cologne, April 24th – 27th. This conference used to be FFK, and I’m gob smacked to be among such a stellar list of speakers, and will no doubt be far too shy to speak to any of them (except Seb, who is equal parts digital-genius and teddy-bear).

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 choice of Python is not accidental: it’s the language in which much of this kind of work is done, but just as importantly it creates a level playing field between experienced programmers who typically work in other languages, so we can focus on concepts and not AS3/js syntax.

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 deeper insights

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.

Pairing is an opportunity to focus on alternatives, not just consensus. You can think of it as A/B testing for your brain: the more paths you consider, the greater the quality of the solution and the depth of your understanding.

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!


About the Author

I'm an actionscript programmer living and working in a tiny village in the Yorkshire Dales, UK. I used to be a TV reporter, but my inner (and often outer) geek won. I also write stuff. Most recently Head First 2D Geometry.

Visit Stray's Website

Share the post

Delicious It Digg this! Stumble this! Share on Reddit Share on Buzz Share on FriendFeed