Reflections on Year One as a Junior Developer

(Brief background: After more than a dozen years in journalism, digital marketing and publishing, I enrolled in the Flatiron School full-stack coding bootcamp in December 2020 at age 34. I graduated in April 2021 and started my first job as a junior frontend developer at TextUs on July 1, 2021.)

During my former career as a journalist, my newspaper assigned me to cover the bareback bronc competition at a local rodeo. If you’re not familiar, the gist is that a rider climbs onto the back of a pissed-off horse, grabs a fistful of rope, and tries to hang on while the animal leaps and twists and kicks with graceful, rippling violence.

The goal is simply to last eight seconds. That eight seconds, as you might imagine, is an eternity of confusion and chaos.

That’s roughly how it feels to start your first day as a junior developer—just with a slightly diminished risk of shattered bones.

You’re handed a new computer, told vaguely to “set up your environment” (yes, new boss and coworkers, I definitely know what that means and how to do it, totally, yeah), and then the tickets start rolling in. I’m painting with a hyperbolic brush — any company worth its salt will provide you with more direction and support than that. Mine certainly did.

My inaugural ticket, which took multiple days, involved a minor CSS fix for a misplaced line break. One year later, a couple of my more recent tasks have included rendering dynamic analytics tables with a sort-by-column feature and adding support for rich media like PDFs and images to our text-messaging service, complete with drag-and-drop and copy/paste functionality for uploading files.

That’s not to say I’m any sort of expert after only 12 months of professional programming. Far from it—if anything, I’m more acutely aware of my limited knowledge. Any of those tickets would be trivial for most engineers after a couple months on the job. Growth happens incrementally, however, and that’s what makes dedicated reflection such a powerful practice.

With that aim, here are a few lessons I’m taking away from Year One as a software developer that may be beneficial to others that follow:

Set a learning goal for every project to keep mundane tasks engaging and stressful tasks manageable

A boring CSS fix doesn’t have to be a chore. If it’s truly something you can repair on autopilot, take the extra five minutes to reread the MDN docs about that property in case you can glean anything new. No one knows how to make white-space, word-break or overflow-wrap do what you think it will the first half-dozen times.

Set two goals when you’re starting a new ticket: completing the requirements, and improving at least one tool in your personal kit.

It could be as simple, again, as giving the white-space docs a thorough top-to-bottom scan. Or, for more hefty projects, it could stretch as far as making a point of using TypeScript generics or practicing .reduce() or becoming an expert with a new third-party library.

I spent weeks mired in date/time quicksand on several separate-but-related tickets. Though I wanted to toss my MacBook into a vat of acid on a daily basis, after a few days I realized how much my understanding of date/time formatting had improved in a short period, almost without me noticing.

I decided to invest a little extra time in learning more about ISO strings, the inner workings of the Date() object in modern JavaScript, and the current state of date/time libraries. Might as well go all-in, right? Spending a few extra hours on those tickets saved me dozens of hours later, and made me more confident with concepts that are often difficult for early-career developers.

Embrace the concept of total ownership over your workload

No one is coming to save you. Get comfortable with that mindset, especially when a project feels overwhelming.

I’m not saying teammates won’t render aid. If I post on Slack that I’m having trouble, I barely have time to put on my headphones before three different people are inviting me to a video call. What I mean by total ownership, rather, is to internalize that the problem is yours and yours alone to solve—senior engineers should be viewed as a lighthouse to guide you, not a life raft to bail you out.

I’ve had several tickets that filled me with dread as I read over the requirements. As much as I wished it would get reassigned or a senior would swoop down and write elegant code under the pseudonym of my Github username, the ticket was still there every time I refreshed the page.

Engineers, of course, are familiar with breaking large tasks into smaller ones, picking an easy starting point, and narrowing focus. That’s most of what we do. The trick here is, as you work the problem, pretend you don’t have an S.O.S. button. Get stuck on a complex algorithm manipulating several data sets, a fancy regular expression, or implementing a new npm package you’ve never used before? Google. Browse StackOverflow. Read the docs. Read the docs again, but for real this time.

Even if you copy and paste code from elsewhere and it works, take the extra 15 minutes to attempt to understand why. You might not get it right away. That’s fine. Push the commit and move on. Do the same thing the next time, and the next, and at some point, it’ll click.

Ask questions when you need to, of course, and raise your hand if you’re truly stuck. Don’t needlessly waste days on a problem. The point is to make a good-faith effort at finding the answers yourself before asking externally.

Failure is an opportunity and should be encouraged rather than punished

I closed the very first pull request I ever created. It had a formatting typo that, in retrospect, didn’t matter, but at the time I was worried would crash the entire Internet and set my company headquarters on fire. My engineering lead immediately messaged me on Slack asking why. I panicked; my first day in a new career, and already I’d screwed up.

Her response? She laughed about how she’d closed PRs herself dozens of times, informed me of the correct process going forward, and left me feeling empowered rather than scolded.

It wasn’t my last mistake. During my initial forays into date/time formatting mentioned above, I misunderstood ISO strings so completely that I wrote an algorithm that lopped off the ends with a .slice() (tip: do not do this) and accidentally forced every user into the timezone for Paris, France. When I began migrating our codebase from Material-UI v4 to v5, I had to delete a feature branch with three days of work because of an erroneous assumption that resulted in a dead end.

Every single mistake led directly to some of my biggest wins. The Material-UI snafu taught me the importance of thinking through and sketching out large projects before letting your fingers touch the keyboard. I studied date/time so intensely after opening the accidental portal to Europe that, a few months later, I replaced sections of our outdated Moment.js implementation with hand-written functions.

Seek out environments where taking the occasional risk is encouraged. It makes tackling bigger, skill-stretching tasks far less intimidating.

Learn a handful of tools really well, and a boatload of tools only a little bit

Someone once told me the difference between junior, mid-level and senior developers is that a junior doesn’t think they know anything, a mid thinks they know everything, and a senior knows exactly how much they do and do not know.

Real developers simply sit down in front of their wall-sized curved monitor, launch Vim, and start writing the next tech unicorn from scratch, right? Nothing could be further from the truth.

No matter how experienced, a huge portion of a developer’s job is looking up docs or code examples or popping a variable into a console.log() for the 10,000th time to decipher what’s happening. The most common phrase uttered out of an engineer’s mouth on a given workday is probably, “What?? Why???”

Get really good at learning. Follow patterns and utilize all of your problem-solving muscles; for example, if you’re given a task and don’t know where to start, search your codebase for anything similar and deconstruct how it was accomplished.

Hone your ability to absorb information rapidly, understanding you might forget it by next week. That’s OK—those docs will always be there to use again. That’s their whole raison d’être. You’ll internalize the knowledge eventually, but don’t beat yourself up if you don’t memorize all the props and functions included with react-router the first time you import it.

That said, pick a tool or a niche—it can be a gap in your current team’s skillset, or just something you’re interested in—and strive to become an expert. My personal choice was TypeScript, with the tangential goal of improving my understanding of vanilla JavaScript. Whenever I have extra time for self study or the opportunity to try something new in a ticket, that’s where I’m focusing my efforts. This foundational knowledge, in turn, has decreased the time it takes to learn new concepts.

In Conclusion

All of the above are stretch goals. Plenty of days or weeks will pass where you’ll only have the bandwidth to accomplish your assignments and nothing more.

As the senior engineers on my team often remind me, “It’s just software.” The world’s not going to end if a feature is delayed by a few days or you get stuck and have to ask for help. Breathe. Relax. Often, the breakthroughs happen after taking a walk, playing video games, working on a puzzle or otherwise disengaging for a few minutes. Be kind to yourself.

And, don’t forget—you’ve already wedged your foot in the door as a junior developer. The hard part’s over. Enjoy the ride!