I lied. In my last post, I wrote about how we’re all software developers. Well, that’s a start, for sure. And a good one. If everybody in the team thinks of themselves as part of software development then you’ll be on track to build something efficiently as opposed to building it first and testing it afterwards, then building it again. But here I want to talk about being a software craftsman. This is about taking it a step further. It’s about taking pride in what you do. It’s about using the right tools for the job. It’s about separating yourself from everyone else who just turns up at work each day, writes code and doesn’t really care about it afterwards.

So, whats a software craftsman? Well, I’m sure everyone has their own definition. For me, it starts with caring about what you’re doing. If you haven’t read it already, I invite you to pic up a copy of Clean Code by Uncle Bob Martin and give it a read. In fact, if you don’t want to buy a copy or take the time to read it cover to cover, I would still encourage you to click here for the Amazon Kindle link, click ‘look inside’ and just read the first chapter. In it, Uncle Bob enlists some of the greatest software craftsmen of our time and asks them what they think of when they think about writing clean code. Just reading that chapter will change the way you approach your work. They all have great opinions but, in particular, Michael Feathers‘s definition jumped out at me. For him, “Clean code always looks like it was written by someone who cares.”*

I care about my code. I didn’t always. When I started to code, I used to complete a job and then move on, not really worrying about it after that, as long as it worked. These days, I care very much about what I leave behind. Like Michael Feathers, I want whoever looks at my code next to sit there at their desk and nod their head in appreciation. I want them to try to think about ways to improve it but not be able to. Good developers write code that works, then make it better. Red > Green > Refactor. I had that drummed into me by Ian Cooper a few years ago and I need to thank him for it. Write a failing test, write code to make it work (without really caring about the quality of it), then make it good. It’s the end two parts that most people, even those who are keen on test driven development, seem to merge into one. They’ll write a failing test then write code to make it pass then move on. Because they only have the one step, they try to make their code good first time around. This doesn’t make a good system to inherit. These days, I’m quite strong willed about doing a good job. In my latest contract I remember being asked to do a job quickly and refusing to cut corners. As a contractor, it’s even more important to me as I probably won’t be able to defend myself when the next person looks at my code and thinks “What idiot wrote this?”. These days, if someone wants me to do a job then I’ll do it well. As I said at the time in my last example, if you want someone to write some ‘quick & dirty code’ then I’m not the right person for the job.

So caring about your code is probably the biggest thing to take away from this post. Whether you’re a Ruby guru writing complex meta-programming or a tester writing Given…, When…, Then… scenarios, make them the best you can.

My everyday kit

The second part of this post is probably slightly less important, but still important enough to read. So don’t go away just yet! Take a look around you. I’m assuming you’re at your desk at the moment, most probably at work. If you’re not, do this the next time you’re there. What do you see? Do you see equipment and peripherals that will enable you to be the best you can be? Or do you see a small screen, a cheap membrane keyboard and a pc that takes longer than it should to do anything?

For some reason, in my experience, developers seem to settle for less than they should when it comes to equipment. In my last post, I made the analogy (well, stole the analogy) about building a house and writing software. I’m going to make the same analogy here. Go to a building site and look at the equipment they’re using. It’s probably better than your toolkit or mine. The next time you go and have your hair cut, ask your hair dresser how much their scissors cost. Other industries use equipment relative to what they’re doing. If they’re working with something day in, day out then they’ll want it to last and they’ll want it to perform. For some reason developers often just take what’s given to them.

I’m not one of them. I like to provide my own kit when I work. That’s not always possible, but I’ll always provide my own peripherals if I can’t provide the machine itself. If I’m going to be sat at a desk for hours every day, I want to enjoy it. I want equipment I can rely on, that isn’t going to break easily and that makes a difference to my performance. These days, I tend to carry around a Das Keyboard 4 Professional wherever I go in a special Das keyboard sling. It’s a proper mechanical keyboard with gold plated Cherry MX switches that sound and feel amazing. It makes typing a joy. I have a Roccat mouse that I can change the sensitivity on whenever I want. A feature I’ve had on previous mice that I can no longer do without. I have a precision Razer mouse mat. Sure, they’re all more expensive than regular items, but not *that* much more expensive. You can pick up everything I’ve mentioned for under £200. You could do it for a little over £100 if you want a cheaper mechanical keyboard. Developers are paid reasonable salaries. Spending £200 on equipment that will last you a few years is an investment. Fortunately, in my current gig we have nice 4K screens, but even then, you can pick up an amazing 28″ gaming 1ms response screen for under £300. What about pairing? If I’m pair programming, I’ll have two keyboards and two mice. It takes a little while to acclimatise to both being in control, but you’ll soon be fine with it and will work better than when you just have one. All that does sound expensive, I know. But, it’s all about priorities. I drive a 12 year old Passat that’s done over 150,000 miles so the money I save on my car, I can spend on gear to help me work efficiently.

And what about software? C# Dev? Are you using Visual Studio without add ons or are you using Resharper? What about scripting? Do you use any old text editor all the time or have you taken the time to evaluate and choose the best one that suits you? Personally, if I’m coding in C#, I like Visual Studio Professional with Resharper and if I’m coding in Ruby, I use a mixture of Vim, Atom and RubyMine. Sure, you don’t *need* a full IDE when writing in Ruby, but it makes refactoring a whole lot easier. If I should rename something, I don’t want to think “That’s going to be a pain finding it in multiple files.”, then not bother. I just want to press F2 and have my IDE change everything for me.

All of these things make a difference to how I write my code. I want to enjoy typing. I want to go to work and look forward to the nice clicky sound of my keyboard. I want to marvel at the quality of my screen. I want a development IDE and a terminal and a web browser on my monitor all at once and not have to alt-tab every 15 seconds. When I come to work in the morning, I don’t want to be thinking “You know what would make my job easier? Better equipment.” I want to go to work knowing the only thing that could make my job easier is if I were better at writing code…

_______________________________________________________

*Seriously though, do yourself a favour and buy the book. You won’t regret it.