Pragmatic Programmer | Book Summary

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

  1. Is the problem being reported is a direct result of the underlying bug, or merely a symptom?
  2. Is the bug really in your code or someone else code? Is it in your compiler
  3. If you explained this problem in detail to a coworker, what would you say?
  4. If the suspect code passes its unit tests, are the tests complete enough? What happens if you run the unit test with this data?
  5. 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.

YOU CAN BUY THE BOOK USING THE BELOW LINK

Sree Hari Sanjeev

The founder and CEO of Wisdom Overflow. His enthusiasm and effort has taken the blog to next level. You will be motivated just by taking a look at his daily schedule.