The part of your job that will matter most in ten years is probably not happening in your editor.
Look honestly at where the friction was on the work you did this year. Very little of it was the code. It was the requirement that meant one thing to the person who wrote it and something else to the person who built it. It was the finance team needing a number nobody could produce. It was support carrying a manual workaround for eight months because nobody ever translated their pain into something an engineer could act on.
Those are the expensive problems, and they live in the space between people who use different vocabularies.
Machines are getting very good at the work that lives inside one vocabulary. Turning a clear specification into working code is exactly the kind of task that keeps getting cheaper every year. What stays hard is deciding what should be built at all, for whom, with which tradeoffs, when the people who know the answer do not speak in interfaces and the people who can build it do not speak in customers.
So build that muscle on purpose.
Spend an hour in the support queue. Not a report about the support queue, the actual queue. You will learn more about your product in that hour than in a month of tickets.
Ask someone in sales what customers ask for that we cannot do, and what they end up promising anyway. That gap is a roadmap whether anybody has written it down or not.
Learn just enough of the other side's language to be useful. What margin means. What the compliance deadline actually requires. Why the finance calendar has the shape it has. You do not need to become an expert. You need to stop needing a translator.
And practise explaining a technical constraint without jargon and without condescension. It has a real ceiling as a skill, and almost nobody trains for it deliberately.
The engineers who are hard to replace are not the ones who type fastest. They are the ones who can sit in a room where nobody shares their vocabulary and leave it with everyone agreeing on what happens next.
Nothing has come close to automating that.
– Asael Shinder
Top comments (0)