Five tips to become a Pragmatic Programmer

The Pragmatic Programmer, 20th Anniversary Edition your journey to mastery by David Thomas & Andrew Hunt is one of those must-read books for any software engineer's bookshelf. Comprised of eight chapters that each stand on their own, it reads like a mentor with decades of experience is revealing best practices theyve collected over a career. There are seventy "tips" that detail the characteristics and behaviors of a pragmatic programmer.

Here are five of my favorite tips:

Tip 4: Dont Live with Broken Windows

Don't leave "broken windows" (bad designs, wrong decisions, or poor code) unrepaired. Fix each one as soon as it is discovered. If there is insufficient time to fix it properly, then board it up.

Every engineering team should have the opportunity to improve their code, to leave the campground cleaner. This tip is about the personal responsibility of keeping your code clean and also the leadership responsibility of creating an environment where teams can make things better.

Tip 11: Dont Repeat Yourself

Every piece of knowledge must have a single, unambiguous, authoritative representation within a system

In today's world of distributed applications spread across an enterprise, its easy to fall into the trap of shotgun blasting duplicative (at best) knowledge across the system. Examples can be found in simple implementations of single-page-apps + backend-for-frontend + backend-apis. Three different layers that all have a notion of the domain, e.g. a sales order, but may create individual representations in each.

Tip 14: There are No Final Decisions

The mistake lies in assuming that any decision is cast in stoneand in not preparing for the contingencies that might arise. Instead of carving decisions in stone, think of them more as being written in the sand at the beach. A big wave can come along and wipe them out at any time.

So many of these tips are related to avoiding apathy of software engineers toward the applications they work on. This one is chief among them. With the assumption that things will always change and that we can continually improve on not just our code but everything involved in our work, we actively invest ourselves in seeking that improvement. Our software architecture, our underlying systems, even the way we work as a team are all fair game for incremental or even dramatic changes to make them better.

We design and code differently in that environment. We experiment more freely; we purposely decouple systems and abstract interfaces. We build in more testing because we know well need to ensure stability with future change. In short, we make better software.

Tip 20: Keep Knowledge in Plain Text

As Pragmatic Programmers, our base material isn't wood or iron, it's knowledge. We gather requirements as knowledge, and then express that knowledge in our designs, implementations, tests, and documents. And we believe that the best format for storing knowledge persistently is plain text. With plain text, we give ourselves the ability to manipulate knowledge, both manually and programmatically, using virtually every tool at our disposal.

Im a bit of a productivity tools geek who likes to play with different apps to write, plan, message, and code. I was bitten many times by tools that became obsolete before I learned my lesson. I kept finding myself in a place where I had to abandon collected knowledge because the binary content was not portable to another tool. Plain text is the key to portability and the output should be, ideally, human readable. Even things like diagrams can be represented in plain text and then parsed to produce visual designs.

It still seems strange that I write most of my posts first in Notion. There are two primary reasons: 1. I find it super convenient to use across all of my devices and 2. I leverage markdown (e.g. using ## to start secondary headings and _word_ to italicize a word) when writingand it can all be exported simply in markdown.

Tip 55: Dont Think Outside the Box - Find the Box

You must challenge any preconceived notions and evaluate whether or not they are real, hard-and-fast constraints. It's not whether you think inside the box or outside the box. The problem lies in finding the boxidentifying the real constraints.

Particularly in large enterprises, hunting down the real requirements often combines researching regulations, tribal knowledge, and rumor. Getting down to brass tacks on whats an actual requirement vs. whats the way weve always done it takes effort and requires a willingness (and environment) to question everything. That said, its critically important to creating value for the customer.