Reclaiming Pragmatism
in Software Development
Pragmatism in software development often casts a negative shadow. It has seemingly become a synonym for “shortcuts” and “sloppy work”. But the term signifies something entirely different, and it’s important to re-establish its true meaning.
The Framework Comfort Zone
Many developers I’ve worked with over the past few years have operated primarily within the context of large frameworks. These have a significant advantage: they provide clearly defined structures and methodologies. They often even include tools to, for example, generate code or validate results. It’s easy to find your way around other projects using the same framework. These benefits are undeniable. However, these developers often lack fundamental understanding. Instead of learning the core principles, they dive straight into the “embrace” of a framework.
Back to Basics
Let’s take a step back and develop without massive frameworks. As I’ve been working almost exclusively with Go since 2011, this is my everyday reality. Go’s strength was and is its minimalism. It avoids the “sugar-coating” that frameworks often force upon their underlying technology. Consequently, developers can seem somewhat “helpless” when they first encounter Go. The answer, however, is simple: they lack the “fundamentals.”
Fundamentals First, Pragmatism Second
Depending on your field—whether you’re building web APIs, background workers, IoT services, or user interfaces—you first need a fundamental understanding of how to solve a problem in a structured way. Which methodologies are appropriate, and what should be avoided at all costs? Only once these fundamentals are understood can true pragmatism be applied. This happens when you consciously decide to do something “differently” in your work context to better serve the solution.
Pragmatism in Practice: Intentional Deviation
The best and simplest example is database normalization. It looks great on paper and makes perfect sense. But in practice, blindly following these rules can come at a high cost. Another example is complex type definitions: deviating from the obvious to define something that can be memory-optimized. It’s about straying from “pure theory” to solve real problems. This, in my view, is pragmatism: not implementing standards for their own sake.
In doing so, you ultimately build your own small standard, tailored to the specific situation and environment. If you understand the basics, you can make this adaptation consciously. This is neither a shortcut nor a sloppy solution. It is an individual “interpretation” made after weighing all the advantages and disadvantages.
What Pragmatism Is Not
And what pragmatism most certainly is not: “Quick & Dirty” solutions. That is simply chaos. It’s the “it kinda works” solution that no one after you will ever want to touch. And with the trend towards “Vibe Coding,” it will only get worse.