Somewhere in your company there is a queue where people find out what your software actually does, and there is a good chance you have never looked at it. Support. The inbox, the phone rota, the chat widget, whatever shape it takes where you work.
Ask to spend a day there. Not to help, and not to fix anything. To sit next to someone and watch.
I have sent a lot of people to do this and none of them came back unchanged, because a day on that queue teaches you things that are simply not available anywhere in the repository.
You learn the vocabulary. Real users do not call it a resource or an entity or a record. They call it the job sheet, or the docket, or the Monday file. Every one of your error messages, field labels and log lines was written in a language your customers do not speak, and you will hear the translation happening live, forty times in an afternoon.
You learn what is actually used. The feature you spent three weeks on gets mentioned once. The screen nobody on your team thinks about turns out to be where four hundred people spend their entire working day, which is worth knowing before you refactor it.
You learn the real failure modes. Not the ones in your incident history, the small repeating ones that never reach your backlog at all because support quietly built a workaround years ago. Ask to see that document. It is a defect list nobody has ever costed, written by people who assumed engineering was not interested.
And you learn the shape of the edge cases you argued about. The odd case somebody dismissed in a design review is nine percent of customers, and the agent beside you can tell you which nine percent.
A few rules so it goes well. Say plainly that you are there to learn and not to audit anyone. Do not fix things live and do not promise timelines, because a promise from a visiting engineer becomes a commitment before you get back to your desk. Write down three specific things.
Then go back, fix one of them, and tell the person who showed you. That is how you are invited again.
– Asael Shinder
