The Frenzy to Chase Every Technology: Pragmatic Engineering

Last week, a message that landed in my inbox struck right at the heart of that big career dilemma I’d been grappling with for a long time, but couldn’t quite name. The message read, “Mustafa abi, should I learn systems, focus on backend, or dive into these new AI agent architectures? When I try to look at all of them, my head spins, and I feel like I’m not specializing in anything by the end of the day.” This question was the most concrete summary of the “know everything and jump on every train” hysteria that has descended upon our industry in recent years.

Throughout my nearly twenty years of field experience, I’ve seen similar confusion countless times, both in myself and in the teams I’ve worked with. The consumption rate of technology has increased so much that a new library or system is released before you can even fully learn the previous one. This situation creates a serious sense of inadequacy and a loss of direction, especially for engineers at the beginning and middle of their careers. In this post, drawing from this excellent topic suggestion, I will share my perspective on why trying to keep up with everything is a career suicide and how we, as pragmatic engineers, can stay afloat.

What Was the Suggestion and Why Is It So Familiar?

The core concern in the email I received was a natural consequence of the information bombardment we all face every morning when we open our browsers. The sender explained that while he wanted to delve into the depths of PostgreSQL, he was also drowning in the details of a new-generation frontend framework, all while juggling Docker and Linux system administration tasks at his company. Adding to this the pressure of “AI is coming, it will end coding, I must learn agent architectures immediately,” it created a complete state of analysis paralysis.

This situation feels very familiar because I went through a similar path. Years ago, I was simultaneously trying to do VLAN segmentation and configure switches, writing systemd units on Linux servers, and struggling with the database performance issues of an enterprise ERP. At that time, I believed I had to know everything with the same depth, and it wore me out immensely. Over time, I realized that knowing everything is not only impossible but also an illusion that degrades engineering quality.

The Illusion of Knowing Everything: Full-Stack Myth or Industry Pressure?

There’s a “Full-Stack” myth that has been marketed in the industry for a long time. This concept arose from companies’ desire to hire system administrators, database administrators, frontend developers, and backend developers all for a single salary. However, in practice, finding someone who is equally specialized in every area is almost impossible. Someone who is very good in one area will inevitably remain superficial in others. This is the biggest factor leading to systems crashing at critical moments.

For instance, you can’t expect a developer who writes a fantastic interface to deeply understand the B-tree indexing logic of the PostgreSQL database behind it or the impact of VACUUM processes on disk. Conversely, it’s unfair to ask a system administrator who meticulously calculates cgroup memory limits in the Linux kernel to solve the complexities of state management in modern browsers. Trying to load all these roles onto a single person will cause that person to have “a little” knowledge in every area and become unable to “produce solutions” in any.

graph TD;
A["Career Focus Point"] --> B["Horizontal Breadth (General Knowledge)"]
A --> C["Vertical Depth (Specialization)"]
B --> D["System/Network Fundamentals"]
B --> E["Cloud and Container World"]
C --> F["PostgreSQL and Database Optimization"]
C --> G["System Security and Hardening"]

The Practical Limits of Being a T-Shaped Person

So, what’s the solution? The “T-Shaped” person model, often heard in the industry, comes into play here. This means having a general knowledge base in many areas (the horizontal bar of the T) and specializing deeply in one or at most two areas (the vertical bar of the T). While this model sounds great in theory, its practical application requires serious discipline. Because if you don’t know where to draw that vertical bar, your T will eventually turn into a rake, and you won’t be able to dig deeply anywhere.

My T model has evolved over time to look like this: horizontally, it includes network topologies, Linux services, and basic frontend knowledge; my vertical specialization areas are enterprise software architecture, PostgreSQL database management, and system security. If I encounter a switch loop or routing flap issue on the network side, I know enough network knowledge to understand and diagnose the problem. However, I wouldn’t attempt to optimize the BGP routing decisions of a global telecom infrastructure; I’d leave that to the real expert. The important thing is to be able to draw your own boundaries.

Pragmatic Engineering: Which Technology to Discard, Which to Hold Onto?

Every day, a new library, a new database, or a new cloud tool is thrown at us. How do we understand which of these will last and which will be forgotten in two years? This is where the pragmatic engineering filter comes in. Before I adopt a technology into my life, I ask myself these questions:

1. Does this technology truly solve a real problem I am currently trying to solve?
2. Is there a strong, independent, and standards-based community behind it?
3. Does the abstraction layer introduced by this technology allow me to debug when errors occur, or does it turn the system into a black box?

If a tool is very popular but has nothing but a huge technology company’s marketing budget behind it, I approach it with suspicion. For example, I wouldn’t move an application that can be easily set up with Docker Compose and run for years without issues into a complex Kubernetes cluster just to be “modern.” Or I wouldn’t immediately try to build a complex distributed architecture for a data processing task that could be handled by a simple Python script. Pragmatism is choosing not the coolest, but the most boring yet most reliable option.

A Real-Life Example: A Decision Point in a Manufacturing ERP

While working on a manufacturing ERP, we needed to present real-time data for the factory’s production planning and metrics from operator screens. The enthusiastic colleagues on the team immediately jumped in, saying, “We absolutely must set up an event-sourcing architecture here, every operator action should be an event pushed to Kafka, and then processed by microservices.” It sounded like a very cool project, worthy of a CV.

However, considering the factory’s physical conditions, the stability of the network infrastructure, and the team’s maintenance capacity, I knew this decision would lead to disaster. Instead, we used standard mechanisms offered by PostgreSQL, optimized indexes, and a simple FastAPI backend with WebSocket connections. The result? The system ran flawlessly for years with practically zero maintenance cost, without losing any messages, and without dealing with complex distributed transaction management. This is the very essence of pragmatic engineering.

The 20-Year Yogurt-Eating Habit: How My Career Filter Works

After all these years of running around in the industry, my greatest gain has been the ability to decide what I should not learn, rather than what I should learn. My personal career and technology filter is built on these three fundamental pillars:

• Invest in Fundamentals: Learning how the Linux kernel works, the handshake stages of the TCP/IP protocol, and the transaction isolation levels of relational databases is an investment that will never become obsolete. A JavaScript framework you learn today might disappear in three years, but TCP/IP has been around for thirty years and will be around for thirty more.
• Learn to Read Error Symptoms: Knowing what to look for in logs when a system crashes is the greatest indicator of expertise. Correctly filtering journald logs, understanding why a systemd service was OOM-killed, or being able to diagnose deadlocks in PostgreSQL will always make you the sought-after person.
• Use AI as a Partner, Not a Crutch: I frequently use AI tools (LLMs, code assistants) when coding or researching complex system configurations. However, unless I have the fundamental knowledge to verify the output they produce line by line, I will never deploy those codes to a production environment. AI can increase your speed, but it doesn’t reduce your responsibility.

Final Word: How to Build Your Own Filter?

If you also feel like you’re drowning trying to keep up with everything, the first thing you should do is take a deep breath and close those fifty different tabs in your browser. Choose a main focus area for yourself. This could be backend, system administration, or data engineering. Deeply immerse yourself in this area; push the limits of those systems, make mistakes, and solve those mistakes yourself.

Don’t completely ignore other areas, but keep them at a “general knowledge” level. It’s enough for a system administrator to understand software architecture, and for a developer to be aware of the resource limits of the server their application runs on. There’s no world where everyone knows everything; there are only people who pretend to know everything and are lost when the first serious crisis hits. Don’t be one of them.

In my next post, I will explain how we practically configure cgroup limits to prevent unnecessary resource consumption on Linux servers and the impact of these limits on application stability.