"The Pragmatic Programmer" 20th Anniversary Edition by Andrew Hunt and David Thomas is a well-regarded book in the software development community. It focuses on providing practical advice and best practices for developers.

In a previous post, I covered the preface of the book which discusses the attributes that make a Pragmatic Programmer, and how there is no best tool when it comes to software development. It’s time to dive into Chapter 1 - A Pragmatic Philosophy.

The Pragmatic Programmer - Chapter 1

It’s important to remember that this book is not about software design. There are many volumes already devoted to that. This book focuses on the programmer. In Chapter 1, the authors cover seven topics aimed at improving a programmer's approach to their work and career. We’ll only touch on my four favorites here, but the other three are also well worth your time.

It’s your life.

"Why can’t you change it?"

This is a short section that emphasizes the importance of taking responsibility for your career and personal development. It encourages programmers to actively seek growth opportunities and be proactive in learning new skills.

If there is something that you do not like about your current working arrangement, then it is up to you to do something about it. Is your work/life balance not what you would like it to be? Do you constantly deal with toxic co-workers? Do you feel like your career or knowledge is stagnating?

YOU have to be the one to do something about it.

Many developers we talk to are frustrated… some feel they’re stagnating in their job, and others that technology has passed them by. Folks feel they are underappreciated, underpaid, or that their teams are toxic.

And the answer we give is always the same.

"Why can’t you change it?"

Chapter 1, p.1

This can be a hard pill to swallow — particularly in the economy right now where it seems like every day brings a new announcement of layoffs across the board.

I have made a few moves in my career, some by choice, others I just fell into. Some were good and some were, shall we say, less good.

When I finally got my first job in software development, I was ecstatic. I didn’t know anything about the company other than they were hiring. I didn’t know what I should or shouldn’t look for in an employer when working as a developer. That’s not to say that the job was terrible. I worked with some great people. It was a small company probably around 30 or so, with a team of around 10-15 developers.

In a short span of time, I found myself promoted to a team-lead position over 3 other developers. I was moved into this position because of the departure of some other developers. Unfortunately, once I took the team lead position, things started to go downhill. The toxicity of upper management (not the development upper management, they were fantastic) but the others of upper management that seemed to see development as a ‘necessary evil’ (even though they were selling software).

Needless to say, after four months in that position, I followed the steps of my position’s predecessor and left the company.

When you feel like it is time for a change, you are the one who has to make that change. I can’t speak to your situation as you no doubt have your own obstacles to overcome, but that’s the point - it’s your life. You have to take responsibility for your own career. If something or someone is holding you back, it is up to you to figure out what to do about it.

The Cat Ate My Source Code

You limit your growth by not taking responsibility for situations.

The "The Cat Ate My Source Code" mentality refers to the act of making excuses for our mistakes, rather than acknowledging them and learning from them. When we blame external factors like tight deadlines, difficult clients, or even our pets for our mistakes, we're not only avoiding accountability but also limiting our growth as developers.

For example, imagine a developer who consistently misses deadlines. Rather than examining their own work habits, they blame the missed deadlines on an "unrealistic" project manager or "unreliable" third-party libraries. This developer may feel better in the short term, but in the long run, they're missing out on the opportunity to improve their time management skills and become more efficient. Additionally, by blaming things other than themselves, they hurt their own credibility. They will never be known as a developer who can be relied on to get things done.

Another example is a developer who introduces a bug into a production environment. Instead of taking responsibility for the error, they blame it on insufficient testing or poor documentation. This attitude might help them save face, but it also prevents them from addressing the root cause of the problem and taking steps to prevent similar issues in the future.

To truly grow as software developers, we need to embrace the principle of accountability. This means owning our mistakes, analyzing the causes, and taking appropriate steps to prevent them from happening again. When we do this, we open ourselves up to continuous learning and improvement, ultimately becoming better developers and more valuable team members.

Software Entropy

The authors tell a very interesting story in this section about a house fire:

Andy once had an acquaintance who was obscenely rich. His house was immaculate, loaded with priceless antiques… One day, a tapestry that was hanging a little too close to a fireplace caught on fire. The fire department rushed in to save the day - and his house. But before they dragged their big, dirty hoses into the house, they stopped - with the fire raging - to roll out a mate between the front door and the source of the fire.

They didn’t want to mess up the carpet.

Now that sounds pretty extreme. Surely the fire department’s first priority is to put out the fire, collateral damage be damned. But they clearly had assessed the situation, were confident of their ability to manage the fire, and were careful not to inflict unnecessary damage to the property. That’s the way it must be with software: don’t cause collateral damage just because there’s a crisis of some sort.

In the ever-evolving world of software development, keeping a codebase clean, organized, and maintainable is a challenge that every developer faces. As new features are added and bugs are fixed, the code can quickly become more complex, less readable, and harder to manage. This phenomenon is known as Software Entropy, and in this blog post, we'll dive into the concept and discuss some strategies to keep it under control.

Software Entropy refers to the natural tendency of software systems to become increasingly disordered and chaotic over time. This can manifest in several ways, such as code duplication, unused functions, outdated comments, and a lack of consistent coding standards. As entropy increases, the code becomes more difficult to understand and modify, ultimately leading to decreased productivity and a higher risk of introducing new defects.

To combat Software Entropy, developers must be proactive and adopt strategies to maintain a clean and manageable codebase. Here are a few best practices to help keep entropy at bay:

Regular Refactoring

Refactoring is the process of improving the internal structure of code without changing its external behavior. By consistently refactoring code as you work, you can keep the codebase clean, modular, and easy to understand. This makes it simpler for other team members to contribute and reduces the likelihood of introducing bugs.

Adhere to Coding Standards

Establishing and following a set of coding standards can help maintain consistency across the codebase. This includes consistent naming conventions, indentation, and comment styles. A more uniform codebase is easier to read and understand, which ultimately helps to reduce entropy.

Code Reviews

Regular code reviews are essential to maintaining a high-quality codebase. They provide an opportunity for team members to identify potential issues and suggest improvements. By incorporating feedback from code reviews, developers can continually refine the code and keep entropy at bay.

It should be noted that code reviews should never be exclusively done by other people. Yes, this is important, but you should frequently review your own code as you write it. After you make something work, go back and review it to clean up any loose ends or any mess that you made during implementation.

Remove Dead Code

As projects evolve, it's common for code to become unused or obsolete. Keeping this "dead code" in the codebase only adds to the complexity and increases entropy. Regularly reviewing and removing dead code helps to keep the codebase lean and focused. Just commenting out the code is not enough! Remove it completely.

Continuous Integration and Testing

Implementing a robust testing framework and continuous integration pipeline can help catch issues before they contribute to entropy. Automated tests ensure that code changes don't introduce regressions, while continuous integration makes it easier to detect and fix problems early.

By adopting these strategies, developers can take an active role in combating Software Entropy, leading to a cleaner, more manageable, and more efficient codebase. You are rarely going to get time to just focus on cleaning up the code. Just like a running vehicle, it must be maintained consistently while it continues to be used so it can continue to bring value.

Remember that keeping entropy in check is a team effort – the more proactive and disciplined your and your team are, the easier it will be to maintain a high-quality codebase that stands the test of time. If it isn’t happening on your team, don’t be afraid to be the one to start it.

Communicate

Communication is often overlooked as a critical skill for software developers. After all, we're mostly known for our technical expertise and problem-solving abilities. However, effective communication is crucial to the success of software projects and plays a vital role in every stage of the development process.

In software development, communication is the bond that holds teams together and ensures smooth and efficient collaboration. Clear and concise communication allows developers to share ideas, express concerns, and provide feedback to one another. It also helps in bridging the gap between developers and non-technical stakeholders, such as project managers, clients, and end-users. When communication breaks down, misunderstandings and misaligned expectations can lead to project delays, cost overruns, and even complete project failure.

There are a few things that we should focus on when it comes to communication:

Listen Actively

Effective communication starts with active listening. Pay attention to what your team members or stakeholders are saying, ask clarifying questions, and acknowledge their input. This not only helps you understand their perspectives but also demonstrates that you value their opinions.

Choose the Right Medium

Different situations call for different communication methods. While email may be suitable for sharing updates or reporting bugs, face-to-face or video calls are better suited for brainstorming sessions or discussing complex issues. Choose the medium that best fits the context and the message you're trying to convey.

Be Clear and Concise

When expressing your thoughts or ideas, aim for clarity and brevity. Use simple language, avoid jargon, and provide examples to illustrate your points when necessary. This helps ensure that your message is easily understood by everyone involved, regardless of their technical background.

Be Empathetic

Put yourself in the shoes of the person you're communicating with and consider their perspective, knowledge, and emotions. This will help you tailor your message in a way that resonates with them and makes them more receptive to your ideas.

Practice Nonverbal Communication

Nonverbal cues, such as body language, facial expressions, and tone of voice, can significantly impact how your message is received. Be aware of your nonverbal signals and strive to ensure they align with the intent of your message.

Encourage Feedback

Create an environment where team members feel comfortable sharing their thoughts and providing feedback. This can lead to better collaboration, improved decision-making, and ultimately, higher-quality software.

More Topics

We’ve only touched on four of the seven topics of this chapter. The other three include Stone Soup and Boiled Frogs: This topic uses two metaphors to explain how developers can make gradual improvements to the software without causing major disruptions. The key message is to make small, incremental changes that will eventually lead to significant improvements.

Also important is the concept of “Good-Enough Software”. This topic discusses the balance between delivering a perfect product and releasing a product that meets its requirements. The authors encourage developers to focus on creating software that is good enough to satisfy customers' needs while also allowing for future improvements.

Finally, Your Knowledge Portfolio. This topic stresses the importance of continually expanding one's knowledge and staying up-to-date with industry trends. Developers should invest time in learning new languages, techniques, and tools to ensure they remain competitive in the job market.

Conclusion

In Chapter 1 of "The Pragmatic Programmer" by Andrew Hunt and David Thomas, the authors provide practical advice and best practices for developers, emphasizing the importance of taking responsibility for one's career and personal development. They encourage developers to own up to their mistakes, combat software entropy by keeping a clean and maintainable codebase, make gradual improvements to the software, focus on creating good-enough software that meets customer needs, invest in continuous learning, and staying up-to-date with industry trends, and foster clear and effective communication within teams. By following these principles, developers can improve their skills, increase their value as team members, and deliver higher-quality software.