My first computer was not a toy. In Brazil in the early 1990s, hyperinflation meant a paycheck could lose value while you waited to cash it. I still have my work booklet, the CTPS, where my monthly salary went from about Cz$22,000 in 1991 to almost Cz$14 million in 1993. I did not become a genius in two years. Inflation did that.
That is how I learned what a computer was for. It was not a box for games or a reason to chase the newest release. It was a tool to solve a real, painful problem: how does a person keep a business alive when money rots overnight? By the time I was writing database applications in Clipper and DBase, I already understood that the tool was only as valuable as the problem it solved.
I still run every new thing through the same progression: from “what does it do” to “what can I do with it” to “what problem does it solve” and finally “for whom”?
The first question is the easiest. A new language, framework, or AI tool has a feature list. The second question is about fit: can I use this with the skills I have and the work I actually do? The third and fourth questions are where the real decision happens. If I cannot name the problem or the person living with it, the tool is just inventory.
I do not get excited by the “juggling shiny toys” conversations. A new front-end library appears and people ask whether I am moving from Angular to React, or from .NET to Java. I have no strong feelings about any of those names on their own. To me they sit on the same shelf: hammers and screwdrivers. If one helps me build something that makes someone’s day easier, I will pick it up. If it is only a reason to rebuild the same project with a different badge, it stays on the shelf.
This is not a new pattern. Every few years a tool promises that business users will not need programmers. The users build something, their needs outgrow it, and the company calls someone to clean up the mess. I have done that rescue work many times. The tool got the user started, but it did not understand the problem. That still took a person.
I recently sat in a conference room while a vendor pitched an AI product to business owners with the same promise: “With this tool, you won’t need developers, because developers don’t know your business.” That line stings because it is sometimes true. There are developers who are so married to their favorite stack that they forget the business around it. The ones who survive are the ones who step away from the keyboard and learn what the owner is actually trying to run. When a developer can name the problem, the business owner does not want to replace them with a tool.
The opposite mistake is collecting tools for their own sake. I have seen resumes stacked with frameworks and portfolios full of side projects that never shipped. The question I keep near them is the same one I ask myself: is there a demand for this, or am I just creating inventory? Inventory costs time and attention. It does not solve problems.
A better use of attention is to watch how people work. I love visiting client sites when I can. I look for the details the requirements document will miss.
- Is the user wearing gloves while using a touchscreen? Then a tap-friendly interface is a bad fit.
- Are there sticky notes around the monitor? That usually means the user is copying data from one screen to another because the system does not hold context.
- Does the person wear a headset and switch between talking to a customer and typing into the app? Then the workflow is split, not slow.
- Does the user stand because the station is shared, or because of back pain, or because the work forces them to walk back and forth?
You cannot answer those questions from a conference room. The work happens in a specific place, with specific constraints, and the right tool is the one that fits that reality. This is one reason I return to task-based thinking over data maintenance: the problem is not “how do I store this address” but “why is the address changing right now.” I have written about that shift in CRUD Is Solved, Focus on Workflows, and it still shapes how I choose what to build.
Tools also change under your feet. I started with DBase and use customers, then moved from Clipper to FoxPro to Visual Basic and ASP.NET, and everything that came after. Storage mechanics, UI patterns, and deployment targets kept shifting. The constant was the question: what is the person trying to get done? If I answer that clearly, the language becomes a detail.
That does not mean tools do not matter. A well-chosen language feature can remove friction. When C# added pattern matching and saved me two hundred keystrokes, I noticed, because those keystrokes were standing between me and a real problem. The feature solved something for me. The same applies to modern editors, AI tools, and testing frameworks. They are worth learning when they make me better and/or faster at the work that matters. If they only make me faster at creating inventory, they are not helping.
A tool is worth learning only if it helps you solve a real problem for a real person. If you cannot name the person and the problem, you are not building value; you are collecting inventory.
This (AI-generated) family doesn’t want a hammer (the tool you use) or a house (what you build); they want to satisfy their housing needs (what they hope you to help them with).
Once the person and the problem are named, the next question is what we put in front of them. The next post looks at why most users do not want more data.
Further reading
- Spreadsheets and Hyperinflation
- Beyond the Tool: What Are We Actually Building
- The Consultant’s Superpower Isn’t Mind Reading
- CRUD Is Solved, Focus on Workflows
Leave a Reply