Pragmatic Programmer | Book Summary
Pragmatic Programmer
‘Pragmatic Programmer’ book by Andrew Hunt is an excellent book for a programmer and a must-read for college students. It is easy to read compared to Code Complete and Clean Code. It covers various programming philosophies. Now let’s see the ways to become a Pragmatic Programmer.
Cat Ate my source code
Don’t blame someone or something else, or make up an excuse. Don’t blame all the problems on a programming language, management, or your coworkers. All of these may play a role, but it is up to you to provide solutions, not excuses.
Learning new things:
It doesn’t matter whether you ever use any of these technologies on a project, or even whether you put them on your resume. The process of learning will expand your thinking, opening you to new possibilities and new ways of doing things. The cross-pollination of ideas is important; try to apply the lessons you’ve learned to your current project. Even if your project doesn’t use that technology, perhaps you can borrow some ideas.
And make a point of reading other people’s source code and documentation, either informally or during code reviews. You’re not snooping—you’re learning from them.
Take a powerful editor and learn it well.
The editor must suit all your needs.
Use the Power of Command Shells
The disadvantage in GUI -What you see is all you get. The command line is better suited when you want to quickly combine a couple of commands to perform a query or some other task
There are No Final Decisions
Requirements change during the project, So be flexible.
Don’t Panic
Before you start debugging, it’s important to adopt the right mindset. It’s easy to get into a panic, especially if you are facing a deadline. But it is very important to step back a pace, and actually think
If you “changed only one thing” and the system stopped working, that one thing was likely to be responsible, directly or indirectly
Debugging Checklist
- Is the problem being reported is a direct result of the underlying bug, or merely a symptom?
- Is the bug really in your code or someone else code? Is it in your compiler
- If you explained this problem in detail to a coworker, what would you say?
- If the suspect code passes its unit tests, are the tests complete enough? What happens if you run the unit test with this data?
- Do the conditions that caused this bug exist anywhere else in the system?
Test your assumptions
Whenever you find yourself thinking “of course that will happen again” add a code to check it. The easiest way to write an assertion to test it. Don’t just test your code, but test your assumptions as well.
Find Bug Once
Once a human tester finds a bug, it should be the last time a human tester finds that bug. The automated tests should be modified to check for that particular bug from then on. Don’t think “oh, that will never happen again”
Don’t Program by Coincidence
Suppose Fred is given a programming assignment. Fred types in some code, tries it, and it seems to work. Fred types in some more code, tries it, and it still seems to work. After several weeks of coding this way, the program suddenly stops working, and after hours of trying to fix it, he still doesn’t know why
Fred doesn’t know why the code is failing because he didn’t know why it worked in the first place.
Refactor Early, Refactor Often
Don’t be a slave to history. Don’t let existing code dictate future code. All code can be replaced if it is no longer appropriate. don’t let what you’ve already done constrain what you do next—be ready to refactor. This decision may impact the project schedule. Think of the code that needs refactoring as a “growth.” Removing it requires invasive surgery. You can go in now, and take it out while it is still small. Or, you could wait while it grows and spreads- after which removing it then will be both more expensive and more dangerous. Wait even longer, and you may lose the patient entirely.
Know When to Stop :
Don’t spoil a perfectly good program by over-embellishment and over-refinement. Move on, and let your code stand in its own right for a while. It may not be perfect.
