This post focuses on what a junior developer should do when starting a job to ensure their success in a position. My sister is finishing a coding Bootcamp, and this is the advice I intend to pass on to her. The truth is, she doesn’t need most of it because she has professional experience before coming to coding. But this is advice I would give to anyone starting any position, at any level. The only difference is that you spend more time in the “getting up to speed” phase as a junior vs. more senior developer.

This is based on my experiences watching people start and succeed, start and fail, and everything in between while working at Canvas and then Amazon robotics. Success isn’t just about individual contributions or the ability to get up to speed quickly. It’s about building an environment where you can continue to nurture and grow. This means if you are successful, you should end up with advocates, mentors, and coaches. The general theme is respect for what came before, a sincere desire to add value, and consistent effort.

  • Make positive contributions wherever you can by adding value in the margins. Ideally, you would do this until you run out of time outside of projects or have automated those tasks away. One simple example, update documentation. If you are using a document to onboard and improve that document, this sends a clear indication to your team that you care about the little things. Making life easier for future developers by helping them avoid pitfalls or clarifying confusing points is vital to team success. While it may seem frivolous, you are making the people who created that documentation happy at the very least.
  • Write down a list of questions and bring those questions in batches instead of single on-offs. What you find is that as you write down all your questions on a subject, you start to fill the gaps. You will begin to ask better and better questions, which leads to better and better answers. Equally important, you show whoever’s job it is to answer your questions you respect their time. Writing down the answers gives you a reference, so you can avoid asking the same questions again.
  • Do not be critical of existing code, even if it warrants criticism. Even if the conventions, linter rules, and norms in the codebase are awful and easily improved, take your time. People can have their ego tied to code. They can feel it’s “their” lego set. Earn trust, know where to tread lightly, learn which parts of the code are ripe for ownership, and start there. If you know something which can make improvements in key metrics early, bring it to the team before you take the issue to a manager.
  • Avoid overpromising. It is tempting to tell product managers what you think you can do, or even what you KNOW you can do. Still, it is better to take a humble learning-oriented approach when talking to people early. They don’t expect anything of you except a beginner’s mindset. You don’t know what has been tried or the reason it failed. Things are usually more complicated than they appear, but sometimes they aren’t or shouldn’t be.
  • Learn to compartmentalize. At some point, you have to dive into a codebase that is foreign to you. The language itself may even be unfamiliar to you. Find your area of concern and narrow your focus as tight as possible to solve your problem. What I struggled with as a curious young developer is where to draw the line for that curiosity. Attempting to fix a bug would take me down a rabbit hole. I would change too much code in too many files, which I really didn’t understand in the first place. Tasks given to juniors initially tend to be straight forward. The ability to segment problems, write tests around the cases for a specific issue, and keep changes scoped to several files is an important skill to learn. It makes code bases more maintainable, changes easier to review, builds trust with your peers, and shows respect for what you don’t know.
  • Find or ask for an example of what you are trying to do. Nobody is going to be asking you to re-invent the wheel as a junior developer—quite the opposite. Even if you have solved a problem previously, maintaining patterns in the codebase you are working on is essential. I have seen developers who always write code how they would write it for a side project, rather than how the team has written it. Then those same developers would stand up and defend why in execution its the same or why it’s more readable. They might even be right. But what is the objective as it relates to the entire codebase, which the whole team supports? Make your work easy to follow and merge until you gain the trust to make more extensive changes. This means conforming your coding to their conventions, down to the little details.
  • Make it clear that you are there to help, even if you may lack the know-how. If you are low on work in the first couple weeks, speak up in a team meeting and volunteer those extra couple hours to take a chore off a team-members plate. Best case, there is something you can do to help them. Maybe you end up looking over their shoulder and watching, so next time, you are ready. Or perhaps they say no, but will appreciate and remember the sentiment.
  • Set whatever boundaries you feel comfortable with between work life and personal life from the getgo. Are you comfortable answering emails on a Saturday night? Great, then go for it. If not, find a way to show your dedication that fits your schedule. If your weekends are sacred, wake up early on Monday morning and spend the time getting up to speed. If weekdays you spend time with your family after five, draw that line and don’t look back. There are many hours in the day and many ways to show you are committed; find yours. You can always bend these things later, but the precedent set in the early weeks defines the expectations people have of you.
  • Be a positive person when possible. This one took me a long time to learn. I value honesty, transparency, and straightforwardness, but that doesn’t mean that everyone else does. My attempts to be straightforward were being received as cynical, overly blunt, or not helpful. I also learned that it is sometimes better to move forward with the wrong solution than to die on a hill with the right one. Be honest with people about limitations and concerns as you see them, but present an upbeat can-do version of yourself whenever possible. Bring problems with solutions instead of just problems.
  • Collect responsibility, don’t wait for it to be assigned to you. As you help people with tasks or start to catch the flow of how you can add value, don’t wait for someone to tell you to do something. Over time, your responsibility grows and grows in scope and importance. By taking on the concern for an area, or even showing you are another person concerned about an issue, you are alleviating others’ burdens. The hardest part is moving on from any chores you took ownership of early on, as the job you were hired to do starts to take shape. You have to look to automate problems away or hope there is a steady stream of juniors developers.

As I get feedback or have any more thoughts or examples, I will expand on this list. Please send me feedback through the links at the bottom of the page. I would love to hear what you think.