One of the driving forces of “Clean Code” is that while it takes a certain amount of time to write code, that same code is read many times. Clean Code is aimed at reducing the reading and hence understanding time of the code.
We recently had a practical session, as part of our continuous learning practice, on TDD. After the first few tests, Doug got into some serious refactoring to make the code clean. As Doug progressed, I found myself becoming increasingly frustrated with the numerous methods, many of which had 1 or 2 lines of code, that he created.
I started trying to understand what Doug was trying to achieve and why I was finding it frustrating. As we discussed the aim of Clean Code and how Doug would “read” the code, it dawned on me that the difference was in detail. Doug would read the initial method, accept the definition inherit in the method names called, and drill down to those lower methods only when required. I on the other hand found I needed to drill down through the many layers of methods to better understand the initial method.
It was this difference to how we went about understanding a program that was making his extreme Clean Code approach work for Doug and not for me.
In previous lives both Doug and I have done a Myers-Briggs assessment and interestingly he is an N while I’m an S. In the Myers Briggs assessment, the Intuitive (N) preference person works from the “Big Picture” drilling down to detail when required, while the Sensing (S) personality is the opposite.
When I did my Myers-Briggs assessment we discussed the need, when presenting to a room of people, to take into account the various understanding approaches inherit in the S and N preferences. Similarly, when you are teaching, my wife informs me, you need to take into account the learning styles people have. For example Auditory versus Kinesthetic.
So, when you are “cleaning” code, take into consideration that the people reading it in the future, may not approach it the same way you do. You need to strike a balance between cleaning up the code into more manageable methods, but not to the point where you have many layers of increasingly smaller methods. Not everyone will save time reading this code, but rather it will take them significantly longer.
I recently watched a TED talk by Julian Treasure on “The 4 ways sound affects us”. In it Julian mentions briefly how noisy open-plan offices significantly decrease your productivity (I won’t spoil just how much it’s decreased). He goes on to say that if you find yourself in one of these, put on some headphones.
