(This is part 2 of 3 in my series of thoughts on The Clean Coder, part 1 can be found here, and part 3 can be found here)
The second part of The Clean Coder by Robert C. Martin (Uncle Bob), is about the discipline of coding. It explores the act of coding itself, how to practice, and strategies for testing one’s code.
Here is a recap/my thoughts on this part of the book.
This is a repost from my old blog thecompilerdoesntcare.com and was originally posted in 2017.
Coding
Development or coding, as Uncle Bob calls it, is a very demanding activity both mentally and physically. It requires a very high level of concentration and has many different competing factors that needs to be juggled at the same time. Things like: the code has to work, it must solve a problem, it must fit well into the existing system, and it has to be clean and readable to other humans (and yourself in 4 weeks).
Because focus isn’t infinite, there is a cap on how long one should code in one stretch. Coding tired, angry, sad, or distracted will result in code that is either bad, too complicated, or plainly doesn’t work. In either case it needs to be reworked, and that’s a just a waste of time.
Getting some rest and looking at the problem with fresh eyes tomorrow is always a better idea than thinking a 14 hour uninterrupted coding session will solve all your problems.
Since I did my master thesis I have not had coding sessions like this (my place of work strongly discourages days longer than 8 hours, for the very reasons mentioned above), but I remember back at university when I came back in on the morning after nights like that, to a hot mess of code written by a tired, groggy, overworked Mikkel, that was complete garbage (the code and, let’s face it, me).
Nothing good came of it, and I will never do work like that again.
The Zone (Flow)
Uncle Bob discourages getting in The Zone or in other words the so called Flow State described by psychologists. When you’re in The Zone you forget about time and place and focus completely on the task at hand.
He thinks it removes focus from the bigger picture which I kind of agree with. However I still don’t like the advice that one should avoid The Zone altogether. Sometimes when you just need to write code for something that is easy to understand and well-defined, The Zone can be great, because you have already made the big-picture decisions, and now all you have to worry about is implementing them. In those cases I thoroughly enjoy The Zone, and am definitely more productive in that state.
Another thing that is distracting for Bob is music. And again, I have to say that if I’m am not alone in a room, music is necessary for me to focus properly. Without it I will pick up a word unconsciously from a conversation across the room, and my focus will shift away from what I’m doing.
I wear noise-cancelling headphones so that I don’t need the music to be loud in order to drown out background noise, and I listen to a lot of different styles of music from classical to electronic to acoustic to Carl Franklin’s Music To Code By. Mostly stuff without lyrics though, as I do find those distracting.
Being Late
As he says: You will be late.
Everyone will go over their estimates sometimes. Software is an inherently difficult thing to estimate, because no one can accurately describe everything up front. But we can still try and look at risks involved solving a problem and estimate accordingly, and not just imagine the perfect problem-less scenario and give the best case estimate.
Going over estimate is not something you realize will happen an hour before the deadline. It is usually very clear much earlier. As soon as you realize that the original estimate won’t hold up, it is your responsibility to let the appropriate people know – even if it won’t be a comfortable conversation. What you shouldn’t do is to let them talk you into trying to deliver on time anyway. i.e. rushing. Overtime might be the answer if the deadline that matters is a date and not an hourly estimate, but even then, it should not be a decision that is made lightly. Overtime will affect many areas of your life outside of work, and the longer hours might result in less productivity – make sure it is worth it.
TDD and Practicing
For a developer to call himself a professional, according to Uncle Bob, he must be a Test Driven Development (TDD)-practitioner. What he is saying is incredibly black-and-white. He is saying that no one can be a professional unless the practices TDD at all times. I’m not sure that I agree here, but let’s explore this a little bit.
The reasoning behind it is: You cannot trust any code that isn’t automatically tested. Therefor every single line of code must have tests associated with it – test coverage must be 100% (asymptotically, at least). The only way to get that is to not write any code without first having a test for it. The only way to achieve that, is to follow the rules of TDD.
The problem is though that in many environments, TDD isn’t practical. In a perfect world, with perfect projects it would be easy, and we would all do it. But our world isn’t perfect. We work with systems where it is simply impossible, and we might have colleagues with different views of quality and craftsmanship than we do – does that mean that we cannot act professionally?
I believe that professionalism is as much a mindset as it is a set of practices. Saying only developers using TDD all the time, are professionals, is like saying a doctor can only be a professional if he only operates in a sterile OR in a high tech hospital. What about the medics in combat zones, that saves soldiers with bullet wounds? What about doctors in third world countries saving lives in mud shacks? Are they not professionals? They work with what is a available to save the most lives possible – they adapt to the circumstances in order to do the best work they can.
I still agree that we should test our software as thoroughly as possible, but it is a fantasy to believe that TDD can be practiced at all times.
That doesn’t mean that we shouldn’t practice though. We should practice our craft at all times, and strive to get better at writing good testable and tested code. We can do that with personal projects and katas (more on that in another blog post), we can improve our skills and knowledge by listening to podcasts and by reading books and blogs. We have to stay sharp!
Conclusion
I believe that being a professional is more about how you think and what your goals are, than the tools and methodologies you use. I think professionalism is producing as good code as possible under your current circumstances, and always taking steps improve the codebase you are working on.
To be able to achieve this, it is important to be well rested, clear of clear mind, and not to rush, which means you need to stand by your estimates and not make promises that will make you write sub-par code. Honesty is key here – don’t try to get out of an awkward conversation by making a promise that is impossible to keep. That is unprofessional.
To always stay sharp a professional needs to practice his skills and expand his knowledge. There are many ways to do this, such as personal projects, katas, podcasts, videos, books, and blogs. In my opinion we should spend quite some time outside of work on these things, in order to become and stay the best developers possible.