Being a Pragmatic Programmer: The Pragmatic Philosophy

Part I

The main reason I’m writing this article is to clear up my understanding of How a pragmatic programmer is different from other programmers? I hope many of you reading this also has the same question in mind while listening to the term “Pragmatic Programmer”. So let’s begin:

By “other” (or “normal” programmer) I mean that each & every programmer on this planet is unique. All have some strengths & weaknesses, preferences & dislikes. Over time many of them will develop characteristics that craft the reflection of their own.

Whereas “pragmatic” is the behaviour of a programmer, and here are some of the common behaviours which makes programmer “pragmatic”:

1. Early/fast Adopter — They love trying new things out & can grasp them as quickly as possible.
2. Inquisitive — They are always ready to ask the question to the things they struggle to understand.
3. Critical Thinker — It’s hard for them to go with the flow, they always smell a challenge to all the promised solutions they see.
4. Realistic — They tend to understand the underlying nature of each problem they face.
5. Jack of all trades — They don’t want to stick themselves to a certain technology, they always look to expand their spectrum of knowledge.

To understand the pragmatic philosophy, let’s understand how a pragmatic programmer thinks.

Some key aspects of the Pragmatic Programmer Philosophies

1. The Cat Ate My Source Code: They know how to take responsibility for everything they do.
2. Software Entropy: They don’t leave bad code/decisions unrepaired.
3. Stone Soup & Boiled Frog: They tend to be a catalyst for a change.
4. Good-Enough Software: They understand the context in which they are working so that they can measure the goodness of the software they are building.
5. Knowledge Portfolio: They are always ready to learn. They know how to keep their momentum up.
6. Communicate: They know what exactly they want to communicate & they are always ready to accept the feedback.

I know no one wants to read lengthy & bloated articles. So to make the article small and comfortable to read, I’m breaking this article into 3 parts. This article will cover the first two aspects of pragmatic programmer’s philosophies. Let’s understand these one-by-one. And yeah, these all articles aren’t directly inter-related, so feel free to read them all at any time & in any order 😊.

The Cat Ate My Source Code

One of the cornerstones of the pragmatic philosophy is to take full responsibility yourself & your actions. A pragmatic programmer takes charge of his/her own career & isn’t afraid to admit ignorance & errors.

Take Responsibility

• Responsibility is something you actively agree to, and you should make a commitment to ensure that something is done correctly.
• Keep in mind that you should make a call based on your own ethics & judgment.
• When you make a mistake (as all of us do) or error in the judgment, admit that honestly & try to offer options.
• Be sure to always come up with appropriate & possible solutions rather than giving excuses.

Provide Options, Don’t Make Lame Excuses

• Before approaching anyone to tell them why something can’t be done, or is late, or is broken, stop and ask yourself the same thing. And then think about how it will sound to another person you’re going to.

Software Entropy

Entropy refers to the amount of ‘disorder’ in a system. Its a measure of chaos that either stays the same or increases over time.

Think of it as a building built by a set of workers. Here, workers are the developers who are responsible for developing software (i.e.: building). The builder uses a hammer, drill, screwdriver, nails, cement, etc whereas a developer uses logical assertions & assumptions to build software. These assumptions can’t be held in the hand and examined, which could lead to unmaintainable software over time if not looked over it regularly. This is called Software Entropy.

Unfortunately according to the law of thermodynamics, it guarantees that the entropy in the universe tends towards maximum. So when disorder increases in the software, we call it “Software Rots”. This is a topic that can be explained better with the help of a very interesting example/theory — A broken window.

A Broken Window Theory

According to this theory, a broken window of a building in a city left unrepaired for a substantial amount of time instils people to start littering, which actually leads to structural damage of the building beyond the owner’s desire to fix it, and the sense of abandonment becomes a reality.

Don’t Live with Broken Windows

So in terms of software development, what this theory signifies is, don’t leave “broken windows” (e.g.: bad designs, wrong decisions or poor code) unrepaired. Fix each one of them as soon as it is discovered. Try to take some action to prevent further damage & to show how you’re on top of the situation.

Keep in mind — Don’t Let Entropy Win

Inspired By: The Pragmatic Programmer — by Andrew Hunt, David Thomas

This isn’t the end though, there are some more characteristics of a Pragmatic Programmer, which I’ve discussed in the following articles:

— Stone Soup & Boiled Frog (Part II)
— Good Enough Software (Part II)
— Knowledge Portfolio (Part III)
— Communicate (Part III)

Inspired By: The Pragmatic Programmer — by Andrew Hunt, David Thomas