Operational work changed the way I think about software. From outside, it is easy to imagine that the clever part is the code and everything else is implementation detail. In practice, the difficult part is understanding what people really do, where a process becomes frustrating, and which parts should not be automated at all.
A person doing the work knows exceptions that never appear in a process diagram. A colleague may understand the data, another person the risk, and someone else why a certain step exists. The developer can connect those views, but cannot replace them.
One hand washes the other
There is an old expression that one hand washes the other. That is close to how good internal software gets made. People share context, test an early version, point out what does not match reality, and trust each other enough to say when an idea is not useful.
Even a brilliant person working alone will miss things. The strongest result usually comes from a group in which different kinds of knowledge can meet. The code may have one author, but the useful product is shaped by everyone around it.
Calmer work is a real result
The best tools I have worked on do not try to look impressive. They remove a repeated step, make the next action obvious, or bring the right information together before someone needs it. They leave responsibility with the person while giving that person a better starting point.
That is the standard I now try to use: not whether software can automate something, but whether it makes the work clearer, safer, and a little less tiring for the people who depend on it.