Landing your first job as a developer is an exciting moment.
Whether you’re coming from college, a boot camp, or teaching yourself, the job offer may feel like the moment you’ve been waiting for — proof that the time and effort you put into learning to program has paid off.
However, learning to code and working as a developer are slightly different things — you have a company to write code for, co-workers to collaborate with who have more and/or different experience than your own, and new tools to grow accustomed to.
I was excited for my first day on the job, but also fought back feelings of intimidation, uncertainty, and isolation. Here are some strategies Planet Argon implemented to help me grow into being a Junior Developer on their team.
A huge element of my onboarding process was building confidence by shattering my imposter syndrome fears. During my first month, I often asked myself:
- Am I going to be able to do this job?
- What if I break everything?
Confidence as a junior developer comes in two ways: feeling trusted enough to perform tasks independently, and having a comfortable environment to ask questions and work with other developers. Including a balance of activities in your onboarding schedule will help your new junior developer feel comfortable in their role a lot faster.
Planet Argon’s first-week plan includes DevOps time for junior developers to set up their machine and get familiar with our client projects and shadowing time with more senior developers to support our new team members in both ways.
A junior developer’s first week at Planet Argon includes meetings with leadership and project managers. It’s a time to share company values and the day-to-day process of how we get things done.
Help your new hires avoid the feeling of, “I’m not sure what I’m supposed to be doing,” by dedicating time to let them know what success looks like during their onboarding period.
Contributing to a codebase can be scary for the uninitiated. As confident as your junior developer may have become in their at-home development environment, working on someone else’s code, for money, can be a big intimidation factor.
Share high-level goals and milestones with them, as well as detailed procedures for writing commits and responding to JIRA tickets. A concrete example from my onboarding schedule included incrementally decreasing the amount of time spent on “absorbed development”. This is a term we use for non-coding related time spent learning how to make the required changes. It’s time we “absorb” because we don’t bill clients for it.
I also appreciated learning about Planet Argon’s “no surprises” rule. When things get overwhelming or off-track, tell someone. We don’t want to surprise our clients or our teammates.
Overall, remind your junior developer that they were brought into the team with the knowledge that other developers would spend time with them to get them up to speed. This company was interested in investing in you, junior developer, and we want you here.
No matter how many times coworkers said, “feel free to ask me any questions you have,” (which does help), I didn’t comfortably take advantage of it until I spent some time getting to know them. After shadowing, I also went back to my personal tasks with new skills to apply, and more comfort when I ran into an issue that I couldn’t solve.
Be patient and make time to plan the tricks of the trade. Reflect on what you wish you would have known when you get started. Keyboard shortcuts, customizing oh my zsh, and discussing version control stunned me at first, as I watched other developers glide through the command line. Using the shortcuts at my workstation felt a bit like practicing scales on the piano, but now I’m getting the hang of playing small concertos.
After watching how it’s done and getting more familiar with your company’s tools, have a manageably-sized ticket ready for them to work on. It’s a great introduction to how your task management system works and it will feel great for them to finish something and mark it “done”.
A common todo to find at the bottom of many lists is to update documentation. As a new hire, this documentation can be crucial — it’s your map to understanding the company and what you should be doing. Be aware of what’s included. Be confident that what you’re giving them is helpful.
Review and update the materials you’ll give your junior dev before handing it off to them. No longer relevant setup guides may stop them up. You wouldn’t want someone to give you a ReadMe that wasn’t accurate, don’t do the same for your juniors.
In addition, ask your junior devs to contribute to your company materials to help the next person who comes along. They’re the most recent ones to touch the documents, they probably know what’s missing and outdated. Giving them this opportunity to contribute provides a chance to reflect on the giant learning curve they’ve embarked on.
Habits form quickly — what felt terrifying and new should (hopefully) become second nature relatively quickly. If you don’t leave notes for the next developer as the onboarding process occurs, chances are the junior dev will assimilate them (just as they assimilate into your team), and forget what stopped them up by the next time a new hire comes around.
Onboarding junior developers and being a junior developer acclimating to a new role are both huge and delicate responsibilities. Combat intimidation with knowledge and support. Quash uncertainty by providing specific instructions. Remind your junior developer that you trust them and that you’re excited to have them on your team.