Decoding Pragmatism

How to become a pragmatic programmer1 in 10 simple steps, according to The Pragmatic Programmer by Andrew Hunt.

1/ No dogma.

A pragmatic programmer is technology-agnostic, i.e. not wedded to any particular language, toolset, or operating system.

It's fine to have preferences, but we need to see each set of circumstances for what it is, applying a solution appropriately.

2/ Great power, great curiosity.

Programming is among the most autonomous professions there are. 10x engineers do not take this agency for granted.

They care about their craft and think about their work—like we're doing right now!

3/ Good-enough software.

"Good enough" does not mean sloppy. Of course, we must meet the user's requirements. But not more than this.

Time is precious. We're gonna have to make tradeoffs. And don't forget to involve the user when you do.

4/ No broken windows.

Quality is a team issue. Unfixed issues destroy the team spirit and shouldn't be tolerated. We need to set an example by fixing bugs when we encounter them—regardless if they're our own.

5/ Let it crash.

Dead programs don't lie. Crashing as early as possible prevents catastrophes from slipping by into production. Defensive programming is dangerous. Let it crash.

6/ Decouple your code.

If everyone has to attend a meeting because no one's sure what will be affected by a certain change, it's a big sign the code needs decoupling. Decoupled code is easier to change.

7/ Coding is non-mechanical.

Coding is not blindly transcribing the design into executable statements. If our software is to enjoy a long healthy life, we need to continually think about improvements.

8/ Keep it simple (for safety).

There are many reasons to keep design simple. It's easier to change, maintain—but it's also safer.

Higher code complexity means a larger attack surface. Less code means fewer bugs and fewer opportunities for security holes.

9/ Be a therapist.

Part of being a good programmer is helping the client figure out what they really want.

Never trust a customer's first statement of needs. Project requirements are learned in a feedback loop between both parties. Be a therapist.

10/ Don't panic.

If coding feels like an uphill battle, take a step back. It's probably harder than it needs to be.

Maybe the design is wrong? Maybe you're solving the wrong problem altogether?

Draw some doodles, take a walk. Talk to your co-worker and the solution will come. Let the friction foster simplification.

In conclusion,

Pragmatic programmers embody responsibility. They value quality, but not complexity.

Above all, pragmatism is about leadership. It's bringing the whole team together, helping our peers improve in the process.


[1] Within the context of software engineering, being pragmatic is basically synonymous with being senior IMO. But let's give the authors their due and use the terminology they've coined.