About six months into my first dev job, I had this conversation with my manager that stuck with me. He said something like, “the juniors who get promoted aren’t usually the loudest ones. They’re the ones whose names come up when people are trying to remember who fixed something tricky last quarter.”

That reframed how I thought about visibility at work. Being noticed isn’t about being noticed. It’s about being remembered for the right things at the right time.

I want to share what actually worked for me in my first three years. Not the influencer advice. The boring stuff that compounded.

Get really good at one specific thing

The trap juniors fall into is trying to be generally useful. You end up known for nothing in particular and easily forgotten when interesting work gets distributed.

The opposite move is to be known for one specific thing within your team. For me, it was internal tooling. I noticed our team was losing a lot of time to repetitive tasks - generating test data, deploying preview environments, running local replicas of staging services. I started building small CLI tools that automated these. Nothing fancy. But after about four months I was the person people came to when they needed any internal tool improved.

That niche made me the obvious person to put on a bigger tooling project, which turned into a real promotion case at the next review cycle. The pattern works at any scale - find a niche your team actually needs filled, fill it, and become the default for that area.

Write good commit messages and PR descriptions

This sounds trivial. It’s not. The amount of credit you get for your work scales with how easily other people can understand what you did and why.

A junior who writes commit messages like “fix the thing” gets remembered as someone who fixes things, vaguely. A junior who writes commits like “Resolve race condition in payment retry loop where two retries could overlap during slow DB writes” gets remembered as someone who understands the system deeply enough to articulate problems precisely.

Same goes for PR descriptions. The PRs I’m most proud of from my first year all have descriptions that include: what changed, why, what I tested, what I’m uncertain about, and what reviewers should look at carefully. They take 10 extra minutes to write. They got me a reputation as a thoughtful engineer way out of proportion to the actual code quality.

Document things nobody else wants to document

There’s always a pile of undocumented stuff that everyone vaguely knows is a problem. The deployment process that lives in someone’s head. The local dev setup that takes new starters two weeks to get right. The flaky test nobody wants to investigate.

Pick one of these and write the doc. The act of writing it forces you to learn the topic deeply, and the doc itself becomes a reference that gets cited (with your name on it) for years.

I wrote a doc about our environment setup process in my first month. Three years later it’s still in active use, and new starters are still pinging me asking follow-up questions because my name is on it. Free credibility, ongoing.

Be ruthlessly reliable on small things

This one matters more than people admit. If you say you’ll have something done by Thursday, have it done by Thursday. If you said you’d review someone’s PR by EOD, review it. If you took an action item in a meeting, follow up on it.

Most juniors are flaky on the small stuff. The ones who aren’t get a disproportionate amount of trust because reliability is a real signal of underlying capability. Senior engineers notice and remember.

The compounding part: when you’re reliable on small things, people start trusting you with bigger things. Bigger things lead to better promotions. The whole arc starts with not flaking on the trivial.

Get good at code review

Code review is the most underrated junior dev superpower. It’s a way to learn deeply (you read way more code than you write), demonstrate technical thinking, build relationships across the team, and contribute value beyond your assigned work.

The trap is leaving useless reviews (“LGTM” or nitpicking style). Useful reviews ask questions, identify edge cases, suggest concrete improvements, and stay focused on what matters. The discipline is “would I be embarrassed if this PR shipped with the bug I’m about to flag?” and “is what I’m flagging worth the author’s time?”

I made a deliberate effort in my second year to do thorough reviews on at least three PRs a week. The quality of my reviews became a thing other people commented on, which led to me being included in design discussions because people knew I’d actually engage with the technical substance.

Don’t just consume - publish

This one is uncomfortable for a lot of self-taught devs because we’re used to learning quietly. But publishing - even small things - changes how you’re perceived.

I started a habit of writing a short technical post once a month. Nothing groundbreaking. Just things I’d learned recently or interesting bugs I’d debugged. Most posts got 50-200 reads. A few got picked up and shared more widely. The cumulative effect over two years was that I had a body of writing that demonstrated I could think clearly about technical topics.

When promotion conversations happened, having that writing made the case much easier. “Here are 24 posts demonstrating thinking across these topics” beats “trust me I know things.”

A note on AI

The juniors I see succeeding most in 2026 are fluent with AI tools but not dependent on them. They use Cursor and Copilot and Claude Code aggressively but they understand what they’re shipping. They’re faster than juniors three years ago because they’re not stuck on syntax or boilerplate. They’re spending the saved time on the harder stuff - design, debugging, communication.

The juniors who struggle are the ones using AI as a substitute for thinking. They ship code they can’t explain, can’t debug independently, and don’t really understand. This is visible in code review and devastating to their reputations. Don’t fall into that trap.

If you want to read more about how the AI shift is changing junior dev work, the MIT Technology Review has been doing reasonable coverage on this through 2025-2026, and Australian firms like Team400 have been writing usefully about how the work is changing inside teams that ship AI products.

What I wouldn’t do

A few things people recommend that I don’t think work:

Posting hot takes on Twitter/LinkedIn. Doesn’t translate to your actual workplace. Your manager doesn’t care about your Twitter following.

Volunteering for every visible project. Spread thin, deliver poorly, get a reputation as someone who overcommits. Better to do fewer things well.

Asking for promotion in your first year. Premature. Build the case for two years, then make it.

Fake-it-til-you-make-it confidence in technical discussions. Senior engineers can tell. Better to say “I don’t know but I’ll find out” than to bluff.

The arc

Looking back, my first three years were a slow accumulation of small reputation deposits. None of them were dramatic. None of them required me to be the loudest person in the room. They added up because they were consistent and aligned with what the team actually needed.

The juniors who get noticed in 2026 aren’t the ones working hardest at being noticed. They’re the ones doing the work that needs doing, doing it well, and being remembered when the next opportunity comes around.

That’s the whole game.