The Real Skill: Solving Problems Users Don’t See

One click is all it took to wreck hours of work. We had a process that went like this: someone would export a package from one environment, start the import into another, and forget to click “no” when the system asked about importing Encompass fields. The environments were so vastly different that importing fields could wreck production. The long-term fix was always to get the two environments to match, but that was a very big ask.

If a user remembered to make a backup, recovery was an annoyance. If they did not get a back-up, it was hours of cleanup. Every. Single. Time.

This was such an easily repeatable offense, but not one time did anyone really draw any attention to it. I was baffled when I came across it.

Seeing the Risk Before the Damage

Typical users tend to work around problems instead of removing them. These things are taken for granted that it’s just how you have to work. “You just have to be careful”. Reminders and notes will eventually get buried. The expectation becomes “just remember to click no.” I remember being trained by people who had post-it notes of all things not to do, but it was so specific and avoidable, I’d cringe listening.

The problem with all of this is people do not always remember, or they get in a hurry and click something by mistake. And when the cost of forgetting is measured in hours of lost time, “just be careful” is not a solution.

Removing the Opportunity for Error

I built a small tool that strips fields out of the export package entirely. It was a quick little import, but easily done. Again, this isn’t optimal because now you have to remember to upload the form, but there are plenty of time for checks for that. A medium-term solution might be to have a custom import built (not use the native import) that checks for fields. But you have to weight the time vs benefit. For now, the question about importing fields never appears because there is nothing there to import; the dangerous choice is gone.

It is not a complicated tool. It does not need to be. What matters is that the process is now safe by default. Users do not have to remember the one extra step.

The Big Picture

Good developers fix problems that land on their desk. Great developers notice the quiet, recurring pain points that everyone else has learned to live with and they eliminate them entirely. A side note: this is typically a huge win with regular users. If you can save them time, make their jobs easier, they will be much more apt to work with you on things like new features or be more patient when you introduce a bug.

This is not about clever code; it’s about paying attention. Look for the small mistakes that carry big consequences. Watch for the workarounds that people shrug off as normal. When you find them, solve them in a way that prevents the mistake from ever happening again.

Why This Matters Now More Than Ever

AI can write a function in seconds. It can refactor a file or suggest an architecture diagram before you can drink half of your coffee. What AI cannot do is walk into a process, notice the places where human error is lurking, and design those traps out of existence. That is still on us. This area is where developers add real value. I think this responsibility will always be ours.