Three Things Successful Junior Developers Do
This article is for anyone preparing to enter the software development workforce as a junior developer, or for anyone who has recently landed their first job as a junior developer. This article is based on this idea
A team doesn’t need its junior developers to be great developers — but it really does need them to be great team members.
These are observations from my own experience as a coder and a manager of coders on how to be a great team member right out of the gate. These ideas aren’t backed up by studies and they have only been vetted by a few friends — so if you have feedback or a different opinion, I’d love to hear from you in the comments section, below.
In my opinion there are three big things that you can do as a new junior developer to immediately make meaningful contributions to your team, connect to your teammates, and to begin the process towards becoming an experienced developer. There are two skills to focus on, and a mindset.
The skills are:
• Master your team’s source control process
• Master your team’s SDLC (software development lifecycle) process
*In my opinion, these two skills are the basic foundation of a professional-grade software developer. Add effective time management, technical competency, and communication skills and you’re a super star.
The mindset is: Be real about what you do and don’t know, and ask for help a lot. This is actually a great mindset to continue for your entire career, btw.
Some Groundwork on Being a Junior Developer
As a junior developer, everyone understands that you are just starting and they don’t expect you to know a lot. The primary concern for your new team will probably not be to determine your level of competency, but to figure out how much extra work they are going to have to do to fix your mistakes as you learn. And your team should expect to spend time fixing your mistakes — software development is complex and difficult.
For at least the first few months, your team will not expect you to contribute much code. However, they will be expecting you to cause some problems as you learn source control and SDLC, and they will quarantine you as best as they can until you are solid with these practices.
The faster you master these two things, the faster you will become professionally valuable to your team, the faster you will make connections within your team, and the sooner you will be given more interesting work. Being real about your level of skill and experience during this time will help your teammates build trust in you, as well as get to know you. Software teams are usually great communities where transparency, communication, and authenticity are highly valued. Just be yourself — everything else can be learned.
Skill 1: Master source control
Source control is how you will keep your changes in synch with the rest of the team. In my opinion, mastering this is the most important thing you can do for yourself and for your team. You have to master source control in order to do anything else. And nobody is going to invest much time in teaching you more until you pass this threshold.
Why does this matter so much?
This is about taking care of your team. Messing up source control when you’re new to it is expected and understood, and you don’t need to feel bad about it. Really. Having said that, consider the process for your teammate — they have their head in something complex, and then have to somehow stash all that information in their brains so they can come back to it later. Then they come say hi to you, and dig into a source control problem, which can be remarkably complex in its own right. Once they get you straightened out, they have to get their heads back into the complexity of the problem they were working on.
It says a lot about the overall community of software developers that this process usually occurs with genuine good will. Again, you don’t need to feel bad about messing up source control as a junior dev. It is TOTALLY okay. Everyone on your team was once a junior, and everyone has done it and needed someone else’s help.
So it’s okay to mess up source control, and everyone understands — but this is an area where you can make big strides in helping out your team. You may not be able to squash bugs or write features very fast, yet, but the faster you grasp source control, the faster other team members aren’t being pulled off of their work to help you. And that is a big deal. You team will appreciate your effort more than you may be able to imagine - until someday you’re the one helping someone else out. It’s basically saying, “I value your time, and am willing to work hard to level up to contribute where I can.”
By the way, there are a few Git UIs available — when I say ‘master’ source control, I mean master it on the command line.
There are great resources online for learning Git, and I strongly recommend learning as much as you can before you start your first job. I’m including a few links to help you get started, but you can easily find more information and even some online courses. This is often a good topic for job interviews, even if you haven’t mastered it yet. Just sharing that you are learning Git, and you’re working on getting your head around some particular part of how it all works, tends to be a great conversation.
How to use Git — Git Video Tutorial — Part 1 (add, commit, push, pull, status)
Git and GitHub Tutorial for Beginners #1 — Why Use Git
Git -The Simple Guide
A Little More
Another way you can respect your teammates’ time is when someone is fixing your source control issue, stay with them and take notes. Ask questions and learn as much as you can.
This is what makes you a member of a team — not how good you are, but how much you value your team members and how willing you are to level up where you can. It will be appreciated and reciprocated. For me, that’s the main thing I look for in a potential junior dev hire. Everything else can be learned.
Once you join a team, I also recommend asking your team all the questions you need to ask until you totally understand how they use source control. Most teams have a source control process, but your team may not have it written down anywhere. Or it may be written down but be incomplete or out of date. It will be a huge service to your team to write down the all the steps when it is explained to you. Any team will love you for this.
Software developers tend to love sharing knowledge, and once a junior developer masters source control, I notice the more experienced developers investing more in their growth. Mastering source control signals that you take the profession, the team, and yourself seriously, and are ready to take on more responsibility.
Skill 2: Master your team’s SDLC process
SDLC stands for Software Development Lifecycle, and is the basis of how work is defined, executed, tested, and delivered. Like mastering source control, mastering the SDLC process is foundational to being a professional software developer, and to being able to work as a member of a team. You should give yourself a few weeks to really internalize your team’s process — but during those weeks you should work hard to master it. Like mastering source control, taking responsibility for working according to the process that everyone else is following shows respect for your teammates’ time and energy. And it tells them you are able to work at a professional level.
Your team will (or should) have a process for how they define and estimate stories, how they commit and accept code to the codebase, and how a story is tested and marked as completed. Your team might have this process documented, and the documentation might be clear and up to date. Or, the process might not be documented at all. If you aren’t given full documentation to refer to, write it down as it is being told to you. It may sound simple when you hear the process, but it can be surprisingly difficult to internalize a team’s process. And for the team to work at it’s best, everyone needs to be working in the same way.
An Important Sidebar
When you join a team, you will probably be given an account for your team’s process management app — JIRA and Rally are common options. Through this you will be assigned units of work, generally called user stories (or just stories).
It’s very important to understand that sometimes the stories will be well written and contain all the information you need, but sometimes they won’t. If you aren’t clear on what the end result of the work should be, it is your responsibility to ask until you are. It may have been someone else’s responsibility to write a clear user story, but we are all responsible for everything, together.
It can feel uncomfortable to ask for clarity on a story when you’re new. However, the time taken to get clarity on a story is a fraction of the time taken to redo a story. And rework typically means that the business isn’t making money on the completed work.
It’s an easy mistake to make, especially as a junior dev. And, again, it’s okay — these kinds of mistakes are part of being junior. Mistakes are always okay, and everyone on your team will make mistakes. When you make a mistake, just take a moment and write a note to yourself about what happened, how it happened, and what you’re going to change to prevent it from happening in the future. Being clear on what you are being asked to do before you get started is as important as your ability to do the work. And as a junior dev, on your very first day of work, this is something you can do to contribute meaningfully to your team.
Mindset: Be real about what you do and don’t know, and ask for help
As a new developer, I once spent three weeks on a project that I could have completed in three or four days, if I had just asked for help. I was smart and talented, but I let my ego and my fear of being seen as not good enough prevent me from just asking my team for help. Instead, I put my head down and tried to grind it out. I eventually did figure out my problem, but by then I had cost the company way more than the feature was going to pay back. As it happened, there was a round of layoffs a few weeks later, and I was included.
What you know and don’t know really isn’t very important, as a junior dev. But, clarity and honesty are priceless in software development, and those are important things you can bring to the table immediately.
If you don’t know how to do something that you are asked to do, just say so and ask for help. A team doesn’t need its junior developers to be great developers — but it really does need them to be great team members. You will learn fast if you are real about what you know and don’t know. You will learn slowly if you pretend you know things you don’t, and you will spend many hours spinning your wheels, instead of learning and contributing.
Depending on where you get hired, the more experienced developers may or may not have much time to review your code. Either way, get as many code reviews as you can. Anytime you finish a piece of work, for at least the first three months, ask if anyone is available to quickly go over it with you. You will learn a lot from this process, and you will gain respect for not having an ego about your code. You will also make connections with your teammates and get to know them. And I can’t overstate how valuable that will be for your ability to grow and contribute.
These are the three biggest things I’ve observed that very successful junior developers do right.
- Master source control: This levels you up from total beginner to professional beginner, and lets your team know you consider their time valuable.
- Master your teams SDLC process: Many junior developers don’t know what the SDLC is — separate yourself from the crowd and let prospective employers know that you are ready to write code in a professional environment.
- Be real: You’re junior, you’re just starting. You don’t need to prove yourself, just learn as much as you can, ask for help, and write down what you learn from your co-workers when they help you.
I hope this article helps you be phenomenally successful as you begin your career. Please leave any feedback or suggestions on how to make this post more useful in the comments.