Your Tech Stack is a Commodity. Your Critical Thinking is Not.
Engineering the “Why” to escape the trap of the fixed-stack mindset.
I am writing this to articulate several key points for your consideration:
Over the years, in countless high-level technical discussions, I have noticed that a significant percentage of software developers tend to think and ask questions like: “Hello! You have been working in the industry for a while. What software stack do you work with?”
Whenever I’m asked this, I find myself hesitating. It isn’t that I lack an answer, but rather that I’m puzzled by the premise of the question itself. Why has the modern developer come to perceive their value as being inextricably tied to a fixed collection of tools? Why do we define our professional identity by the "pile" of technology we use, rather than the problems we solve? What makes a developer perceive their software writing process as being tied to a fixed stack?
Let’s explore the concept linguistically. The dictionary definition of “stack” is as follows:
1. (countable) A pile of something that is usually arranged neatly, such as a stack of books.
2. (countable) In computing, a method of storing information where the most recently stored item is the first one to be retrieved.
When we refer to a collection of software components, we call it a “software stack.” Similarly, the term “technology stack” describes the range of technologies used in a particular application or system.
Root of Evil:
It is not inherently evil to think from a technology stack narrative; however, this thinking often stems from various freelance marketplaces where specific business problems need to be commoditized and solved using proven blocks of technology stitched together. Practically, the technological landscape is predefined even before fully understanding and strategically planning for specific tools.
The argument is that a commoditized problem can be addressed using this stack notion. For example, a practitioner in the field of nutrition wants to share thoughts about the nutritional benefits of food and a healthy lifestyle; however, they do not want to deal with all the complexities of digital platforms. As a result, they hire someone to create a blog-style site for their writing. Ironically, this individual contractor resolves the issue using PHP and scripting languages, MySQL for data storage, and Apache HTTP as a web server, hosting the solution on a virtual machine running on a Linux operating system. This combination is commonly referred to as the LAMP stack.
This creates a classic narrative of a development stack. However, I oppose this approach; we should ask ourselves, is it even necessary? Why aren’t we making it simpler?
Practically speaking, freelance marketplaces demand expertise, and it is easier to demonstrate and communicate through these narratives. However, thinking this way is not ideal for a developer, as it leads to a predefined solution without fully understanding the actual business problem.
Counterproductive :
A fixed narrative without considering the business context and the customised needs of the customer limits our ability to think of simple and effective solutions. This isn’t just about perfection; a narrow, fixed technology stack restricts engineers—who are essentially problem solvers—from making a meaningful impact on the business and delivering value by solving problems. This limitation constrains our thinking, as we are confined to a predetermined stack that can hinder creativity and innovation.
When a problem is better solved with a different tool, developers waste energy forcing their fixed stack to perform tasks it wasn’t designed for, resulting in fragile and inefficient systems.
Alternative Approaches: Asking questions?
Bridging the Gap: Understanding the Business Problem
Industry Shift: From Commodity to Innovation
Asking questions is truly critical, and the Problem-First Framework
WHAT: The Definition of the Problem
Before touching the “stack,” you must define the shape of the problem. If you don’t know what, you may apply a generic solution to a unique challenge.
WHY: The Business Justification
This is where critical thinking replaces habit. Asking why prevents the “Fixed Stack” from becoming a “Fixed Mindset.”
HOW: The Tailored Implementation
Only after the What and Why are clear, do you decide How to build it. This is where you become “stack-agnostic.”
A fixed technology stack can offer developers a sense of security, but it can also limit a business’s flexibility. By shifting your focus from asking, “What stack do you use?” to “What problem are we solving?”, you transition from being just a replaceable coder to becoming a valuable partner. Furthermore, relying on a specific stack can hinder your growth as an engineer, preventing you from thinking beyond the constraints and innovating to provide value for the business.
I am not against stack; I am against not asking questions or being fixed.