I have been writing software professionally for a few years now and contributing to open source since 2018, which is long enough to have worked alongside some genuinely excellent engineers and to have noticed that they were not excellent in the way I expected.
None of them were the person who knew the most. Some of them knew noticeably less than the people around them about any particular technology. What they had was a set of habits, and the habits turned out to be more portable than the knowledge.
This is my attempt to write those down. It is a personal list, not a universal one.
1. They care about details that do not seem to matter
A clear variable name. A commit message that says why rather than what. Consistent error handling. Individually none of these is worth arguing about, which is exactly why they get skipped.
The compounding is the point. A codebase where every small decision went the easy way is not slightly worse than one where they did not — it is the thing everyone describes as "we should rewrite this."
I did not believe this until I maintained something for three years.
2. They understand rather than memorise
Knowing which incantation fixes an error gets you through today. Knowing why it was broken gets you through the variant of it you meet next month, which will not match any search result.
The test I use on myself: can I explain this to someone without repeating the phrasing I read it in? If not, I have memorised it.
This is slower up front and there is no way around that. It is also the only version that accumulates.
3. They are not loyal to their tools
The people I have learned most from did not identify as Go developers or Python developers. They picked what fit the problem and were mildly annoyed at having to have a preference.
Language loyalty is comfortable and quietly limiting. Every tool has a shape it fits, and being certain in advance that your favourite fits everything means you will occasionally be wrong at length.
4. Learning a new language changes how you write the old one
"The limits of my language mean the limits of my world." — Ludwig Wittgenstein
This is the one I underrated for longest.
Learning Go after C++ did not just give me a second language. It changed what I thought was normal — that errors could be values, that the concurrency primitives could be small, that a standard library could be worth reading straight through. I write better C++ now, and I have barely written any C++ since.
Every language is an argument about how programs should be built. Learning one is hearing the argument. You can disagree with it and still be better for having understood it.
5. They stay curious past what is required
The frontend developer who understands the query planner. The backend developer who knows why the render blocked. They are not doing this for a promotion.
Most interesting problems live at boundaries — between services, between layers, between teams — and the boundary is precisely where nobody's job description reaches. Knowing slightly more than you need on both sides is how you end up being the person who can see the whole failure.
6. This is a team sport, and the code is the smaller half
The best code nobody can work with is worth less than adequate code everyone can.
I have watched a technically superior design lose to a worse one because its author could not explain it, and I have watched an average engineer become the most valuable person on a team by being the one who reliably unblocked others.
Reviewing carefully, writing things down, answering questions without making people feel stupid for asking — none of this appears in a technical interview and all of it determines what a team can actually build.
7. Try things that are not obviously your path
The route to knowing what you want is usually a few things you turned out not to want.
Backend, frontend, infrastructure, data — moving between them is not indecision, and the time is not lost. Every one leaves you with a way of thinking the others do not have. My own path went through documentation and developer tooling before it went anywhere else, which at the time looked like a detour and turned out to be the most useful part.
8. The machine needs maintenance
"Sleep is the best meditation." — Dalai Lama
Your ability to think clearly is the tool you are actually being paid for, and it degrades in ways that are invisible from the inside.
Tired debugging is not slower debugging. It is worse debugging: you stop forming hypotheses and start changing things at random. I have lost whole evenings to bugs I fixed in ten minutes the next morning, which is a lesson I have had to relearn several times.
Walks, sleep, and things that have nothing to do with computers are not what you do after the work. They are part of it.
9. Follow what actually holds your attention
Interest is information. When something pulls you in enough that you look it up on a Saturday, that is worth paying attention to, because sustained attention is the scarce input and no amount of discipline substitutes for it.
This is not an argument for only doing what is fun. Most work is not. But over a career, the direction you drift when nobody is directing you is a better guide than any plan.
10. You are probably ready
The single most common failure I see in people I mentor is not applying. Not opening the pull request, not proposing the idea, not putting their name down for the talk.
Nobody feels ready. The people who look like they did just applied anyway.
The bar is consistently lower than it looks from outside, and the way you find out is by finding out.
What they have in common
Reading these back, only one of them is about knowledge. The rest are about attention — to detail, to other people, to your own state, to what you are drawn towards.
That is not a motivational point. It is a practical one, because knowledge has a short half-life and these do not. The specific things I knew five years ago have mostly expired. The habits have not.
None of this is a finish line. It is just what I have noticed so far, and I expect to disagree with parts of it later.