What Compounds
The career advice that doesn’t sound like advice
Most career advice is a trick — a hack, a framework, a way around the work. The advice that compounds is dull. That is why it works.
If I could send a few notes back to a younger me, none of them would be technical.
Own the work
Take responsibility for the work in front of you, and do it well. Over years, the single largest leverage you have in any job is that you can be relied on. That sounds boring. The compounding advantages usually are.
Be nice to everyone. Not as a strategy. Not because it pays off. Because the alternative is exhausting, and most of the people around you are doing harder work than you can see.
Take feedback seriously, without taking it personally. Junior engineers do one of two things with feedback: dismiss it as wrong, or absorb it as identity damage. Both are expensive. The skill is separating the signal from the sting — pulling out what is true and discarding the rest, including the parts that hurt for reasons that have nothing to do with the work.
Before asking someone for help, do the work yourself first. The exception is a deadline at risk — then ask early, not late. Outside of that, the struggle *is* the work — not the friction of being stuck, but the act of forming your own model of the problem before someone else hands you theirs. Skip that and you skip the thing you are actually paid to learn.
Serve the organization
The job is not to be a good engineer. It is to help the organization move forward. The two are correlated, but not the same thing.
That means asking the questions other people are not asking. Understanding what the product is for, who pays for it, where it is going. Pushing on decisions that look suspect even when they sit above your level. Plenty of capable engineers spend years optimizing their craft and never wonder whether the work is the right work for the company.
This is also why job-hopping every twelve months is expensive. The first year you learn where the bathrooms are. The second year, the system actually becomes legible — you start to see the joints, the politics, the parts that are real and the parts that are scaffolding. That legibility is when your judgment becomes useful. Leave at month thirteen and you burn the investment just before it pays. There are exceptions — a company unraveling, a role that was misrepresented, a manager you cannot work for — but make sure the reason is real, not a restless year mistaken for a broken job.
Stay long enough to be useful in a way only someone who has been there can be.
Pick the right thing
Most engineers I have watched fail were not unskilled. They were busy doing impressive work on the wrong thing.
Ask yourself, repeatedly: is this where my time should be right now? The question is uncomfortable, because an honest answer often invalidates the last week of effort. Ask it anyway.
The same restraint applies to the code itself. Solve the problem you have, not the one you might have at a hundred thousand users you will never reach. Over-engineering is not an architectural sin — it is an attention tax. Every hour spent hardening the wrong code is an hour not spent on what matters now.
Ship small, then iterate. A series of small changes beats one big release. Smaller diffs are easier to review, faster to revert, and quicker to expose a wrong assumption. The instinct to ship one big polished thing often hides a fear of being seen mid-thought — but even when the motive is pure, the mechanics still favor small.
And resist dogma. DDD is not the answer. Neither is TDD. Neither is the framework you read about last week. None of them survives contact with every problem. Each was forged in a specific context and breaks the moment you carry it somewhere else. The job is to pick the right tool for the work in front of you — language, framework, architecture, design. People who hold one methodology tightly have mistaken their preference for a principle.
Build your leverage
Invest in AI, then put in the reps. A cheap subscription gets you curiosity, not fluency. The judgment for when a model will handle a task cleanly, when it will bluff, when to push back, when to switch — that comes from volume. Pay for the better plan and use it until the tools stop feeling mystical. Calibrated intuition is the goal — knowing, without thinking about it, what these tools are good and bad at. You get there only by working at the frontier long enough that it stops feeling like the frontier.
Then use AI as a tutor, not a vending machine. Before writing code, talk to the model. Ask it to walk you through the codebase in your own language. Have it explain a component the way a patient senior engineer would, calibrated to what you already know. The real unfair advantage is not the code it generates — it is the synthesis it produces for you specifically. Engineers who use AI well are not the ones who type fastest. They are the ones who understand the systems they touch.
Then sharpen your environment. Engineers waste astonishing amounts of time fighting their tools — switching windows, hunting for the same command, breaking flow to look up syntax. Spend a couple of days getting your editor, shell, and daily workflow exactly how you want them. The setup feels indulgent. It pays back every working day for years.
The shortcut is the trap
None of this is clever. None of it is a hack. That is the point. The shortcuts do not compound — the unglamorous habits do.
Younger me would have skimmed this looking for the trick. There isn’t one.