You did the hard part. You can build the thing. You ship features, you read a stack trace without panicking, you can pick up a new framework over a weekend. That competence is real and you earned it.
So here is the uncomfortable question: what happens when coding itself starts losing value? Not disappearing, losing value. AI now writes the boilerplate, the tests, the first draft of almost anything. The thing you trained for, the part that used to make you stand out, is becoming the baseline everyone has. The differences that decide where you end up sit somewhere else entirely, and nobody really sat you down and taught you where.
My co-founder put together a short on this when the book came out.
Here is the longer version, with the reasoning behind each point.
Addy Osmani spent more than a decade at Google before joining Anthropic, and he put this into a book called The Effective Software Engineer. Three patterns run through it, and the shape underneath them is the whole point.
Efficient is not the same as effective
Doing something well is not the same as doing the right thing, and mixing them up is expensive. You can spend three months building a technically flawless feature that nobody uses. Clean code, full test coverage, zero business value.
The skill that protects you here is not faster typing. It is judgment: looking at the backlog and asking which of these actually matters, instead of which one is the most fun to build. Most engineers optimize for the interesting problem. The effective ones optimize for the problem that moves something.
Your code only travels as far as you can explain it
Finding the right solution is half the battle. The other half is convincing the organization to actually build it. Your ability to communicate does not sit next to your technical skill as a nice extra. It sets the ceiling on how far that technical skill reaches.
A great design you cannot get anyone to agree to is a great design that never gets built. Communication is not the soft thing around the real work. It decides whether the real work happens at all.
Invisible work does not get counted
You might assume people notice what you are shipping. In a busy company, they mostly do not. Promotion conversations happen in rooms you are not in, and the only version of your work that exists in those rooms is the version someone can describe out loud.
This is not about self-promotion. If your work never enters the conversation, it does not exist for the people deciding who moves up. Making your impact legible is a skill nobody teaches you on the way in.
So here is the pattern
Three takeaways, one shape underneath all of them. Choosing what matters, explaining it, making it visible: these are exactly the skills most engineers treat as optional, and exactly the ones that decide where a career goes. They were never on the syllabus, so it is easy to assume they do not apply to you. As AI takes over more of the pure technical work, they are quietly becoming the part that is actually yours.
This is not about your code getting worse. It is about the ground shifting under what “being good at this job” means, and noticing it before the people around you do.
Utterskills trains the skills beyond code that decide who advances: communication, ownership, and judgment. If this hit a nerve, that is the point.