Clean Code
Clean Code by Robert C. Martin (Uncle Bob) has long been spouted as a book every programmer should read. The book explains reasons why someone should want to program, why one should program cleanly, and how to program cleanly. I picked up a copy of this book during college but never finished it. I tried to read the book again during my internship but failed again. This time I'm going to make it through and you all are going to hold me accountable! So no more wasting both of our time, let's go into my thoughts on Chapter 1 of Clean Code. Much of my writing will be what I have taken away from the chapters. Please do not take what I say with any sort of authority as I have not discussed my thoughts with others and certainly have not discussed it with Robert Martin.
There Will Be Code
The first part of chapter 1 goes into the future of programming and attempts to dispell the idea of programming becoming obsolete. The arguement for the disappearance of programmers is that coding languages will soon become so highly abstracted that the product owners will simply be able to enter their requirements themselves. Uncle Bob's retort on this being that humans have long missed the opportunity to match exactly what their costumers require and that requirements can sometimes too exact for a certain level of abstraction.
I certainly see both sides of this arguement. As a programmer myself, I'm extremely hopeful that this field will be around for a long time. My personal experiences in the field lead me to believe that programming will be around at least for the next 20-30 years. We have seen that legacy systems do not simply grow to use modern languages and there lacks expertise, money, and time to convert them all to use newer systems. I believe legacy systems will become like the aging equipment in industries like manufacturing, where there will always be a small skeleton crew to maintain and upgrade the equipment; or like the accounting field where there exists efficient systems for the masses to use cheaply but businesses, or those with specific needs, will need to outsource to experts or keep an experienced individual on the premises.
I think the best thing for someone wanting to make a career out of programming can do is just continue to learn. Continue to learn your current job and learn how to best use other technologies in conjuction with it. Be the person to bring up workflow systems or the abstractions your company is looking for.
Bad Code Is Everywhere
This part of the book brought up so many personal feelings. Several times have I experienced, or been a part of, 'quick fixes' that are never documented or new changes that are not accompanied or covered with tests. 99% of the time these events happen for good reasons and just simply get forgotten about. Perhaps the change was a hotfix to a system in production and the team's need to document is put in the backlog. This is followed by the tempo never really slowing down enough to afford documenting that system and soon no one really remembers what the hotfix did or that it even existed. Additionally there's been times were tests haven't been added since the project belonged to a separate team and no one really knows how to set up the tests to properly test the new feature. This can continue on as the next developers don't want to add tests because the earlier group doesn't.
Maintaining coding standards is hard. It takes a certain amount of integrity and energy from others to keep everything readable and up-to-date. It reminds me of a separate book I read, The DevOps Handbook that recommended using 20% of the overall time a week to work on technical debt. I certainly think this is one way of moving forward but I think it would need buy-in from management and excellent documentation to be able to prove the value of doing it.
What Is Clean Code
This was probably my favorite subsection in chapter 1. Uncle Bob has used statements from other successful programmers to argue what the definition of clean code should be. While I will not go into depth what every programmer said - although I recommend you to because they were all very insightful - I did want to talk about Bjarne Stroustrup's section.
Some of you may know, Bjarne's the father of the C++ language. In his quote he uses the words 'elegant' and 'efficient' multiple times. Clean code should be elegant and efficient! As with any product you buy - cars, cleaning equipment, household items - the item should do exactly what it says it does. If you buy Tide detergent, it's probably not because of how it looks on your shelf, although that may be a part of it, but you're probably buying it because it cleans your clothes. Code should be like those products. It should do exactly what it says it does and it should tell you exactly what it does.
Additionally, the section goes into how bad code can 'tempt'. I'm so glad that Robert chose this section to go into. For those not reading the book, Robert talks about how a house with a broken window will continue to fall into disarray. If the window goes unfixed, the floors will probably go without being cleaned and the pipes will probably go without being maintained. This is much like a programming project. If you don't update the documentation with your changes, it's doubtful the next person will. If the documentation isn't getting updated, why update the tests or refactor the functions? It reminds me of cleaning my apartment. I can either clean for 15 minutes a day or let it go, but by letting go I will probably spend more time on it in the long run. This ties in well to the last part, the boy scout's rule.
The Boy Scout Rule
"Leave the campground cleaner than you found it". While I was never a boy scout (I stopped after becomming a cub scout), I was in the military. In the military we had a thing that if you found with a mess, it was your mess. It doesn't matter if someone before you caused it, you being there meant you were responsible for it.
I like to continue this thought process in the coding world. If you added a feature, fixed a bug, or just refactored, you need to make sure all of this is documented. If you found a mistake in early code, that mistake is now yours to fix. I think it's extremely easy to just use source control to find out who caused the issue and then push it off your priority list. If it's not your priority, who's is it? While you could probably argue that the original person needs to fix it, it's impossible to know what the deadline or requirements was asked of them. At the very least, I recommend bringing it up to them and offering to help. I find too often we take things too personal when the other person simply wants the product to succeed. Always try to imagine best intentions of others and always try to be a good steward.
Conclusion
I'm looking forward to working my way through this book. I know it will continue to get more technically deep and that the beginning chapters set guidelines and thought processes. I'm hoping you continue to join me on this journey!
Top comments (1)
This book has been on my reading list for awhile now I just can't afford to pick it up at the moment. Thanks for posting this it's cool to see what sort of stuff the book goes into and it's confirmed for me that I want to read it