Pragmatic Programmer was written by Andrew Hunt and David Thomas back in 1999.  Given the date, is is not surprising that they talk about C and Smalltalk as really powerful languages.  They are not that popular anymore but they were used to build even better languages.

However, this book is not about these programming languages.  Instead it gives you a bunch of tips about writing maintainable software.

Developing Great Software

The core of this book is about guidelines for developing better software and to work better as an individual and as a team.

It is really common to think that writing software as the total opposite of making art.  Software  is associated with the logical thinking process rather than creativity.  However, software development is not that different from art if you care for your craft.

There is no point in developing software if you don’t do it well.  It is not about trying to achieve perfection, but our technical skills can be sharpened by constantly asking ourselves “Can we do better than this?”

Responsibility and Honesty

Software development is a team sport and nowadays the team is likely to be distributed throughout the world.

In spite of cultural differences, everyone in a team needs to be responsible and honest.

Being responsible in this particular context means fixing what you break, deliver what you promise,  and provide options instead of lame excuses.  Honesty involves being straight with your team.  If you need help, ask instead of delaying the whole schedule.

Communication skills also play an important role while working with teams because it is how responsibilities are defined.  In order to communicate in an effective manner, an outline can be sketched of the message you need to transmit.

Keep in mind that understanding your audience is crucial to for your message to be heard. If you consider their motivations and interests, it is easier to choose the relevant information that has to be shared.

Working as a Team

One of the responsibilities involve helping each other instead of blaming others. Blaming someone won’t fix the problem, so it’s better to focus that energy on fixing the bug.

Software can also suffer from a natural process called rotting.  You have to pay attention to bad design, wrong decisions, and poor code and clean it up as soon as you discover it.  Neglect will just accelerate rotting.  Ignoring bugs and bad design will leave the door open for more bugs and worse design.  You’ll end up with unmaintainable code.

I think this is one of the harder lessons to implement in real life.

Create an atmosphere that encourages change.  For example, if you discover dinosaur code that needs refactoring, fix it.  Become a catalyst for change.  Show everybody in your team how bright the future can be. Plant the seed and help them move in the right direction, to get into action and make their vision a reality.

In my perspective, it is important to show something tangible before sharing it with others.  People find it easier to join an ongoing success that has a shape rather than a vague idea.

The Orthogonality Principle

Orthogonality means that changes in one place do not affect any others.  It relieves the pain of interdependence and helps you improve quality.

For example, when a client makes a request, it is important to remember that it may change later.  

Maybe the client changes their mind or we run into a technical obstacle.  If the code is properly self-contained, independent, and has a well-defined purpose, then it will be well ready for any contingency.


I found these general tips really helpful in order to avoid simple mistakes that can get into larger problems over time. The tips that are presented on this book summarizes years of knowledge from really skilled programmers with hands-on experience in software development.

The fact that these tips are practical and not theoretical makes them even more valuable for someone who needs the knowledge that experience gives you in a really short amount of time.