The Codebase You Sit In Rubs Off On You

Spend all day at a fish market and you'll leave smelling like fish, even if you never touched one.

Spend your day in a codebase full of shortcuts, and you'll start writing shortcuts too, even if nobody told you to and even if you swore you never would.

That's how environments work. They rub off on you, whether you notice it or not. And in engineering, this isn't a metaphor it shows up in your git log.

The lie of "it's all about discipline"

Most engineers think their habits come from training, courses, or sheer effort. If your code is sloppy, the assumption is you didn't try hard enough. If it's clean, you must have "good discipline."

That's only half true. A huge part of how you code comes from what surrounds you every day, on repeat, long before you're conscious of it:

• The PRs you review, and the ones that get rubber-stamped instead of actually reviewed.
• The Slack threads where someone asks "does this really need a test?" and the answer is a shrug.
• The postmortems you sit through, the ones that hunt for a person to blame versus the ones that hunt for a broken process.
• The teammate whose code you copy-paste from at 2am because it's the closest example you can find, bugs and all.

None of this announces itself as a lesson. Nobody sends a Slack message saying "today I am teaching you to skip error handling." It just seeps in through repetition, the same way an accent seeps in from the people you grow up around.

Where this actually shows up in production

This isn't abstract. It shows up as specific, recognizable symptoms:

Silent try/catch blocks everywhere. Not because anyone taught "swallow your errors," but because the first three examples of error handling you saw in that codebase did exactly that, and you pattern-matched off them without questioning it.

A team where nobody writes tests for "obvious" changes. Six months later, someone ships an "obvious" one-liner that takes down checkout for twenty minutes. The postmortem calls it human error. It was actually a cultural default nobody chose on purpose, it was absorbed.

Incident channels full of finger-pointing instead of timelines. New hires learn within a week that admitting a mistake early gets you blamed, so they learn to sit on problems until they're unavoidable. That delay is the expensive part, not the original mistake.

Commit messages that are just "fix," "update," "wip." You'll find the one senior engineer on the team who started that pattern years ago, still committing "fix" today, and everyone quietly inherited it.

Compare that to a team where the senior engineers write commit messages that explain why, not just what; where someone flags an edge case out loud in standup instead of letting it slide; where an incident review ends with "here's the missing guardrail" instead of "here's who missed it." Sit in that environment for six months and you'll start doing the same things, not because you decided to, but because that's what normal looks like now.

Why "just work harder" doesn't fix this

If your habits were purely a function of effort, then two equally hardworking engineers in different environments should converge on similar code quality. They don't. Drop the same disciplined engineer into a team that treats testing as optional, and within a year their testing habits will have eroded, not because they got lazy, but because the environment stopped rewarding the behavior and stopped modelling it.

This is also why "hire good people and leave them alone" doesn't scale culture. Good habits decay under a bad environment faster than bad habits improve under a good one is slow. Osmosis runs both directions, and it runs constantly, not just during onboarding.

Changing what you're surrounded by is the actual lever

This is why the fastest way to level up often isn't another course or another book, it's deliberately changing what you're marinating in every day:

• Review code from engineers better than you, even when it's not required. You're not looking for bugs; you're absorbing their defaults.
• Sit in on incident calls outside your own team. Watching how a genuinely good incident is run, calm, timestamped, blameless, recalibrates what "normal" looks like faster than any postmortem template.
• Follow people who write and talk publicly about the specific problems you want to get better at. Your feed is an environment too. It rubs off exactly like your team does.
• Choose the side projects and open-source codebases you spend your evenings in as carefully as the one you're paid to work in. If every codebase you touch after 6pm is a mess, don't be surprised when "mess" starts to feel acceptable at 10am.

Your first team teaches you more about "how to engineer" than any style guide, wiki page, or onboarding doc ever will, whether that team is excellent or quietly broken. And it keeps teaching you, every day you stay in it, long after onboarding ends.

The real question

The scent of your environment always follows you into your next commit.

So the question worth asking isn't "am I working hard enough?"

It's "what am I letting rub off on me, and is it actually who I want to become as an engineer?"