How to Develop a Pragmatic Mindset as an Engineer

This newsletter is sponsored by .

Download the CAFE(S) framework for evaluating AI agent context quality

AI agents are only as effective as the context they operate on. The new gives engineering teams a practical method for diagnosing and improving the five core dimensions of context quality before issues reach production.

What you’ll learn:

• A shared vocabulary for evaluating AI agent context across your systems
• Actionable patterns to identify and fix context failures early
• How to scale AI workflows safely without compromising performance

Thanks to DX for sponsoring this newsletter. Let’s get back to today’s thought!

Intro

Building a technically perfect solution doesn’t mean you’re building the right solution.

I’ve seen many engineers (including myself) spending weeks (and even months!) building something technically amazing, only to realize that a much simpler solution would have delivered the same or even better results.

The best engineers don’t just know HOW to build great solutions. They know and understand whether it’s worth building in the first place.

This is becoming even more important in the AI era. As writing code gets easier and faster, the ability to make good decisions, understand trade-offs, and focus on what actually matters becomes much more valuable.

And that’s where having a pragmatic mindset makes all the difference.

In this article, I’ll share a mistake I made earlier in my career and practical ways you can develop a pragmatic mindset as an engineer.

This is an article for paid subscribers, and here is the full index:

- What Does it Mean to Have a Pragmatic Mindset?
- My mistake of building a theoretically correct solution rathet than a pragmatic one
- First, Build the Right Things; Second, Build Things Right
🔒 Prioritize Simple Solutions Over Complex Ones
🔒 Think in Terms of Trade-Offs
🔒 Use Boring Tech to Build Great Products
🔒 Get Used to Building Proofs of Concepts (PoCs)
🔒 Become a Salesperson, Too
🔒 Focus on the Product and the Business
🔒 Last words

Let’s start!

My upcoming book “The Multiplier Mindset” published by O’Reilly

This article is an adapted version of one of the chapters of my upcoming book called “The Multiplier Mindset”, published by O’Reilly. The book will be published soon, and you can already pre-order it!

What Does it Mean to Have a Pragmatic Mindset?

Pragmatism is one of the most important concepts in software engineering.

Being pragmatic as an engineer means focusing on what actually works in each specific case, not just what is theoretically correct.

There are endless variables and trade-offs we need to consider when building software, and many of them are people focused.

And while AI can predict the next best token, it doesn’t have the real-world experience or the perceptiveness to pick up on many different signals and make the decision that best fits a certain moment.

A pragmatic engineer finds the best solution that’s possible within the constraints of the real world, not the ideal world.

There are many potential solutions to every engineering problem. Some are theoretically correct but don’t work in reality because of the set of specific constraints involved.

Engineering is not performed in a vacuum. The constraints on real production software include the following:

• Budgets
• Product requirements (which may change)
• Team members’ knowledge and expertise
• Team members’ and stakeholders’ personalities, relationships, and motivations
• Legacy code
• Existing hardware and infrastructure
• Regulatory frameworks
• Project schedules

And so on. Being pragmatic means we build useful, reliable, and achievable solutions within the existing constraints.

My mistake of building a theoretically correct solution rathet than a pragmatic one

Back when I was a senior software engineer, I made the mistake of building a theoretically correct solution rather than a pragmatic one.

We were building a new feature for an application that used Angular on the frontend and ASP.NET Core on the backend. We were adding functionality to let users upload, view, edit, and set metadata for images.

I was excited to work on this. We spent a lot of time and effort on it, and I was personally very proud of it. But our users were already accustomed to cropping images themselves before uploading them, so they never really used the cropping and resizing functionalities we built.

It was a technically correct solution that worked amazingly well, but pragmatically, it was a bad call.

To come to the best and most pragmatic decision, ask yourself, “What’s the simplest solution we could deliver?” Then deliver exactly that. You can optimize it further if you need to, but only after delivering it.

The legendary computer scientist Donald Knuth famously wrote that “Premature optimization is the root of all evil.” Too often, engineers try to optimize prematurely and get excited about building a “complex solution” that isn’t even needed, so they waste both time and effort.

In the next sections, we’ll look at how you can develop a pragmatic mindset as an engineer.

First, Build the Right Things; Second, Build Things Right

You can build the best solution that’s technically possible, but if the users don’t need it, they won’t perceive it that way.

Ruthlessly prioritize what you should focus on; only after that should you look to optimize it.

This is more important than ever at this time in the AI era. As you can see from the image below, there’s a lot more (mobile) apps being built and released, but the apps with significant usage have actually dropped.

This means that pure building is worth less, but WHAT to build and WHY to build it so that people will care is worth so much more.

There’s a huge need for companies and products to stand out from competitors in a certain way, and just pure features and tech is just not going to cut it anymore. That’s already expected.

With this in mind, the work of engineers is shifting a level upwards, as pure building based on requirements is worth less, but great decision-making is worth a lot more.

Prioritize Simple Solutions Over Complex Ones