If you train someone to build software, they will see software-shaped problems. That was certainly true for me. Someone describes a painful process, and before they have finished the sentence I am already picturing a form, a table, a workflow.
The uncomfortable thing I have had to accept is that a fair number of problems presented as software problems are not.
Some are policy problems
If a rule is ambiguous, automating it does not resolve the ambiguity. It encodes it, and now the ambiguity is harder to see and harder to change. The right move is often to get the rule agreed first, which is slower and involves no code at all.
Some are volume problems in disguise
Building something to handle a task that occurs rarely can cost more, over its lifetime of maintenance, than the manual effort it replaces. Not always. But it is worth actually asking rather than assuming that automated is definitionally better.
Some are clarity problems
Occasionally the real issue is that two teams have different definitions of the same term, and everything downstream is confused because of it. No feature fixes that. A shared definition does.
Why this matters for how I work
This is not an argument against building things. Most of what I work on genuinely does need to be built. It is an argument for spending the first part of a problem understanding it rather than designing it.
The technical background is still an advantage here. Knowing roughly what something would take to build is exactly what lets me ask whether it is worth it. I just try to use that knowledge to evaluate rather than to jump.