"Clean code always looks like it was written by someone who cares." – Robert Martin
Most engineers learn the hard way. We suffer enough bad code that one day we wake up determined to be the change we wish to see in the world.
I finally got around to reading Clean Code by Robert Martin, a must-read in the software community. This book is for programmers or programmers who want to become better programmers. Check, check.
Here are a few lessons learned from reading "Uncle Bob’s" book and reflecting on my developer experience.
Applications are only as good as the underlying code
Building software is more than just writing code. Developers turn conceptual ideas from a person’s mind into real-world applications…and it can be a long, arduous endeavor. I often underestimate the amount of time, work, and effort it takes to create a software system with true value and purpose.
Coding the right way is equally as important as building something attractive to customers and clients. Because applications are only as good as the underlying code.
Writing clean code upfront saves time and energy for your future self
Tight deadlines and other business factors out of a developer's control make it tempting to take shortcuts and bypass best practices. But this yields more ongoing maintenance and future fixes. There’s no doubt about it, bugs will happen. However, the number of bugs can be reduced by writing clean code, especially with unit tests.
Taking time to write well-structured and architected code enables you to make quick, easy changes down the road. Your future self, or future software engineers, will thank you.
Core tenets of great code
- Keep it simple. By doing this, we increase efficiency in both the initial creation of software and the long-term maintenance of applications.
- Reduce unnecessary complexity. When bugs or problems occur in software, we want the location of the errors to reveal themselves quickly. This can be done through helpful logs, alerts, and alarms.
- Reduce the surface area for bugs to occur. Vertical distance is similar in that less code is usually better than more code. Having more code than necessary introduces vertical distance which increases the probability that bugs can and will occur. A bonus is that the ability to find where errors happen will be easier since there will be fewer places to look.
- Favor clarity over cleverness. The amount of time, effort, and resources spent fixing bugs can cripple a company’s ability to innovate and create new products. I would argue that most people (especially software engineers) would rather spend their time creating new products and working on new ideas rather than staying bogged down by the maintenance of old software.
I love software engineering because the learning never stops. I’m realizing that behind every great software application is a developer who took the time upfront to write clear, simple, easy-to-read code. At the end of the day, it’s not just computers that read our code…it’s people. Shoot me a message with your thoughts on Martin’s book, or other developer practices. I’m eager to keep the conversation going!