Reading and Learning 'Clean Code' by Uncle Bob #Day_1

This is going to be interesting, I was thinking of writing a blog for so long! I had so many ideas and topics I could talk about and here I'm starting with the most unexpected topic I thought I would ever take. As a coder, I like to code (pulling off irony and cliché at the same time?) and I also like to solve problems and puzzles (pfff is she serious?). Ahem..and I also like to read a lot, to be honest, I read a lot more than I code (perhaps that's why Coder AFK suits me). So today, I have brought something from my library for the coders, no it's not fiction, and no it's not about snakes (I'm a python sucker). It is simply about 'clean code'.

Clean Code

"Far too often, 'software engineering' is neither engineering nor about software".

- Bjarne Stroustrup

When Stroustrup said this, he was talking about certain things, more specifically, he was 'worried' about the actual process of delivering the software and its maintainability. He talks about the possibility that useful code can get lost (lose the essence of being good) in lots of processes that engineers encounter in software development and delivery. Even in these processes, there are not just engineers, there'll be a manager, an HR and perhaps a legal team and whatnot. Anyways, as coders, programmers, and software developers, we need to understand how to provide less friction in all the processes and also how to smoothen collaboration with our fellow engineers. I used to think about these things in a way, as I value understanding between the team players. But these thoughts were often put down by my peers, as they said that what matters is that your code should just work and you're successful. You should know as many languages as you can, and make things work. Now I seriously wonder why I ever paid attention to these narrow-visioned people. I was so happy when I came across the Clean series by Uncle Bob.

These are pretty thorough books discussing what is clean code, what is clean architecture, who are clean coders, how to reach all of this, etc. So, I started to read two of Uncle Bob's books. These are:

• Clean Code: A Handbook of Agile Software Craftsmanship

• The Clean Coder: A Code of Conduct for Professional Programmers

Yes, I'm reading them simultaneously but that's my problem. Since these books are pretty big, I will share my interpretations, opinions and suggestions through my blogs as I travel through these books. The first stated book focuses on our product, the code. It addresses the most common problems we face, "Why I don't understand this code?", "Why I don't understand my co-worker's code?" and "Why I don't understand my own code?". The issue may not be your understanding but the code which is probably difficult or complex to understand or even, though accepted by the compiler, is unable to give a clear picture of what is it actually doing. This is where the problem begins and now it's gonna mate with itself. And that's my hideous way of saying that your problem is going to multiply as the code grows.

Imagine, you are in a hackathon with a great idea and knowledge of tools you can work with. You start the development with your team. Everything starts well, you know what you want to do and the collaboration starts. But then somewhere, for some reason, everyone is stuck at a line of code. Suddenly, unable to identify the problem with it, one moves up the code and the other moves down. Then one is checking what a particular function is doing, and suddenly they all are unable to understand. Some of you maybe didn't even have to imagine, you just had to go back in memories. What I'm trying to say is, that we have been in similar scenarios, and the problems we have faced can be greatly avoided in the future by improving our craftsmanship (Boy, I love this term, the word itself is so beautiful and it appreciates elegance and efficiency). Here I have attempted to make you understand the importance of clean code, a code that a smart human can understand. Yes, no offense but we don't need to dumb down the code to its capacity, just to that extent where we and our co-workers can make sense without any confusion. This is what I understood through the first pages of the book 'Clean Code'. Surely, I'll go into details, probably chapter by chapter but not altogether in one blog. And so I plan to share things slowly, blog by blog. I want that we, as a community, don't just learn these things like one-shot tutorials, rather we imbue these things in our minds and become better programmers.

I came across lots of wonderful quotes by some well-known programmers while reading the book. Here I'm gonna share the one which really touched my heart. Not the whole quote though, just the line which made me go 'ah' in realisation.

Clean code always looks like it was written by someone who cares

- Michael Feathers, author of Working Effectively witg Legacy Code

This is what I like about our community, whereever today exists a clean, elegant, efficient code, there was a caring author behind it.

The Clean Coder

Now, talking about the second book, which states itself to be a 'code of conduct'. At first, I thought that this is going to be like a sequal, and will have further codes, case studies and explaining some more techniques from the 'ah' point of view. But it was something else this time, and to my surprise, I absolutely fell in love with the attempt this book tries to make. In other words, I highly appreciate what this book is addressing upon. The first book talks about how to make the code clean and why is it necessary, on the other hand this one talks about how to make the coder clean and why is it necessary. No, I'm not commenting on lazy coders who refuse to shower (but please guys shower). This is more about fitting in the sector effectively and firmly. I'm just at the starting of the book and I came across two case studies. One of them was pretty heart-wrenching, it includes people literally dying and no it's not one of my obnoxious jokes, I'm serious. After reading them I could get an idea where this book is leading me.

You can have the greatest idea or the greatest solution to a problem or you've detected the greatest threat there can be, but if you cannot effectively convey the same to the related parties, your whatever greatest thing is as good as virtual, not a reality. So far, my interpretation says that the case studies were highlighting the everyone-knows-but-no-one-talks-about-it fact that most of the engineers are not able match the professional standards of collaboration, management, planning, negotiation, etc.

Imagine, if all these engineers were also acing professionalism in the sector, how many things we can get done? how many problems it can solve? are you able to understand why this books inspires me so much? To my understanding, this book is going to be a personality development and enhancement book specifically designed for coders. One can take it as a blueprint and then create a mindset of a coder. I'm not saying we need to agree with everything written in these books and everything will be useful to everyone but they do motivate us to think and ponder upon these philosophies. I believe in some way or in some quantity, these books can help each one of us to transform and become better programmers.

I take leave now, I want you to ponder upon these, come up with your own ideas and opinions. Let me know in the comments what do you think or what your strategies can be for the same. Soon, I'll talk more about this.

But...who is Uncle Bob?

It is not me for sure, Uncle Bob is the author of these books. I know, right? Well, he calls himself Uncle Bob in the book. I would search about the origin of this nickname and share it with you guys. The actual name of the author is Robert Cecil Martin, he's an american programmer, instructor and someone who is famous for promoting agile practices and designs. Martin indeed has a lot of experience and since in his time they dealt with good amount of low-level and assembly languages, it is pretty sure they know their way around better than we do. And I like to learn from those instructors who are experienced and funny. He makes jokes too.