Chapter 6 of “The Clean Coder” primarily focused on practice. Martin explained the different types of practice including Kata(practicing on individual skills), Wasa(practicing in pairs with another person), and Randori(free-form practice). With these three sets of practice techniques he compares each to martial-arts. He states that much like martial-arts, you will never get two exact sets of problems(or opponents) and you don’t practice against a particular style, but instead practice technique so you know how to handle each unique situation. By practicing how to break down and tackle these problems, when one appears you know which direction to take to assess it.
I am sure when Martin first began practicing, his sources were limited. In today’s technology age, there is an abundance of sources to practice skills such as online sites like LeetCode, Project Euler, etc. and even open-source projects you can contribute to on github. The best type of practice is your own personal projects because you experience the entire software engineering process from gathering requirements, to development, and even testing. No matter how you practice, as long as you do it you should be fine. Even Michael Jordan, the greatest basketball player of all time spent his time in the gym practicing his craft. Software Development isn’t any different in that sense.
Test Driven Development(TDD) was the topic of chapter 5. TDD was explained as a continuous cycle of writing a test for code designed to fail at first, then writing just enough code to make it pass. These cycles repeat over and over until the final product is achieved. The purpose of this development method is to ensure we are writing code that can easily be maintained. You won’t have to worry about introducing something in your code which breaks it horribly and you can’t pinpoint the reason for it. If you write code and all of your tests fail, you know exactly where the bug was created and this simplifies the debugging process because you won’t have to search through thousands of lines of code to fix your problem.
TDD is a different process than what you do when you are first programming. At first you build an entire project and test after to make sure your program outputs exactly what you want. The fault with this method is you design tests around what you expect to happen, and you don’t take into consideration all of the possible bugs that an atypical user would find in your code. Coding this way also hinders the refactoring process because classes are tightly coupled and introducing a small bug in your program is nearly impossible to find.
From now on I will attempt this form of developing. It will be different at first and I possibly won’t be AS productive at first, but once I get the hang of it I will be sure that my code is both clean and maintainable.
I believe for any software developer first beginning their career they want to be “Yes Men”. We are so eager that we have what it takes to be a professional we don’t know what the word “no” means. “Can you stay late and complete this? Can you make this all by yourself? Can you do that… etc” We want to belong, we want people to believe in us, we want a paycheck every week. This saying yes all the time must be a stage because once we actually know we belong, we learn our limits. We learn from experience that we need a team to complete something, we need time away from the office to be productive, we need a life outside of work to keep our heads in the game while we’re working.
Chapters 2 and 3 of “The Clean Coder” emphasized these points concisely and effectively. By only saying yes, you agree to add features that cannot be implemented and this in turn shifts focus away from the primary goal. Learn to say no when appropriate and work hard and deliver when you say yes and respect will be earned. I believe Martin said it best when he stated, “Professionals know their limits… Professionals are not required to say yes to everything that is asked of them. However, they should work hard to find creative ways to make ‘yes’ possible.”.
Chapter 1 of “The Clean Coder” was focused on what exactly clean code is. Clean code is elegant, reusable, and easy to maintain. My first couple of semesters, the primary focus when coding was hacking away until I finally found something that worked. Once I had a working version, the assignment was submitted and forgotten about. As I’ve progressed through my education, I’ve noticed something that has sort of happened naturally. Over time my code has actually become easier to read and I could go back to my code and follow along and understand my thought process at the time. I went from naming all of my variables a,b,c, etc. to actual names that mean what they represent.
After reading the first chapter, not only did I notice my progression, I also realized how much I need to improve. I now understand I must continually test my work, and also make it easier for myself to go back later on and be able to understand my code. Maintainablity and reliability have become a lot more important, and I am excited on using these ethics to improve my future work. Hopefully one day my code can be considered “clean”.
My name is Xavier, and I am currently a Senior at Worcester State University. I am graduating this Fall studying Computer Science with a concentration in Software Development.
The first week of the Senior year capstone marks the beginning of developing on a code base larger than I have ever experienced. My first feelings are those of nervousness, but soon after the nerves are feelings of excitement. I’m ready for this project, and I’m ready to graduate. Four years of schooling has prepared me to succeed, not only in this project, but any project I set my mind to in the future!