How pragmatism might impact your quality

Disclaimer

Caution: This text is very opinionated, and you might not agree with it, or have another perspective on it, but maybe you will find some interesting thoughts, which you want to share.

My Point of View about clean code

While all the clean code principles make sense and I agree with them, I also tend to think that sometimes they introduce some layer of abstraction, which is often not needed and just makes code harder to read. So, when writing code, I’m often thinking about being more pragmatic and not following the principles completely. Also, I’m a strong believer in “code documents itself”.

With that little disclaimer being said I want to share my experience of a recent code review and how it started to change my thinking about being (over)pragmatic.

The beginning

In the project I am, I was working on a service where not every part of the business logic was implemented yet, but there was a second service which would like to talk to the first service in order to verify that the communication between these services is working. So, I implemented a mock response, where some more or less valid values would be returned. I did not pay much attention to it, since it is just a mocked response and will eventually be implemented anyways:

private fun provideMockResponse(): Response = Response (
    value1 = "MockLookingAlmostReal",
    value2 = "MockLookingAlmostReal2",
    subClass = SubClass (
        subValue1 = "MockLookingAlmostReal"
    )
)

So I opted to be a little more pragmatic/lazy in this case instead of writing well documented and “perfect” code.

Once I submitted my changes for code review, I was advised to extract the values into a variable and include a comment explaining the reasoning behind the implementation.

My reaction

While reading the comment, I didn’t fully understand why this change was necessary. I initially argued that the code was fine as it was and that extracting the values wasn’t needed. This led to a call with the reviewer, during which he explained his perspective. The main points were that it’s not obvious that value1 and subValue1 are equal and that we lose maintainability, for example if we want to change some of the values. Moreover often enough you see code being forgotten without any comment why this was needed once.

My argument was: This is not needed, because it’s going to be refactored anyways and is just for testing. So, no need for perfection here, pragmatism is easier and serves the duty.

My thinking

In the end I somewhat accepted it, but decided to not do it today and because it was the end of the day anyways, I drove home. But on the way home I started to think about it. Was he really right? Was I perhaps wrong? Am I too pragmatic here, and his suggestions do actually offer some benefit?

To answer this question for me it helped to think back to the saying: “Code is being read more often than written”. Also how often have you written code, didn’t document it and came back later and were questioning yourself, what have you been doing there?
Another thought that came to my mind was, that I probably used being pragmatic as an excuse for being lazy.

These two thoughts helped me to manage to accept the code review.

My conclusion

What should you take away from this little story?

1. When you’re unhappy or even mad with a code review because you don’t agree, wait another day and take some time to think about it. You might cool down and see it through different eyes
2. When you’re being pragmatic are you really being pragmatic or just lazy? If you ask yourself this question and the honest answer is you’re lazy, then maybe you should reconsider your code. I don’t want to say that being lazy is necessarily a bad thing, sometimes lazy written code is just better, because you didn’t overengineer it, but you always should consider that it might affect quality and maintainability negatively
3. When writing code keep in mind that you’re the author, but you’re probably not the only reader and perhaps not even the person that reads this code most often. So a comment to document some decision that were made might be worth the slightly less readable code

I hope you liked this little story, can relate or might have even taken some learnings from it. Before coming to the end of this little article, I must honestly admit, that looking back at the example from above I would do it again, because I still think it would have been fine. I would add a comment though 😄.

But I also have to say, that I’m constantly learning and evolving my coding skills, and it definitely started some thought process. So maybe there will be a part 2 of this story! Stay tuned and read our other more technical stories. (By Jonathan Merkel)

How pragmatism might impact your quality was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.