So the idea is before you’ve even starting writing your task, you must think about what it is that your task should do, what is the behaviour of your task that you want. And then you write something that describes that behaviour and ensures that the result you get out of it is what you expect. Then you write the task and should tick a couple of magical boxes. One is that if you can’t write a sentence starting with the word should, the chances are there’s another task that should be doing it.

I was talking to somebody. I’d written an equals methods, that shouldn’t really have been there but I thought it should at the time.

I remember that when I was on the support team, most of the time we spent, we were basically sitting heads down looking at screens, looking at these bugs all day. We were trying to work out where they come from, whether it was just a that a till had crashed and the system was… you know, maybe there was a bug, maybe it was just a known fault with one of the many third party systems we were talking to.

Most of our time was spent diagnosing the same bugs over and over again. Only there were eight of us, so I might see the same bug once every two weeks. Somebody else on the team who had been there longer had almost certainly seen it before. I thought wouldn’t it be great if we paired and passed that knowledge around ourselves so that we are all able to diagnose these bugs really quickly and didn’t tend to spend two days doing it. And I told one of the other guys on the support team this and he said “But that’s your job!”

My first project with [employer] was for a retail client. It was great. We wrote the retail application that sits on the tills of the stores and talks to their back end, deals with stock, things like that.

It was not the most Agile project in the world, but it was years and years long, you know. It was about four or five years, it’s still going in various forms. And people are using it. I remember I came in and within a week I was writing code, pairing with somebody. And one month later that code was in production. I was like “I spent 7 years development work, nothing’s ever made it and here I am, I’ve been here a month and it’s in!”

I was working for a company by Heathrow Airport. This one evening I was finishing something up and I was still there at about, it must have been just before six or seven, something like that. Suddenly everybody had stopped work and they were all standing by the window and I said “What’s going on?â€? They said, “Look, you’ve never seen this.” I went “What?” And they said “Oh, this is why we stay late.”

And I went up to the windows with them and Concorde took off and it was extraordinary. I’ve never seen anything like it, just in terms of “Wow! This is what human beings can do.” The noise, even through sound-proof buffers, windows it’s incredible, you can feel everything vibrating and you can see it take off and when it took off at night, you could just see these huge blue flares of jets out the back and it took off and when it had gone and cleared the horizon you could hear the car alarms all going off in the car park outside.

I remember the first Java project we got put on, that was amazing. It was a team of four devs. We were producing set top box software, so it was almost J2ME, highly embedded. We wrote all the code using VIM and we used Win-CVS. We just checked out the code and we checked it back in again. We resolved the mergers between us and all using the same code base; no branches, nothing funny. The simplest project imaginable. We had some really just stupid rules in that company, like every line of code should have a comment. I remember doing full Java docs for every single method I wrote and just going: it’s just so obvious, why can’t we just miss it out for this one? But we weren’t allowed to because of the company policy.