The Pragmatic Programmer

As a software developer, you know that the tech landscape is constantly evolving, and staying on top of the latest tools and techniques is crucial to your success. But in the midst of all the buzzwords and trends like AI, machine learning, and so much more, it can be easy to lose sight of the fundamental principles that support good programming. That's where The Pragmatic Programmer By Andrew Hunt and David Thomas comes in. This classic book offers a refreshing perspective on software development that emphasizes practicality, flexibility, and common sense. Whether you're a seasoned pro or just starting out, the insights and advice in this book will help you become a more effective, efficient, and pragmatic programmer! Over the last three weeks I have been reading and taking some notes on my thoughts about this book so let's dive in and explore some of my main takeaways.

The Broken Window Theory

When I first started reading the book I made it just FIVE pages until I already had to grab a pen and paper to write my thoughts about the concept of "The Broken Window Theory". The idea behind the Broken Window Theory is that if a broken window in a building is left unrepaired, it can create an environment that encourages further vandalism and deterioration. This is because the visible broken window sends a message that no one cares about the property, and therefore there will be no consequences for the further damage.

This concept originated in criminology but somehow these authors flawlessly applied it to software development, so let me explain their analogy. In software development, the Broken Window Theory applies to the concept of technical debt. Technical debt is the accumulation of unfinished work, such as code that is poorly written or not properly documented, that must be addressed at some point in the future. According to the Broken Window Theory, if technical debt is not addressed promptly, it can create a culture that tolerates subpar work and low standards. Just like the broken window, the presence of technical debt sends a message that it's acceptable to take shortcuts and not pay attention to details. This can lead to more technical debt and a cycle of declining quality.

So in conclusion, just like a broken window, it is important to address technical debt as soon as possible. This is because the longer technical debt is allowed to accumulate, the more difficult and expensive it becomes to fix. By addressing technical debt promptly, developers can maintain high standards and prevent the cycle of declining quality from taking hold.

The Evils of Duplication

Let's talk about the D.R.Y. Principle or also known as the "Don't Repeat Yourself Principle". A key concept discussed in Chapter Two that really stuck with me. The idea behind the D.R.Y. principle is that if you have multiple instances of the same code or logic throughout your codebase, it can lead to maintenance issues, bugs, and wasted time. Instead, you should strive to have a single reference point for each piece of code, so that you can make changes in one place and have those changes reflected throughout your codebase.

You may think this concept is very closely related to cohesion and coupling but it's actually a different aspect of software development that took me some time to wrap my head around. Let me try my best to put this idea into words: Coupling measures the interdependence between modules or components in a system, cohesion measures the degree to which the elements within a module or component are related, and the D.R.Y. principle emphasizes the importance of avoiding duplication in that module or component. While reducing duplication can help to improve cohesion and reduce coupling, it is only one factor in creating well-designed, maintainable software.

To follow the D.R.Y. principle, you can start by identifying areas of your code where there is duplication. This can include repeated code blocks, similar functions with slightly different implementations, or redundant data structures. Once you've identified these areas, you can start to refactor your code to remove the duplication. This principle, which sounds so obvious to some, I can't say I have consciously made the effort to condense my code through this method. Come Monday, I look forward to going through my code base and seeing where I can apply this D.R.Y. Principle!

The Craft of Coding - What Makes a Good Developer?

Sprinkled all throughout this book are tips and tricks on how to become the best version of yourself as a software developer. In the past, these authors have worked with many software developers all the way from junior to principal engineers and they found a similar trend among the ones that performed strongest regardless of their job level. Here are some of my main takeaways that I wrote down during my reading:

• Continuously Learning: Great developers are always seeking to learn and improve their skills. They are curious, stay up-to-date with the latest technologies, and are always looking for ways to improve their craft. The author noted that many of these developers do this organically, they live and breath the thrill of finding new tech that others haven't worked with before.
• Analytical Skills: Software development is all about solving problems, so great developers excel at breaking down complex problems into manageable pieces and coming up with creative solutions and then turning them into clean and concise code for their projects.
• Soft Skills: Developers don't work in a vacuum, so being able to work well with others and communicate effectively is critical. Great developers are able to collaborate with other developers, project managers, and stakeholders to ensure that everyone is on the same page and that the project is moving forward smoothly.
• Attention to Detail: Good developers pay close attention to details, whether it's writing clean, readable code, debugging effectively, or ensuring that their software works correctly in all situations. They are able to see the big picture of the project and adjust quickly based on priorities.
• Passion: Lastly, one of the most important traits according to the author. Great developers have a genuine passion for software development. They enjoy the challenges and opportunities for creativity that it provides. He noted that the personality behind the passionate ones genuinely view software development as a calling or a vocation, rather than just a job, and are motivated by a deep sense of enthusiasm and interest in the work they do.

Be a Pragmatic Programmer

So what does it mean to be a pragmatic programmer? Be someone who is focused on delivering high-quality software that meet the needs of stakeholders and your end-users. It means being open to new ideas and approaches, but also having the experience and knowledge to make informed decisions and avoid common pitfalls. It means being disciplined and organized, but also flexible and adaptable in the face of changing requirements or unexpected challenges. The pragmatic programmer is someone who is dedicated to the craft of software development, and is always striving to improve their skills, knowledge, and effectiveness as a developer.

Ultimately, the core concept I got after reading this book was simply - Emphasizing the importance of being practical, adaptable, and continuously learning over everything else.