As a senior engineer, it can be easy to forget that junior developers don’t have the context and knowledge you do. To avoid frustrations on both sides, it’s important to communicate effectively. Here are ways to ensure you’re being more considerate when communicating with junior team members.

As a senior developer, you have time and experience on your side. You’ve most likely worked at multiple companies and developed a sense of how things work and how best to solve problems, ask questions, and work effectively. It’s easy to forget what it’s like entering the workplace for the first time as a newly-minted junior developer.

With no prior professional experience, junior developers often have no or little knowledge of workplace expectations and the business context. Even when I started my current job as a senior developer, during the first month, I was surrounded by people talking about things I’d never heard of before and using a language I’d never developed in before. It was hard to know which parts of what I was hearing were important to know and remember, and this was all while I was trying to learn a new programming language as fast as I could. As a junior developer, you’re in the same position, except you have no experience to draw from and no existing projects to bolster your confidence.

Even though everyone was friendly at my first workplace, it was super intimidating just because it was my first job. To ensure your team and organisation feel welcoming to junior developers and sets them up to learn and grow, here’s what to consider when communicating with them.

Show junior developers they’re welcome and supported

When I was a junior starting in my first role as a developer, I had no idea what was expected of me or how to behave in an environment that was so dissimilar to what I was used to at university. My goals were to make a good impression and figure out what I could and couldn’t do. It was a whole new set of social interactions to learn.

To help developers who are new to the working world, it’s important to make them feel welcome and supported in an unfamiliar and intimidating space. A good place to start is to try to understand the concerns and motivations of the people you’re working with. This will help you communicate more effectively.

Junior developers are often learning a new programming language as well as how the company and professional relationships work. When I was a junior, I had to learn Python, but I also had to learn how to interact with colleagues across various business functions, how to protect my time, and who to ask for help with specific tasks. There’s a lot to learn that I forgot about once I’d been working for a few years. When I joined Stitch, I got to live through that process again when onboarding new junior developers.

A good way to show new developers that they’re welcome and supported is to ask them what their goals are, what they’re hoping to achieve in their role, and how they’re hoping to progress in their careers. You can immediately change the way you’re supporting someone if you give them the opportunity to tell you how they want to be supported.

Ultimately, your goal should be to provide the space for them to grow while providing them with support and resources to do so.

Celebrate the small wins

When you’re onboarding new developers, it’s often hard to recognise what they’ve done as impressive if it’s something you’re used to doing every day. For example, at Stitch, new joiners do their own integrations into our API as a way to learn how the system and product work. For someone new, being able to do that quickly is incredibly impressive. For a developer who’s just entered the working world and is still learning the ropes, doing something that may seem mundane to you can be a huge achievement!

Taking the time to recognise achievements like these can help the people you are onboarding to understand that they’re meeting expectations, feel appreciated, and feel like what they’re doing has value.

Make it clear you’re available for support

I’ve found that giving junior developers the space to solve their own problems is great. It’s also an opportunity to encourage them to ask for help if they need it to make sure they know that that’s part of working in a team. When I was fresh out of university, I often tried to solve things alone for far too long because it’s what I was used to doing after years of working on assignments, projects, and tests alone. Breaking that habit has been essential in my career development and has helped me learn a lot faster than I would have if I’d stuck to doing everything alone. Asking for help is a key aspect of working effectively, no matter how experienced you are.

At Stitch, we try to bridge the gap in understanding by providing guidelines to new developers on what’s expected of them as they onboard. They’re assigned an onboarding buddy who works alongside them and is always and explicitly available to help and answer any questions.

To create the space where this is possible, I’ve found it helpful to clearly outline where, when, and how the person I’m onboarding can contact me. I make it clear that my role while they’re onboarding is to make sure they succeed. As part of that, it’s my job to answer their questions. Laying the foundation early can ensure that junior developers understand they can ask you questions and that they know when and how they can do that.

A trap I’ve fallen into is to assume the person onboarding me is too busy to answer my questions. So, making it explicit that it’s your job to answer questions and that you have the time to do this helps new developers to feel comfortable with asking questions.

You can also use this process to give new developers a boost by introducing them to people who are relevant to the thing they’re struggling with. If they know who the right person to ask for help is, it’ll make that process much simpler. I try to ensure I always at least mention the person who would be best placed to help them with things they’re struggling with. Pointing them in the right direction is often enough to let them find the solution independently.

Be specific and give context

When communicating with new developers who might not have any context of what is generally expected or allowed, being explicit about tasks, the context surrounding them and the thinking behind them is important.

For example, a trap I fall into regularly is only saying what needs to be done instead of also including why it should be done. If you can describe the problem-solving process as well as the solution, you can help new joiners develop their understanding of the types of errors you see and how to solve them. It also means there will be a record in whatever chat application you’re using of how to solve the specific issue in the future, and they shouldn’t have to ask for help with it again. Another benefit of this approach is that you can take the common questions and turn them into an onboarding document for future new joiners.

Teach new developers how to learn

As a junior developer, I often found that knowing what to search for or ask was itself a hard problem. If I’ve never encountered an issue before, it can be hard to put into words what exactly I’m trying to achieve. When helping someone new, it can be useful to have them describe what they wanted to happen and then what they observed happening.

Often they will describe an error that is already tracked internally but isn’t fixed yet, which can save them a lot of pain. For example, we have a data flow test that is known to be broken. After seeing people struggle to figure out the issue during deployments, we’ve created a document of known errors that can be a good reference for new joiners too. Providing more context at each step to build up new developers’ knowledge empowers them to be more capable going forward.

Prioritise understanding over getting unstuck

When you’re onboarding junior developers, it’s often tempting to give them the answers so they can move on from being stuck. It’s often a better approach to ask them questions that lead them to the answer. For example, if someone is missing a header from an API call and can’t figure out why it won’t work, you could lead them to the answer through the following line of questioning:

1. Can you show me the API calls you’ve tried that are failing?
2. Is there anything different between these calls and the calls shown in the documentation?
3. If you use the query from the example, does it work?
4. Can you print out your query and the corresponding working example query? Are there any differences?

Obviously, if they’re struggling, it’s best to give them more direct help. But as you onboard new people, you’ll get a sense of how much help they might need, and you can adjust as you go.

Be mindful of the language you use

In my experience, most developers I’ve talked to either experience or have experienced imposter syndrome. This is especially true for newer, more junior developers who are still figuring out their roles.

I’ve seen imposter syndrome exacerbated by inconsiderate language use. An example of this could be making something hard seem easy. It might be easy for you, but that’s probably because you’ve done it many times before. As much as it might feel like you’re being reassuring by saying it’s easy, it’s not always conducive to creating a safe, supportive environment for junior developers. If they begin the task and find it difficult, they might find it hard to come back to you for help because they know you’ve said it was easy even though they’re struggling.

Using words like “just” can also trivialise hard work. If you’re tasked with doing something and the person instructing you says something like “just write a migration for that change”, when you do finally finish figuring out how to connect to the database, how to write the migration, how to run and test the migration and then finally validate that it works, you’ll probably feel like you took longer than you should have instead of feeling like you overcame some worthwhile obstacle and learned new useful things along the way.

Be open to learning from your new team members

In the same vein, if a junior developer complains about something, it’s not productive to dismiss that feedback as them being new. If it’s not purely due to misunderstanding, then it’s worth considering that it should either be better documented or should be made less complicated. In these situations, it can be a great learning opportunity to have the person you’re onboarding document all their challenges with the onboarding or the tasks they work on initially and use that to inform process and documentation changes. The API integration task we give to new joiners at Stitch is a great example of where we use this to our advantage. For the onboarding automated setup script, onboarding documentation and API documentation, I get new joiners to write down anything they’ve struggled with so we can use it to make the documentation and tooling better every time.

At Stitch we value the diversity of our team and their talent and are constantly seeking to ensure we’re supporting their development no matter the level they’re at. These principles are part of our company values, and we’ve strived to make them part of the way we work.

Be considerate: Everyone was new once—even you. Remember what it was like when everything around you was something you didn’t yet understand and know that this can sometimes be overwhelming. Try to take the points of confusion and frustration and turn them into valuable learning opportunities both for you and your new joiner.

Related Resources:

• A 3-Step Process to Communicate More Effectively as a Developer
• 5 Communication Habits That Keep My Team Aligned
• How to Improve Internal Team Comms by Understanding What Information You're Missing
• Hacking Asynchronous Communication as a Remote Team Member

Jethro Muller is a senior full stack developer at Stitch. He primarily works in Typescript on server-side NodeJS code. He enjoys ORM query optimisation, building pipelines and tooling, optimising workflows, and playing with AI.