Feed on
Posts
Comments

I just did a code retreat in lovely Floyd, Virginia.

You should.

For those who haven’t yet, a code retreat is a long day of programming, constrained in such a way as to create an open-ended opportunity to learn.

The formula is simple: we do six sessions of paired TDD. Each one is on the same problem, but with a different partner. The code is destroyed at the end of each session. That is, each session starts entirely from scratch.

That’s all there is to it, or so I thought going in.

Getting Hooked

The remarkable effect of the constraints is to focus a very high intensity onto the problem domain and its potential solutions.

You care.

The problem itself is readily understandable, but its potential solutions are really not. They are just one hair too complex to hold in your head all at one time, which is brilliant.

A toy challenge would not work nearly as well.

On the other hand, if the challenge were harder, you wouldn’t, or at least I wouldn’t, approach it with the easy certainty that you know the solution already. The experience wouldn’t be nearly as valuable without the scorched arrogance.

Test First vs Test Driven

The certainty of solution starts boiling off in the first round, and somewhere in the third it runs out altogether.

This is good, partly because the smell of burning ego is good for the soul, but also because it makes it much easier to open one’s heart and mind to learning.

Once I got opened, I learned many things, some small and some not-so-small.

After the sessions, we talked about what, if any, lessons were learned. Perhaps the single most common statement was that the participant learned that having a pre-formed solution in mind could cause lots of pain.

Corey Haines calls this ‘pre-conceived solution’ thing ‘test first’, as opposed to ‘test driven’. It’s an excellent distinction.

The idea is that in test first you solve the problem in your head, then write a test to force that solution, then type it in. Truly driving by tests, on the other hand, means typing in the test with beginner’s mind, and starting to solve it only after you’ve written it.

That’s exactly how it should be in our daily work.

Old Friends and New

It was fun to see some old friends, my pal George Dinwiddie, and my until-now-twitter-only-friend John Stoneham. I knew Corey Haines from the scene, but mostly also on twitter, and it was a blast to get so much good time with him.

But it wasn’t just my old friends. Many of the folks there came from one or more of the sponsors. The local hosts, Gustin Prudner’s Entryway, did an amazing job. They procured and prepared two excellent venues for our sessions, and everything went off without any hitch.

I won’t list the new friends I made, but I was delighted to hang with so many people who clearly care about excellence in software development.

Geek Joy — *Shared*

The most important lesson was one I re-learned rather than encountering for the first time: to share geek joy is delightful, intense, and absolutely revitalizing.

I feel like I need to rush right out and do good geek work today.

I’m already on record for saying that what the industry needs most is to learn how to intertwine geek joy with business value. But to be reminded so forcefully is just terrific.

Go Sign Up Now

It’s Cheap And Amazing!

Leave a Reply

AWSOM Powered