It’s amazing how easy it is to be a programmer/developer/code monkey without having to do it properly. I got my first programming job when I was 17, a whole ten years ago, and now after recently reading Clean Code and Refactoring to Patterns, I can’t help but wonder what the hell I’ve been doing all this time. I’ve been writing code, but I sure as hell haven’t been programming. Looking at the code I’ve written as recently as only a few weeks ago now makes me cringe. “Why am I calling this method here?”, “What the hell is this comment?”, “Is this a joke?!?”.

I took a job as a developer for a mobile phone voicemail to email provider four years ago. I was only there for a few months but I still feel like I learnt more about programming while there then I had previously and ever have done since. I’m a firm believer in the notion that you’re only ever as good as the people around you. If you come in at a lower level you’ll soon pick up the pace, and if you come in over those around you, you’ll soon slow down to match your co-workers. As always there are exceptional circumstances. Sometimes if you’re too low, you’ll never be able to perform to the same standard, and if you’re too high, you probably won’t stick around long enough to get bogged down. I’m in a bit of a unique situation in my present role, because I work in pretty much complete isolation from other developers. Which means I have to set my own benchmark. I remember when I started, I was still so full of energy from my previous job (the one mentioned above) that I wrote some pretty cool code, which even impresses me when I look at it four years on. But as time went by I became more and more rusty and the quality of my code decreased dramatically. I stopped reading computing books altogether and took more of an interest in general business subjects. I took an interest again when Rails came on the scene, but none of the coolness or wow factor of doing Ruby could be applied to my day job doing Java, so that area of my life still continued to dwindle. The discovery of Grails changed that to a large degree, but by then I had lost the sparkle for Rails and my code became the same mess, just in a different language. I constantly think to myself that there has to be a better way. Rails and Grails felt like an answer to a certain degree, but the same underlying issues of design and brittleness remained. While features were quick to implement, changes were slow and painful to make. Simple requests became complicated hacks built upon other hacks to fill in holes left by other feature requests. Rails and Grails, while eye openers and moral boosters, didn’t solve my problems.

I was naive and blamed the language, the framework or the previous developer for my issues. I felt that my designs were sound and the code of a high standard. It “felt” tidy and the functionality all there, neatly sectioned off into different places. But Clean Code and Refactoring to Patterns showed me how wrong I had been. Regardless of the language or the framework, without well designed, robust and agile coding practices, you eventually hit a very hard brick wall. To say they were an eye opener is an understatement. It felt more like a programming re-birth. In hindsight, all the signs of bad code were there, I had just become totally blind to it.

Not very long after reading both books, I tasked with making some changes to an old legacy Java system. In the past I had absolutely detested working on it. Everything felt like a mess and that the slightest change would bring the whole system to its knees. But I felt confident this time. I started writing tests, which I had never done before, and started using the absolutely brilliant refactoring capabilities of IntelliJ. I spent a lot of time refactoring code so that the new functionality existed, wrapped up, in a state that it should, rather then in a shoehorned/hacked state. No doubt it too me longer then if I’d just shoved it in, but the system became better as a whole for it. The long reach of the masses of refactorings I performed have left parts in a greatly improved state. Perhaps in some cases, with added complexity – a small price to pay for better testability, design and extensibility. I would rather have an added degree of complexity over a brittle design any time

Anyone can knock out code, anyone can cut-and-paste a system together if they tried hard enough, but writing code alone is a solution to a small fraction of the overall problem. Anyone can churn out new features for a v1 release, but what about v1.1 or v2 or v3. As developers we dig our own graves. Clients don’t understand why things used to happen so fast, but now it’s sometimes weeks before anything new is ever shown. Fast – Slow – Slower.

This is where good, clean code starts to come into it’s own. Code that’s light on it’s feet. Code that’s easy to move in and out. Code that isn’t a brick wall and requires you to code around. Good design and good coding practices are at the heart of delivering a robust solution. If you are a developer you need to read the books I mentioned above, or at least just Clean Code. Heck, as a developer you need to read books. FULL STOP. I know many developers who don’t read at all, which to me is just unthinkable. You maybe one of the few that shrugs their shoulders after reading something like Clean Code and says “Yeah, I know all this already.”, and if so, good for you, but even you will probably know someone who could do with reading it, probably more then once ;)