I recently started reading The Pragmatic Programmer: From Journeyman to Master, by Andrew Hunt and David Thomas, which was published in 1999. The book is well organized in short and self-contained chapters. Each chapter has tips that offer advice on several subjects such as testing, prototyping, debugging, how to communicate effectively, exception handling, best practices and challenges.

This book is highly recommended and it’s amazing to see how a software development book could remain influential and a-must-read for this long(two decades). I have read only two chapters until now and the reason why I am writing this blog post is that I find it very useful and want to memorise as much as I can by writing and sharing some tips. I intend to do so in every two weeks. I like to challenge myself sometimes .

What is a Pragmatic Programmer?

They say it’s a style, an attitude, and a philosophy of approaching problems and their solutions. They think beyond the immediate problem, always trying to place it in its larger context and to be aware of the bigger picture. After all, without this bigger picture, how can a programmer be pragmatic? How can they make intelligent compromises and smart decisions?

Are you a pragmatic programmer?

Here are some characteristics that make you a pragmatic programmer according to the authors:

1. Early adopter/ fast adapter. When you have an instinct for techniques and technologies and you also like to try things out. When you grasp new things quickly and integrate it with the rest of your knowledge.
2. Inquisitive. When you always tend to ask questions.
3. Critical thinker. When you rarely take things as given and you always smell a challenge.
4. Realistic. When you try to understand the underlying nature of each problem you face.
5. Jack of all trades. When you try to be familiar with a broad range of technologies and you are able to move to new areas and challenges.

First tips

Tip #1 Care about your craft

-There is no point in developing software unless you care about it doing it well.

Tip #2 Think about your work

Think about what you’re doing while you’re doing it, Constantly be thinking, critiquing your work in real time.

Tip #3 Provide options, don’t make lame excuses

Don’t say “The Cat ate my Source Code”, but take responsibility for everything you do. Don’t say it cannot be done, but explain what it can be done to salvage the situation. Also don’t be afraid to ask or that you need help.

Tip #4 Don’t live with broken windows

Don’t leave “broken windows” (aka bad design, poor code or wrong decisions) unrepaired.