How to Actually Grow as a Junior Dev in Your First Year
Looking back as a 7-year senior -- what genuinely worked during year one
I Nuked a Branch on Day One
My career started by botching a git merge and wiping out the entire develop branch. My mentor restored it in 27 minutes, but those 27 minutes felt like 3 hours. Face beet red, staring at my monitor. The senior next to me said "Don't worry, I almost nuked the production DB in my first month" -- still not sure if that was comfort or a warning.
Seven years in, I've got some things I wish I could tell past me. But everyone's situation is different, so take this as my experience, not gospel.
Start Reading Other People's PRs
In my first year, I treated code reviews like report cards. Approve felt great, Request Changes ruined my day. (So naive looking back.) But the real inflection point was when I started reading other people's PRs.
Read one senior's PR a day. Ask yourself why they chose that structure, why that naming, why that library. You won't understand 70% of it at first. Do it for three months and your code style will transform dramatically.
I learned the pattern of extracting logic into custom hooks by reading my mentor's PRs. Before that, I was cramming 340 lines into a single component. useEffect with fetch logic, error handling, and state updates all jammed together -- looking at that code now is terrifying.
Actually Read the Error Message
I'm not joking. Most first-year devs don't read error messages -- they copy-paste straight into Google. I did the same thing. Red text appeared and I reflexively copied it into the search bar.
But the answer is in the last two lines of the error message more often than you'd think. TypeError: Cannot read properties of undefined -- start by tracking down which variable is undefined. Follow the trail of why it's undefined and you'll solve it in 5 minutes.
I once spent 30 minutes digging through Stack Overflow, came back, re-read the error message, and found the answer on line two. That was a humbling moment. This one habit tripled my debugging speed.
How You Ask Questions Changes Your Career
"Why isn't this working?" is the worst question. From the mentor's perspective, they now have to ask "What thing?", "How is it not working?", "What have you tried?" I asked questions like this constantly in year one and heard plenty of sighs. Honestly, I probably annoyed the hell out of my mentor.
"I'm trying to do X, attempted Y, and got error Z. I checked the docs about A but it seems different from my situation" -- framing it this way does two good things. Half the time you find the answer while organizing the question. The other half, the answerer can jump right in with context.
(Some call this "rubber duck debugging" -- whether you're explaining to a duck or a human, the process of articulating is what does the work.)
Juniors who ask good questions get proactively helped by seniors. It's not office politics -- people naturally gravitate toward those who are easy to help.
Dig Into Company Code, Not Side Projects
In year one, I spent every weekend on side projects. Three todo apps, two weather apps, one half-finished blog. "Gotta build the portfolio" was the obsession. Looking back, I would have grown twice as fast spending that time going deeper into company code.
Understanding why legacy code was written a certain way beats building 10 todo apps. Todo apps are "solving problems you already know the answer to." Legacy code is "confronting real-world complexity."
When you see something in the company codebase and wonder "why was this written this way?", run git blame and trace the commit history. You'll discover what constraints that code was written under. Sometimes it's a hotfix that 3 people wrote overnight 3 years ago, still alive today. Understanding that context changes how you see the code.
10 Minutes a Day Is Enough
Every day before leaving, I spent 10 minutes jotting down what I learned in Notion. Even a one-liner like "Today I learned why useMemo preserves referential equality" works. "Learned that as const in TypeScript narrows to literal types" -- stuff like that.
Read it again six months later and you'll think "I didn't even know this basic thing?" When burnout hits, these notes offer some comfort.
(Honestly, I didn't write every single day. Maybe 15 days a month? Still helped.)
If It's 70% Done, Just Submit It
In year one, I'd agonize for three hours before opening a PR. Renamed variables ten times, added unnecessary abstractions, ended up with code more complex than what I started with. Seven years later, here's what I know: if it's 70% done, submit the review.
Just write "Not finished yet -- checking if the direction is right." If the direction is wrong, finding out early is a win. Getting "this is the wrong approach" feedback after polishing to 100% is actual hell. I went through that twice. Threw away 3 days of work once.
If I could tell year-one me just one thing: "It's completely normal that you can't do things yet, so go ahead and be wrong more." The person who wiped a branch with a bad git merge is now teaching new hires how to use git.