Senior Devs Don't Write Better Code. They Think Differently.
I spent 3 years pair-programming with staff engineers at two FAANG-adjacent companies and realized the gap isn't syntax or frameworks. It's a completely different mental model for what 'done' even means. Here's what actually transfers.
The first time a senior engineer reviewed my PR, she didn't touch the logic. She deleted my comments. All of them. 'If you need a comment to explain what this does, the code is wrong.' I thought she was being mean. She was being precise.
1. They read code like a detective, not a student
Junior devs read code top-to-bottom. Senior devs start at the thing that's most likely to be wrong. In 2023, I watched a staff engineer at a 200-person fintech debug a production incident affecting $340k/day in transaction failures. She opened the codebase and went straight to the retry logic. Not the error logs. Not the stack trace. The retry logic. 'Distributed systems fail at the boundaries,' she said. She found it in 4 minutes. I'd have spent 2 hours.
The mental model matters more than the tools. She wasn't smarter. She had a better prior on where bugs live.
2. They're obsessed with the call site, not the implementation
When they write a function, they write the usage first. Pseudocode it:
// They write this first:
result = processPayment(user, amount, idempotencyKey)
// Then figure out what processPayment needs to look like
// to make that call site cleanThis sounds minor. It's not. It forces the API to be human-shaped instead of implementation-shaped. Your future self is the user. Design for them.
3. They distrust cleverness
The most senior engineer I've ever worked with has a rule: if you're proud of a piece of code, it's probably wrong. Clever code optimizes for the writer. Boring code optimizes for the reader at 2am during an incident. These are not the same person, and 2am reader wins every time.
4. They log for the next person, not for themselves
Most devs log what they needed to debug during development. Senior devs log what an on-call engineer with no context will need at 3am. There's a Datadog query difference between log.info('processing') and log.info('payment_processor.start', {userId, orderId, amount, idempotencyKey, attempt}). The second one costs 40 characters. The first one costs your Saturday.
5. They write the test that would have caught the last bug
Not comprehensive test coverage. The specific test that would have prevented the last production incident. This is a completely different discipline. Coverage metrics are a vanity stat. The question is: does your test suite encode your team's hard-won knowledge about failure modes? If someone fixed a bug without adding a regression test, the knowledge lives in one person's head and leaves when they do.
6. They say 'it depends' and then actually answer
Juniors hate ambiguity and pick a side fast. Seniors name the tradeoffs, identify the load-bearing assumption, and give you a concrete recommendation. 'It depends on whether you're optimizing for read or write latency, and given your traffic pattern in Datadog right now, I'd go with option B' is a complete sentence. 'It depends' alone is an abdication.
7. They treat naming like architecture
A bad name is a distributed lie. Every place that name appears, someone builds a mental model on top of it. If user sometimes means authenticated session and sometimes means database record, you don't have a naming problem. You have a correctness problem waiting to happen. The time to fix it is before the second usage, not the twentieth.
8. They make the PR reviewer's job trivially easy
Not by writing simple code. By writing a PR description that says exactly what changed, what didn't change, and what you're uncertain about. Senior engineers know that review quality degrades fast when reviewers have to reconstruct intent. A good description isn't documentation overhead. It's the cheapest correctness check you have.
9. They know what they're not changing
This one took me the longest. The most important word in a senior engineer's vocabulary is 'scope.' Every change has a blast radius. They're not more careful than junior devs. They're more aware of what they're leaving alone on purpose, and they make that explicit. 'This PR doesn't touch the auth flow. That's a separate ticket.' That sentence has saved production systems. I've seen it.
None of these habits are about being smarter. They're about having thought through failure modes enough times that your defaults shift. You can shortcut the time by finding the senior engineer willing to be annoyed by your questions. That's the actual cheat code.