Book Highlights: The Pragmatic Programmer

Completed Book on : 18th September 2022

Highlights were extracted using highlightextractor.com

Main Summary

This book is a guide for all Programmers who want to be an effective and pragmatic Programmer. It provides you with principles and guidelines on how you can be a very efficient and productive programmer. The best thing about this book is that it can be applied to any sort of programming and is not concerned by technology stacks or the latest tools. The main crux is to adopt a pragmatic mindset when it comes to programming.

Highlights

"We can be proud of our abilities, but we must be honest about our shortcomings, our ignorance as well as our mistakes."

This highlight emphasizes the importance of humility and self-awareness in programming. It suggests that while celebrating achievements is essential, acknowledging and learning from mistakes and areas of ignorance is equally crucial. In the ever-evolving field of programming, continuous learning and a humble approach contribute to personal and professional growth. The more you make mistakes, the more you learn.

"Instead of excuses, provide options. Don't say it can't be done; explain what can be done to salvage the situation."

This principle encourages a proactive and problem-solving mindset. Rather than focusing on limitations or challenges, it advocates for presenting viable alternatives and solutions. A pragmatic programmer always looks for solutions rather than excuses. This showcases the programmer's ability to think critically and adapt to different situations.

"One broken window, left unrepaired for any substantial length of time, instills in the inhabitants of the building a sense of abandonment—a sense that the powers that be don't care about the building. So another window gets broken."

The "broken windows" analogy talks about a building where if one window is broken and left unrepaired, the rest would also eventually get broken. This is to emphasize the importance of promptly addressing issues. Unattended problems can lead to a decline in overall system quality and may influence others to follow poor practices. Timely maintenance and fixing of issues are crucial for maintaining a healthy codebase. Always be on the lookout for broken windows and repair them whenever you get the time.

"People find it easier to join an ongoing success."

Many times when you present a new initiative that requires a huge overhaul or code change is vetoed because engineers get overwhelmed by the idea. The approach here is to start small and gradually expand, once it gets in the flow, other engineers would automatically join and they would not be overwhelmed by it.

"Invest regularly. Just as in financial investing, you must invest in your knowledge portfolio regularly. Even if it's just a small amount, the habit itself is as important as the sums."

This is very important, you must invest in yourself, either by learning new technologies or mastering your current ones. Try to build something using what you have learned and showcase it as a portfolio. Maybe write a blog about it. This habit ensures adaptability and long-term career growth.

"DRY—Don't Repeat Yourself"

The DRY principle advocates for avoiding redundancy in code. It suggests that each piece of knowledge or logic should exist in a single, unambiguous place. By adhering to DRY, programmers can enhance maintainability, reduce the likelihood of errors, and promote a more efficient and organized codebase.

"In an orthogonal system, the answer should be 'one.' Moving a button on a GUI panel should not require a change in the database schema."

Orthogonality in design ensures that components are independent, and changes in one do not affect others. This contributes to a modular and flexible system where modifications are localized. The example of moving a GUI element without affecting the database schema shows the practical application of this design principle.

"Keep your code decoupled. Write shy code—modules that don't reveal anything unnecessary to other modules and that don't rely on other modules' implementations."

Decoupling and writing "shy" code emphasizes the importance of minimizing dependencies between modules. This enhances code maintainability and allows for easier updates or replacements of individual components without affecting the entire system.

"You shouldn't be wedded to any particular technology."

This emphasizes the importance of being pragmatic and open to adaptability. You should choose a technology based on the situation. The right tool will serve you better whereas the wrong tool will increase your workload.

"Don't leave 'broken windows' (bad designs, wrong decisions, or poor code) unrepaired. Fix each one as soon as it is discovered. If there is insufficient time to fix it properly, then board it up."

If you find a broken window and immediate fixing is not feasible, temporary measures such as commenting out code or writing a TODO message are suggested to prevent further degradation of code quality. This helps highlight the issue to other programmers too that a specific piece of code is broken and maybe they might repair it.

"It's easier to ask forgiveness than it is to get permission."

This resonates with me. At times if you have an initiative in mind, and you are fully aware that it would get rejected if brought up in the weekly stand-up call, then it is better to quitely find some time and work on it. When you have enough of it done, you can inform the stakeholders by giving them a demo and surely they will not disapprove it. If they dissapprove of yor sneakiness, you can ask for forgiveness. :D

"Commonly needed functionality or data that doesn't fall into an obvious area of responsibility can get implemented many times over"

This principle highlights the importance of communication to avoid redundant implementations. By fostering an environment where developers communicate effectively, the chances of multiple implementations of the same functionality are reduced, leading to a more streamlined and efficient development process.

"Avoid global data. Every time your code references global data, it ties itself into the other components that share that data."

This principle advocates for avoiding the use of global data, as it introduces dependencies and makes the code less modular. By minimizing global data references, programmers can enhance code maintainability and reduce the risk of unintended side effects.

"We think it is better to know one editor very well, and use it for all editing tasks: code, documentation, memos, system administration, and so on."

Master a single editor very well rather than simply knowing multiple editors. It goes a long way. Becoming proficient in one editor can lead to increased productivity and a smoother workflow across different aspects of software development. Nowadays, I can wholeheartedly recommend VS Code as an editor to master.

"It doesn't really matter whether the bug is your fault or someone else's. It is still your problem."

A pragmatic programmer does not blame, he fixes. Regardless of individual ownership, all team members should consider it their responsibility to address and resolve bugs, fostering a collaborative and accountable team culture.

"Before you start debugging, it's important to adopt the right mindset"

Debugging is an art in itself, if you want to master it, you need to let go of your ego, and your judgment and be look at the problem from an open mindset. Creating a conducive mental environment helps in effective issue identification and resolution.

"A very simple but particularly useful technique for finding the cause of a problem is simply to explain it to someone else."

This introduces the concept of rubber duck debugging, its a technique where explaining a problem to someone else or an inanimate object (like a rubber duck) can help in identifying the cause of the problem. The act of verbalizing the issue often leads to new insights and solutions. This has always helped me.

"In most projects, the code you are debugging may be a mixture of application code written by you and others on your project team, third-party products, and the platform environment."

This principle guides programmers to initially focus on their code and project-specific elements when debugging. Yes, there are always external factors like third-party libraries which could be the cause but first, you need to start with your code and gradually reach the level where you think it could be an issue with the third-party library.

"All errors give you information... if there is an error, something very, very bad has happened."

Highlighting the informational value of errors, this principle suggests viewing errors as indicators of potentially severe issues. It emphasizes the importance of taking errors seriously and addressing them promptly to maintain the integrity of the program.

"When your code discovers that something that was supposed to be impossible just happened, your program is no longer viable... terminate it as soon as possible."

This highlights that exception handling is very important when it comes to programming. If your program arrives at a situation where it does something weird, it should immediately be terminated and the exception handled. The reason to terminate is that if it continues, it might do harm rather than good since it has reached an unchartered territory.

"Don't let existing code dictate future code".

This talks about stagnant codebases, where if the current code is pathetic and of bad quality, people generally tend to write the same type of code in future. But a pragmatic programmer knows that all code can be replaced. So he would approach this by writing better code.

"Automate every task everything you can, avoid manual procedures at all cost.

This quote is something that I have personally done whenever it's possible. There are always redundant tasks lying around which can be automated, try to automate them to save your time and energy.

"The success of a project is measured by how well it meets the expectations of your users."

At the end of the day, it's not your code, it's the expectation of your users, and your clients who use the software. If the expectations are not met, no matter how pretty the code is, it's not worth it.

**"Work with your users so that their understanding of what you'll be delivering is accurate." **

Connecting it with the previous highlight, one should work with his users, trying to understand their problem and getting constant feedback from them. In this way, the Software delivery will be accurate.