I was reading a blog post by Aidan Fitzpatrick recently, and as is often the case whilst scouring the web for endorsable blog authors, felt some sympathy for the misinterpretations or unfortunate circumstances I assume Aidan to have been through. I don’t believe the experience of trying to improve oneself and their code but failing and thus falling back to old ways, is a particulrly uncommon phenomenon. So it seems appropriate to address some of the points Aidan has raised, in an attempt to help and perhaps even reinspire those suffering silently in simular situations, fallen to the wayside in their endeavour for excellence.

Clarity

There is often some confusion with regards to clean coding. As a senior developer mentoring juniors, it is crucial that we expose and pass on the knowledge of OOP design patterns, SOLID principles, Test-Driven-Design, and the vast array of practices. James Old’s blog post bad code is the first step to good code fairly identifies that Junior developers will regularly misinterpret these practices, stumbling through their work attempting to correctly apply newfound knowledge.

This is where your years of being a developer truly shines; a senior developer knows where to draw the lines. The last thing we want is to end up with an enterprise fizz buzz. But that doesn’t mean we should sacrifice any code quality! The patterns and practices must still be used, the principles adhered to, the tests written first. You’re a professional, not a script kiddy, right?

The Best Way

It’s a question we’re often posed.

“What is the best way to do this?”

That answer differs by so many factors, an experienced programmer with extensive knowledge of clean coding, just knows. We’re aware of the downfalls of future proofing, but understand the extensibility afforded through clean code. We know if we just follow some very simple principles, we give ourselves the best chance of victory against the onslaught of the weird and wonderful, ever changing requirements.

The best programmers collaborate and keep up to date with the technologies applicable to their field. They’ve heard about the latest buzz, evaluated and indentified use cases, and learned when and when not to use technologies. They have the common sense to spend some time spiking and prototyping before introducing new dependencies to a product. They have the ability to communicate concepts to the team and the mental strength to accept the outcome of collaboration.

Most importantly, when the best way at the time, is no longer the best way for the current requirements, a good developer knows to refactor.

Being Prepared

Projects will regularly fail if you dive face first into an area or technology for which you have no expertise, regardless of how clean your code is. You’ll spend great portions of time refactoring as you adjust application structure to the API you’re learning. In such a case, it will feel like following test first was a disatrous decision, sweeping structural changes will require constant changes to the tests.

The fix for this isn’t to drop the tests or start writing rubbish code. It’s to be prepared. You wouldn’t dive into a dark pit face first. You’d examine the pit and make sure it’s safe to proceed.

The product, API, technology, or so forth, you’re trying to work with should have been evaluated and researched. Depending on the complexity, a quick glance at a Getting Started page or 10 minutes spiking some code might well be enough to get you going. In other cases, reading extensive documentation, many short (and quickly disposed of) spikes, discussions and research is required. Be prepared, the time spent will always be worth it.

Quick code

Inevitably, bugs leak through, or agreed upon behaviour is contrary to end user intent. The customer will always be a part of your feedback loop, and development methodologies such as SCRUM assist us in keeping that feedback loop as short as possible. In startups, putting a product out there might be the best way to perform your market research and determine product viability, but in all industries, it’s important that we get a product out of the door - even if that door is internal to the business.

Even the seemingly well informed make the mistake of assuming clean code is slow to write code. My response to that is very simple: practice.

As mentioned in a previous article, writing good code doesn’t break even in value over time. Once versant and well practiced in clean coding, it should be at least as quick as dirty code, if not faster. You just have to suck it up and practice; see it akin learning to touch type again. It becomes muscle memory, with IDE’s capable of generating huge amounts of code structure from the tests, saving you from having typed them directly.

The value added by maintainability, extensibility, and quality of clean code is not used to break even, but to vastly outweigh consideration for any alternative approach.

Doom and Gloom

It’s certainly not all doom and gloom. Aidan raises many points that I agree with such as the latest technologies not by some bizarre coincidence being the best technologies. Technlogies, frameworks, platforms, all have pros and cons. Adopting third party software blindly can obviously lead to downfalls, as can spending inordinate amounts of time researching said software.

The trick is to find a good balance. I’m fortunate enough to be surrounded by not only passionate individuals whom enjoy spending their own time looking at, and subsequently discussing the latest technology news, but also teams mature enough to say no. The time to better research, retrain and migrate existing projects to new technologies must always be outweighed by the benefit of doing so; your team leads and management process experienced enough to determine such.

Summary

It doesn’t surprise me that people struggle to onboard themselves with clean code, and it doesn’t surprise me when I encounter people reluctant to be onboarded (the stubborn, stale, and adamant few admittedly as pointless at times as online trolls).

If you really want to make it, you’ll need enthusiasm, passion, and pride. All qualities you hope to find in any person, in any role. If you don’t care, if you’re just slogging it through the days to pay the bills, perhaps consider a new career?

For those taking their first tentative steps upon the enlightened path, good luck, and don’t give up!