9 Ways to Make the Most of Your First Few Months as a Junior Developer

Bits of advice from one new programmer to another

Like many new things, my first day as a junior web developer can be described as a mixture of excitement and abject terror. Fresh out of the twelve-week web development immersive program at the Flatiron School, I knew that I’d received a top-notch crash course in programming and that I was technically fully equipped with the necessary skills to succeed in a programming job. I was confident that I could learn quickly and build beautiful, functioning web apps with Ruby and JavaScript. And I was beyond stoked about landing an awesome job as an apprentice developer on the Flatiron School’s Labs Team. But still, I wondered if that would be enough. Imposter Syndrome struck. I panicked.

Four months later, I’ve just shipped my first big solo feature (strangely enough, ahead of schedule), so I can tell you that a) it gets better and b) there are a number of things you can do to totally crush it at your first programming job after graduating from a coding school. With the help of my managers, team members, and former classmates, I’ve compiled some tips for conquering a new codebase, settling in, and figuring out what it means to be a professional coder. Try ’em all, especially if they make you slightly uncomfortable because in reality, that’s how you’ll grow and learn the most.

  1. Read every code-related thing you can get your hands on. Books, blogs, news, documentation, source code — read it all and absorb as much as possible. You may not understand all of it the first time around, and that’s okay. You’re a beginner, and as you get used to your new career, you’ll be able to flip back, review it, and parse more. What you need now is a foundation or framework for understanding. For Rubyists, I recommend starting with Practical Object Oriented Design in Ruby by Sandi Metz as well as Design Patterns in Ruby by Russ Olsen. They’re both foundational texts that’ll help you not only get the hang of writing quality software but also aid you in deciphering the code that the rest of your teammates have written.
Getting buy one get one free sundaes with the team!

2. Be social. Get to know your team. Don’t eat alone, and ask people to grab coffee (or ice cream!). I’m a naturally introverted person, so this was especially hard for me to do. If you’re the same way, push yourself to do it anyway because by forming strong relationships with your team, you make it so much easier to work together. By breaking the ice and discovering more about your co-workers, you’ll humanize them and make them all seem way less intimidating, which is important for when you need to ask questions (and you should ask a ton — see #3). Similarly, attend professional conferences or meet-ups and maintain a strong support network — whether that’s your team, your former classmates, or your family, you’ll need some backup because changing careers, let alone learning how to program, is hard.

3. Ask a ton of questions (like, actually, a ton). It’s more than acceptable not to know everything, and not knowing everything doesn’t make you stupid. This took me way longer to believe than I’m willing to admit. When you’re approaching a massive codebase for the first time, a codebase potentially filled with legacy code and bugs, of course you’re not going to understand it immediately. Do yourself a favor and ask questions upfront. I wouldn’t ask the same ones over and over again, but do your best to poke around and ask when necessary. Spread your questions among different teammates too if that helps. Just because something is in the codebase doesn’t mean it’s right. So again, be sure to ask if something seems confusing or strange. Plus, a lot of more senior devs (well, at least the ones on my team — you all rock) will patiently explain something with expertise and kindness. (In many cases, them being able to answer your questions also stokes their egos and builds their confidence, so win-win!)

4. Have high expectations, but also forgive yourself if you fail. Set reasonably high goals for yourself. Maybe you’ll learn how the Iterator pattern works by Friday. Or you’ll aim to close a bug by end of next week. Then try as hard as possible to meet that goal, even if it means putting in extra time outside of normal work hours. Take breaks when necessary, of course, and don’t burn out, but in my opinion, it’s ideal if you can extend the bootcamp mentality for as long as possible because investing time now (when you’re super pumped about programming!) will pay off later. I view your first few months on the job after programming school as a critical period, when you’re just trying to cram in as much as possible about how a language works. Also, you may not reach your goal, and again, that’s okay. As Sandi Metz writes in Practical Object Oriented Design in Ruby, “Perfection is elusive, perhaps even unreachable; this should not impede your desire to achieve it.” Just accept it, move on, and keep challenging yourself. As corny as the whole “shoot for the moon” concept is, it’s true. You’ll land in the stars, and that’s not a terrible place to be.

5. Find meaningful ways to contribute to the team. Whether that’s writing unit tests or organizing social activities, figure out a way to add value. I’m personally very pro test because it’s an important skill to have and having a robust test suite will often help you refactor your code down the line. Writing tests also helps you get a couple lines of code into the app without breaking everything, so you can get accustomed to the deployment process and the team’s workflow. (To be honest, I broke a couple things in my first few months; that’s cool too as long as you learn from your mistakes.) But I digress; find a way to contribute because it’ll make you feel like a valued member of the team and help you overcome any lingering symptoms of Impostor Syndrome.

6. Review others’ pull requests daily. This not only helps you get a sense of other team members’ programming styles, but also helps you understand the team’s workflow and how the codebase continues to evolve. Personally, I’ve observed different team members write with slightly different styles and naming conventions, so now, when debugging, I can better anticipate where each of them might have written a line or how they might have named a method. Also, with fresh eyes and perspective, you might even catch a bug or two. (Take the small wins when you can.)

7. Tackle bugs. Many of my teammates have done this with great success. They might not initially know how to solve an issue, but going through the process of tracing a bug to its source is a great way to learn how to solve problems and to get familiar with the rest of the codebase. My best advice is to try tackling a problem on your own first. If you get stuck, try pairing with a more senior member of your team. You can also try “shoulder surfing” or shadowing someone while they debug. Getting a sense of how to approach a problem will help when you tackle a related issue in the future.

8. Blog about what you learn. Blogging is an important component of both the immersive and online web development programs at the Flatiron School. Blogging helps you synthesize your thought process about a technical concept and figure out what gaps you may have in your understanding. But in addition to helping you clarify a concept, maintaining a blog allows you to keep a record of your progress so that you have tangible proof that you’re actually making progress. It helps sometimes, when you face a technical roadblock, to go back a few months in your blog archives and see how far you’ve come.

9. Ask for feedback. Not many people enjoy receiving feedback, but when it comes from the right people (i.e. people you trust and who care about you both as a person and teammate), it is extraordinarily helpful for your personal and professional development. So solicit code reviews as well as feedback from your team members. Constantly figure out if there’s a way to do something better. There’s likely always room for improvement when it comes to coding, deploying, team procedures, communication or otherwise. We thrive in an industry with fast feedback loops and constant iteration, so get used to asking for and giving feedback because it’ll make everything get better faster.

When you’re just starting out as a new programmer, it can be hard to keep Impostor Syndrome at bay. But think about it this way: when you’ve learned to code in only three months, imagine what you’ll be able to do in the next nine. The most comforting thing I came across is this single line Sandi Metz wrote in Practical Object Oriented Design in Ruby: You will never know less than you know right now.” She was talking about correctly grouping methods into classes, but I’ve applied it to my programming career in general. I repeat this mantra to myself almost daily, and now I’m pretty much convinced that as long as you keep working hard, you’ll be a truly awesome programmer in no time. Now go forth and learn, love, code.