Working with Junior Developers

Author’s Note: In lieu of writing more involved technical articles, I’ve decided to write this brain-dump article talking about my thoughts on junior developers. My current official capacity is Principal Developer, i.e. a senior-level developer, but I work in manager, tech lead / scrum master, mentor, and teacher roles as well. The ideas here are my own, and I still think I have plenty to learn when it comes to working with junior devs and others in general.

The purpose of this article is give my thoughts, and hopefully some wisdom about how to work with junior developers in any capacity — as another junior developer, a senior developer, a non-technical manager, and more. In the past, I considered myself a junior developer. Junior developers can be any age and from any walk of life. This article is mostly for senior developers such as myself, but also for junior developers and the general public.

What is a Junior Developer?

The term “junior developer” has been popping up a lot on my Twitter lately, but it’s always been around. Its definition varies from company to company, organization to organization, and there is certainly no concrete definition for what a junior developer is. It isn’t always a badge that someone wears. As career shorthand — and seemingly as understood by the community — developers as individual contributors are broken into senior and junior levels. A junior developer is one who works under the guidance of people with more experience. There are conceptually and practically many other levels of developer, but I’ll only talk about junior and senior specifically in this article: a junior developer is one who is not senior … yet.

A junior developer would be one ready to work in a professional setting. They can:

  • Demonstrate basic job skills, i.e. showing up on time, following guidelines and procedures, etc.
  • Make minimal contributions to software projects without guidance.
  • Collaborate with others at varying levels and make more complex contributions with guidance.
  • Build, test, and deploy projects by following instructions, effectively with guidance.
  • Contribute to documentation with guidance.
  • Demonstrate competency in a platform — probably the platform they have been hired for.

Junior devs will have many more skills and talents beyond the ones I have just listed. This is purely a baseline that all junior developers should be able to achieve. Junior developers should also be readily contributing to the software development community/ecosystem they work in professionally and personally.

As for senior developers, there are some skills that they should have that will set them apart from developers at a junior level. These are not necessarily platform specific. They are more general developer skills. All developers should continue to work to master these in addition to mastering their chosen platforms. Junior developers may possess some of these skills, but I don’t think a developer should be considered senior until they can exhibit competency in all of these skills:

  • Make intelligent decisions about technology stacks and libraries used to build projects.
  • Set up testable, deployable, documented projects from scratch that other developers of any level can begin contributing to immediately.
  • Help solve the most difficult problems a project faces.
  • Code review effectively.
  • Be a model for project contributions in terms of code, documentation, and version control quality.
  • Mentor and empower junior developers not just in the project or platform, but also in general hard and soft skills, communication between and among departments, and maybe even life.
  • Understand and respect all roles — technical and non-technical — involved in a project.
  • Perform all of the junior developer skills (noted above) autonomously, i.e. without guidance.
  • Make important meta contributions, i.e. enhancements to software or process that can be employed effectively to many parts of a project or even to other projects.

Senior developers, like junior developers, are unique, and they all possess their own skills and talents that allow for unique contributions. The list above is as minimal as I can make it. My hope is that all developers who consider themselves junior have all of the skills in the first section, and all devs who consider themselves senior have all of the skills in the second section.

If I missed something, I would love to hear feedback about that. If you feel you don’t possess a skill for a particular section but consider yourself to be at that level, I’d be interested to hear your thoughts too.

Understanding Junior Developers

Any professional developer is — or was — a junior developer. Maybe being a junior developer is a mentality: you think you are junior until you have the confidence to think of yourself as more than a junior. That comes on its own with time.

Personally, I have never met a junior who had any resentment towards being considered a “junior.” On the contrary, this seems like a point of pride for some people. I’ve known quite a few people who have happily introduced themselves as “junior developer” in social situations and include it as their role on social profiles. This may particularly be the case of developers who have just started jobs that they’re excited about. Perhaps a junior developer has unlimited potential, and their talent will grow meteorically. This is something everyone can get excited about. In the same vein, I don’t think that a “junior developer” is something to be disrespected in any way. It’s just become a shorthand for identifying a class of developer.

Junior developers usually possess a subset of the following traits:

  • A desire to learn as much as they can.
  • A desire to contribute meaningfully to projects that sometimes mirrors a fear of not being able to make meaningful contributions.
  • A general sense of optimism, and a specific optimism about development.
  • An immediate fascination or even obsession with the work they’re doing. Watch out for this one.
  • A fear of asking too many questions, or not being knowledgeable enough. This is particularly poignant because there is no track record they have to reassure themselves with. This is one to watch out for as well.

Working with Junior Developers

Understanding the mentality of junior developers should help you work with them. There are tenets to working with junior developers depending upon your capacity.

As a junior developer

I originally wanted to write this section as how to work with junior developers as a junior developer, but it metamorphosed into how to be an effective junior developer too.

  • Be open minded to, but skeptical of, contributions of other developers — both junior and senior.
  • Challenge other developers with the goal of you both improving.
  • Do not undermine anyone. Your abilities will be recognized and celebrated for their own merits, and if you throw other devs under the bus that will get noticed too.
  • Admit to your own mistakes. Do what you can to cover others’ mistakes.
  • Don’t mock or censure others unless you are close enough to do so genially. If you feel negatively about something another person has done, give them the benefit of the doubt, but speak to someone more senior to clarify the situation.
  • Don’t be afraid to ask questions. One of my favorite wise tidbits is:
He who asks is a fool for five minutes. He who does not ask remains a fool forever.
  • At the same time, make sure that you have tried several options before seeking help. Make sure you have a question, and learn how to ask a question. The advice from Stackoverflow can be applied to question asking in general.
  • Take an interest in what other developers are doing both in the project and in their lives.
  • Time box your issues. Commit to work on something for a period of time — an hour, 30 minutes… Once you are stuck for that amount of time, ask for help.
  • Consider your contributions to be as valid as any senior’s.
  • Remember that senior developers can and will make mistakes. Do what you can to help catch and prevent their mistakes — especially if they entrust you to something that they have done, perhaps via code review.
  • Focus on improving yourself, but be aware of how you can improve the team.
  • Respect everyone.

As a senior developer

You will probably have one or more junior developers working on a project with you. There may be other senior developers on the project — perhaps some more senior than you, but this section will generally include tenets for working with those more junior than you.

  • Be open and available to provide help and clarity. If you need to be heads-down, make this clear ahead of time. I need to focus on this issue from 1–3pm, but I will be available after that.
  • Remember where you came from. How would I like to be treated if I had asked that question?
  • You don’t know everything. Junior developers might know more about something than you do. Be ready to accept that and learn from it. In fact, you should happily admit when you have learned something new. Junior devs and others will respond positively to that acknowledgment.
  • Be transparent about everything you do. Don’t change things without a strong explanation, and make sure developers know what’s going on.
  • Explain your reasoning behind every decision you make. If someone questions a choice you have made and you can’t defend it intelligently, you should rethink it.
  • Recognize accomplishments from everyone and point out what others can learn. As Charles Schwab said,
I am hearty in my approbation and lavish in my praise.
  • Delegate, but don’t shy away from annoying problems. Don’t give a junior dev something to do because you don’t want to do it. Make sure they have a baseline to work with when they approach an issue, and keep the mentality that you may have to solve this issue alone.
  • Foster competition, but elevate everyone. Don’t create artificial competition where it is not needed, but try to create incentives for achieving goals.
  • Question everything, but criticize nothing. Offer alternatives for solving problems alongside your explanation for their superiority. When guiding others, remember the words of Alexander Pope that Benjamin Franklin quoted in his autobiography:
Men must be taught as if you taught them not, and things unknown proposed as things forgot.
  • Focus on creating a gestalt team. You don’t need to focus on yourself anymore.
  • Respect Everyone.

Being a senior developer can be a lot of pressure at times. It is a prestigious title to have, but there may be many hungry eyes looking to you for guidance or to impart knowledge. The gluttonous ones may even be saying, “I can do better than they can.” Remember the point that I’ve stated throughout this article: developers are unique and possess unique talents and abilities. You will see and learn something new from every junior developer you work with. Your growth will now come more through your experiences working with others versus the personal improvement you strived for at a more junior level.

I think that imposter syndrome is very common in the software development field. After all, we are all imposters… but at the same time we all have transcendent talent. Software developers should be able to use the same tools and solve the same problems. The difference might be the amount of time it takes someone to do something, or how effectively it is done. Senior developers might have a broader view into the maze of software development, but this doesn’t mean that juniors can’t notice details that they miss.

I have worked in a toxic software development environment before. This environment focused on metrics and individual results as indicators of performance. Since leaving that, I have personally tried to foster an ergonomic environment when I can. I avoid criticism and punishment. I try to make everyone feel positive about what they have contributed. If I have an alternative solution to a problem, I try to make a strong argument for it. If someone is not producing what the team needs them to produce, I work to fix this from the perspective of the team to the benefit of the individual. I recognize that everyone makes mistakes, and just because you are senior doesn’t mean you will make fewer mistakes.

In fact, the gravity of a senior’s mistakes becomes larger the more senior they become. If you are a senior, you should discover tactics to catch your mistakes and expose them readily so they can be addressed before they do damage. Be ready to address this personally. If a junior dev doesn’t catch a mistake you made you still need to take responsibility for it.

As a non-technical manager

I have no experience working with developers from a non-technical perspective, so I don’t have a lot of advice to offer here. I can only come up with one more tenet:

  • Respect everyone.

Ideally, everyone on the team wants to produce the best outcome for the project and wants everyone working on the project to achieve as much as possible. This isn’t a zero-sum game. While there may be competitions and strong performers, the project should be a positive experience for everyone. Everyone should be engaged and feel like they are making contributions. It can be easy to get caught up in the drudgery of the project and neglect the personal needs of its contributors.

As a once… perhaps currently… undeservedly arrogant developer, I can also say that some junior developers can fall into a trap of disrespecting more senior workers — especially those that are non-technical. It’s not your duty to prove your usefulness junior devs, but at the same time it’s important to remain humble about your purpose. Continually ask yourself how you are contributing to the project, what more you can add, and what you can do differently. Ask for feedback from technical contributors. Be ready to offer feedback to them as well, but try to understand their perspective. We’re all people even if developers occasionally seem like robots or cogs or something.

Conclusion

Working with junior devs has been a very positive experience for me. I have had the opportunity to work with dozens of junior developers in some capacity, and I can’t say I have had a negative experience. There have been some failures to achieve goals, and I take responsibility for almost all of these. I still don’t know what I’m doing, and I’m figuring it out as I’m going along. I hope that all of the devs I’ve gotten to work with have the same positive feelings that I do, and forgive me for what I perceive to be my glaring flaws.

There are a couple of particular items I noted to watch out for when working with junior developers:

  • An immediate fascination or even obsession with the work they’re doing.
  • A fear of asking too many questions, or not being knowledgeable enough.

The first point is not necessarily a bad thing, but I have noticed that some junior developers will work a lot harder than they have to. I have personally been guilty of this: I’ve gotten so excited about the work I was doing I was working up to 40 hours a week off the clock so I could play around with the software I was working on. In and of itself this isn’t bad, but seniors should keep an eye out for burnout and should provide opportunities for variety in things to work on and new skills to learn. As developers, we automatically think that spending more and more time on development results in constant growth. After all, Franz Listz supposedly practiced piano up to 14 hours a day, so immersing ourselves in development isn’t always bad, right? To be honest, I don’t know. All I can say is that some junior developers may go through this phase, so just be aware, watch for burnout, and try to channel that creative energy into something great.

If you’re another junior developer who doesn’t feel this intense motivation to develop while others around you are doing so, don’t worry. I hope that all developers feel a passion and continuous growth in what they are doing, but you can certainly have other completely different passions in your life that you want to focus on. Just make sure that you are making meaningful contributions professionally. If you’re not sure, ask! Above all, your personal health and wellness comes first.

If you’re a senior dev, be prepared to help junior devs as much as possible. Some will ask too many questions, and others won’t ask enough questions. You may get a lot of x-y questions, and you should be able to recognize and redirect these. Give the opportunity for junior developers to arrive at solutions themselves, and give them credit for solutions that might be different than the one you had in mind — especially ones that are superior to the ones you had in mind. Stay aware and stay humble. Focus on creating a gestalt team rather than focusing on yourself.

Junior developers cannot be treated en masse. They are all individual people, and part of the joy of working with them is seeing how they grow as individuals. All of the advice I’ve given in this article is merely a baseline for working with other devs. I’d be interested to revisit this in another, one, five, ten, or more years and see how I can improve upon it.