Lately I’ve been thinking about why I want to be a software craftsperson. Right now I feel like the luckiest person in the world to have got this apprenticeship. But I know quite a few developers who, if they were sat where I am right now, would not be so happy. It makes so much sense to me to aspire to write clean code, but for some others, clean code is not an aspiration, it’s not really anything. It’s a phrase that doesn’t have a whole lot of impact on their code. Obviously I can only talk about some of the developers I know, and that’s not yet a giant number, but it seems so strange to me to have such differing opinions on the meaning of quality code with people in the same industry as me.

I think it does come down to what quality code means and what it means to be a good developer. I wanted to train to be a craftsperson because I share the view software craftsmanship holds of quality code and, to me, being a good developer means consistently delivering what is asked of you. At 8th light, high quality code is what is asked of me, and I am doing my best to learn to deliver and improve. But I wonder what would have happened if I had ended up somewhere else, where the marker of quality was different. For some developers what they are asked for is code that works, fast. Of course, I am still delivering working code, but I know, with a small program or kata, I could maybe get it working faster if I didn’t spend time testing. I’m not actually sure if that’s true, because I am really good at breaking my code without meaning to, and I don’t know how I would go about fixing it without my tests to guide me. But anyway, a better programmer than me could probably write a program without tests faster than they could write one with them. And what if this was what was asked of me? Would I still advocate TDD? Would I still spend so much time thinking about my design and how to refactor?

I was taught to code with TDD in mind. I was aware of the red, green, refactor loop, but I would rarely refactor. When I was just starting out, I thought that the refactor stage was superficial, just a quick tidy up of your code so that it would look nice to anyone who saw it and you’d look really clever because it was so neat. I didn’t care about that. If my code worked, passed all my tests and did what I expected it to, there was no way on earth I was touching it again. Or even looking at it. If I got something to work, that was it. It worked. I had finished. Backing away before I could break it.

Of course, with only two weeks of coding under my belt, I just didn’t know enough to really understand what I was doing, let alone how to refactor my code. It took a while to really see the benefits of clean code for me, but I got there in time. It was probably when we started working on group projects that I understood how important it was for your code to be readable. Previously I had worked with a pair, but the majority of the time we would be working through a walkthrough so when it came to starting with a new pair on a new codebase, it was very unlikely that their code would be any different from the one you were just working on.

This all changed when we were set loose on group projects, and I’ve got to admit I wrote some of the worst code of my life during that hectic time. All of us were just desperately trying to get whatever it was we were working on to work. Kent Beck states that to get from the red bar to the green you are permitted to commit any sins necessary, since you will be going back to refactor as soon as the bar is green. Well, we committed a few sins in our group projects, and most of them were without the refactor stage. Some of them were without the red/green bar stages. There was some bad code.

And coming to a piece of code I’d written after a couple of days away and having no idea what it was doing, and with few tests to hint at what it’s supposed to be doing, was horrible. It was working, but I had no idea how to add to it or change it without everything breaking. I ended up with code I was not proud of, and never wanted to look at again.

To some of my friends, the idea of software craftsmanship is this fanciful, abstract notion that doesn’t quite apply to the code we write day to day. For me, it is so much more practical than that. Clean code is a tool, it is pragmatic, it works. That’s why I aspire to be a software craftsman, because I want to deliver code that works, and the cleaner my code, the more well tested it is, the better it works. And why do something if I don’t want to do it in the very best way I can?