7 Engineer Habits That Matter
More Than Skill for a Raise

I've watched a lot of engineers who started at the same time, with the same starting salary, end up 2x apart on pay three years later. Most of the time the difference isn't who's the stronger coder. It's 7 habits they've been compounding since week one. This piece isn't about tech. It just breaks down the habits, so you can check yourself and fill the gaps.

Note: This article cites no private salary data and points at no specific individual. Every comparison is a write-up of patterns that are common across the industry, meant for self-reflection, not as a basis for hiring or performance reviews.

01 How Much You Care About Commit Messages

The difference isn't length. It's "thinking about the next person who reads this code."

Six months later a bug shows up and you (or a teammate) dig through git log for clues. If you can see "why this changed," you pin it down in 3 minutes. If you can't, you burn a whole afternoon re-reading the code.

This is the habit of "turning your present self into a teammate for your future self." You can't see it in the short term. Over the long run the gap is enormous.

02 How You React When a Coworker Slacks You

Every time someone hits a wall and comes to you, it's actually a moment that tests whether you can be trusted.

How fast you earn that trust decides "whether the next important task lands on your desk."

This isn't about "being a nice person." It's "building an asset." Every problem you solve for someone else earns you one more person willing to push back on your decisions.

03 How You Leave Comments in PR Reviews

Is writing real PR comments tiring? Yes.

But it's the way to "pull the whole team up to your level at the lowest possible cost." Your teammate fixes it once, learns it once, and next time writes it that way on their own.

A PR review isn't an audit. It's a classroom.

A year later, you'll notice the whole team's code style looks like yours. That's the seed of "Tech Lead influence." Not through a title, through comments.

04 What You Talk About at Lunch

This one is the easiest to overlook and has the biggest impact.

The first kind of talk is complaining. Feels good, compounds to zero.

The second kind is being curious about the problem itself. Sounds boring, but every lunch reinforces the self-image of "I'm someone who solves problems."

People who complain about work are running in place.
People who stay curious about problems are building assets.

One hour of lunch × 5 years ≈ 1,200 hours. Spent complaining vs spent thinking = a completely different trajectory.

05 What You Bring to a 1-on-1

Most people's 1-on-1 looks like this:

• "This week I did A, B, C"
• "Next week I'll do D, E, F"
• Done

That's a status report, not a 1-on-1.

A 1-on-1 that actually compounds looks like this:

• Progress (30 seconds, not the point)
• What you're stuck on + what you've already tried
• What you want to learn + a concrete plan + what support you need from your boss
• What task you want to take on (ask for it explicitly)

A 1-on-1 isn't a status report. It's "asking for opportunity."

People who don't ask never get it. People who ask get seen as "someone who wants to grow." Companies only invest in the latter.

06 Your Stance on Learning New Tech

The key isn't "learning fast." It's "sharing after you learn."

Create a "my learning notes" folder on the internal wiki, and write 1-2 posts a week, 300-500 words each.

Three months later, the team is searching that folder for answers.
Six months later, people in other departments are citing your docs.
A year later, when the promotion comes up, your boss has concrete evidence to point to: "he made the whole team stronger."

Sharing > learning.
Because the former makes your influence compound.

07 How You React When You Fail (the most critical)

Of the 7, this is the biggest dividing line.

On the day you take down production, or push one wrong line of code that makes the team work late, what comes out of your mouth?

Companies aren't afraid of you failing. They're afraid you don't know what you got wrong.

Every failure is a chance to show the signal "I can learn from my mistakes." People who can show it get treated as "worth investing in." People who can't get treated as "unreliable."

You don't have to apologize for failing.
You have to spell out where your judgment went wrong, why it went wrong, and how you'll avoid it next time.

The takeaway

Seven habits, and not one of them is "algorithms," "frameworks," or "new tech."

They're all built up from "every small decision."

• What you write in every commit message
• How you answer every time a coworker asks
• How many comments you leave in every PR review
• What you talk about over every lunch
• Whether you speak up and ask in every 1-on-1
• Whether you share what you learn
• What comes out of your mouth after you fail

Skill is the ticket in. Habits are the ceiling.

What most engineers are stuck on isn't "not enough skill." It's habits they never built.

This piece makes no "7 killer moves, instant results" promise. All 7 are the compounding kind. You start with tomorrow's commit message, and you only see the change six months later.

But that's exactly where its power is. 90% of people will nod along and never do it.

You read this far, which means you want to do it. That commit tomorrow, give it an honest shot.