Pragmatism

Read The Pragmatic Programmer. It’s was the most transformative book in my career and will give you a mental model for understanding how to be an “effective” programmer.

Pragmatism means thinking of or dealing with problems in a practical way, rather than by using theory or abstract principles.

Throughout your journey through the technology field, you will inevitably come upon that one team member that is STUCK on minute detail that holds the entire team from delivering a feature. They argue that this solution won’t scale and you have to redo the feature and miss release. Now don’t get me wrong there will be times when you have true technical concerns - but this person is saying it won’t scale when you start to hit 10x your current production volume. A pragmatic approach to this would be that you we can release now, and create a backlog item to work on the refactor in the future. What is most important is that you can be “effective” by delivering value, but keeping in mind that you may need to come back to this in the future. Pragmatism is all about looking for sensible and practical solutions to our problems. A more relatable way of saying this between developers is to build with a “good enough” mentality.

“Good Enough” Mentality

The “good enough” mentality changes the way that we view software development, in that what we are focusing on building a solution that is “good enough”, rather than what is best. Through your experiences you will be able to determine what is needed now, and what can be integrated later when the time comes. You can design your systems such that it solves your current tasks, but also in a way that you are open to the possibility of change. Your system has the ability to adapt to changes in the future, without fully committing to these designs until they are needed.

A common understanding is that the more time you put into a task, the higher the quality the result will be. (Side note — I thought this graph was also relatable in that the more time we spend on our designs, the more confusing it can make the final solution.) The early parts of the curve would indicate a “quick and dirty” solution, whereas the latter part indicates the “best” solution possible. In the middle where it starts to level is the sweet spot that is “good enough” — where your return on investment (time) no longer benefits you as much.

How Much is “Good Enough”

There is no universal process for finding out what is “good enough” for every case. Different industries have different standards. Different projects have different timelines. Different people have different philosophies in maintainability.

Here are some properties of a “good enough” solution to get you started:

• Good enough that it works
• Good enough that it can fit within the deadline
• Good enough that it can change with different requirements
• Good enough that it can handle some degree of unexpectedness — some uncommon use cases, heavy performance loads, or system failure for some examples

The Benefits of The Pragmatic Approach

Following this mentality can have a profound effect on your developer experience:

• You will be more confident in your assessments and designs
• You will be encouraged to evaluate all of your options, and trim down the answer to just the right size
• You will be more consistent in making delivery dates because you are taking time into consideration
• You will have better work/life balance because you won’t have to overwork to make up the difference between the best design and the one that will ship on the metaphorical next Friday

The content of this article was adapted from my Medium blog post, The Pragmatic Approach.