We kicked off SoCraTes UK 2013 with lightning talks, and it was then that the theme of the conference was set. They all influenced the coming days in some ways (especially Chris’ five-minute rant on bad code and terrible naming, accompanied by a bottle of Jack Daniels), but the one that stood out the most, especially me, was Erik’s. He spoke about the process we go through when we make a mistake, and he gave me two words that had been missing from my software development vocabulary: personal responsibility.
The whole conference, I was searching for the answer to the question: what is my responsibility? We talked about refactoring, legacy code, architecture and all the other practices that we take for granted are good. Sure, they’re nice. For me though, it wasn’t enough. I’d established early on that I thought our real collective values began with a single word: think. It’s a beautiful idea, but I had a problem: I didn’t know where to go from there. How do I define “thinking”, and how do I explain it to the unenlightened software developer standing next to me at the pub? These questions started to expand when I thought a little about pragmatism: How do we know when we’ve tested too much? Do we need to do this elegantly? Will refactoring this benefit me in the future? How much time do we have?
My internal monologues kept bothering me up until a discussion after the end of the conference with
a chap from the Midlands about Jean-Paul Sartre, existentialism, self-awareness… you know, all that good stuff you get sunk into when you’ve had a few pints. He explained to me that there’s an issue with self-awareness: it’s depressing. Once you realise you’re a very small thing in a very big universe, you start to question the meaning of it all, and a lot of people come to the conclusion that there is no meaning. We can draw parallels to this in the world of software development: once you’re introduced to the world of clean code, agile development and XP, you can’t help but start to evangelise. Even the most anti-social developers I’ve met have tried to introduce the concepts to their teams. It’s infectious. And when you (undoubtedly) fail to convince people, you might start to wonder what the point of it is at all. Finding meaning in your work only carries you so far.
It was at that moment that I realised something: I didn’t care. I was asking the wrong question. It’s pointless wondering what your responsibility is if you don’t know who your responsibility is to. The answer to that question was easy: it’s me. I’m responsible, first and foremost, for making myself happy. All I want to do is build things, and it’s not so important if they’re not used, never heard of or completely neglected afterwards. I want to be like those people who draw amazing works of art in the sand on the beach, and the next day, when it’s washed away by the sea, they go back and do it again. It’s why I love katas and code retreats: nothing is better than throwing away your work so you can do it better next time.
It’s important to deliver value to your customers (whatever value is; I’m still not sure), but it’s also important to have fun along the way.