My last two jobs came through recommendations from former colleagues. Someone just said "you should talk to Avraam." I used to think that was luck. I don't think that anymore. It was years. Years of showing up, being useful when nobody was watching, not disappearing when things got difficult. You can't compress that timeline. There is no faster algorithm for becoming the person someone vouches for.
I've been thinking about this a lot lately as I watch the industry sprint toward shipping everything faster. Velocity is the metric. Friction is the enemy. Time is pure waste to be optimized away.
I get the instinct. I've felt it. But there's a category of things in software (and in careers, and in communities, and in life) where time isn't inefficiency. It's the input.
My son's class planted these at the Kita. Each cup has a child's name on a little stick. Nobody can make them grow faster. You water them, you wait, and eventually something comes up.
What time actually builds
In a codebase I've worked there was a service everyone was afraid to touch. It does something odd. It looks like it could be refactored. But there are a few comments and a linked incident number, and the person who wrote it explained exactly why the obvious version will corrupt data under a very specific race condition that only appears under production load.
That comment isn't just documentation. It's institutional memory. It exists because someone was present long enough to live through the incident, understand the root cause, and leave a record for the next person. You cannot vibe-code that. You cannot ship it in a sprint. It accumulates over time or it doesn't exist at all.
The same is true for trust within a team. There's a threshold, I think of it as two jacks or better. In draw poker, you need at least a pair of jacks to open the betting. You can't bluff your way into opening with a weak hand. Below that threshold you pass, no matter how confident you feel. Trust between engineers works the same way. Below a certain tenure, below a certain track record of showing up and following through, you're still playing with a weak hand. Nobody's going to hand you the design decision or defend your judgment in the meeting you're not in. That credibility accumulates through repeated presence, and it cannot be shortcut.
The code that forgets its own reasons
There's a kind of debt I've started paying more attention to. You probably know technical debt, shortcuts that compound over time. What I'm describing is different, it's what accumulates when code exists but nobody recorded why it exists.
In teams that move deliberately, intent gets captured. There's time to write the ADR, to leave the comment, to have the conversation that becomes shared context. In teams obsessed with velocity, intent gets silently discarded. The decision gets made, the code gets shipped, and the reasoning never makes it out of someone's head.
A year later, nobody knows why the service doesn't use the standard client library. Was it a performance issue? A licensing concern? A personal preference? Nobody left a note. So the next engineer plays it safe and doesn't change it. Or they change it, and something breaks, and now you're in an incident you didn't see coming.
This is the hidden cost of speed culture. Not just worse code. Code that has forgotten itself.
I'm not making an argument against fast iteration or any of the things that make modern software development genuinely better. I use those tools. I'm glad they exist.
What I'm saying is that there's a category of thing, reputation, trust, community, institutional knowledge, the kind of codebase people actually want to work in, that doesn't respond to acceleration. It requires duration. Consistent presence. Following through when it's inconvenient. Being there for the incident at 2am and then writing down what happened so the next person doesn't have to be.
Big things take time, great things take more.
The engineers I most respect aren't the ones who shipped the most in the least time. They're the ones who are still around. Who are still curious. Who have a body of work that built over years into something nobody could have assembled in a sprint. Who left things better than they found them, in codebases, in teams, in communities, in the people around them.
That's not something you optimize. That's something you do.
