Software projects succeed or fail based on the quality of the teams behind them. Expert developers can be hard to find. So how do you get junior developers to level up? It’s not enough to teach how to use a framework or tech stack. Good developers can follow a pattern. Great developers know why patterns are established and how to improve the project as it grows.
A lot of developers can benefit from coaching. Yes, recent college or boot camp graduates will likely need help integrating into real-world work, but anyone onboarding to a project with less than a few years of experience should be considered for additional support. The best candidates for coaching are developers who frequently require help but are eager to learn. Established projects with a high number of junior developers should also consider a broader training plan to maintain the health of the project and invest in team productivity.
Teach More Than Tech
While each developer and tech stack requires individualized training, much of software engineering depends on broader skills. Understanding what code is doing is essential to see why technical decisions were made. Supporting that base of technical skills are team processes and cultures that reinforce good decision-making.
In addition to language-level features, teach the common APIs your team uses. Prioritize what tools developers will actually use since exhaustive training is practically meaningless without hands-on practice. Ultimately every developer needs to learn how to teach themselves, so demonstrate how to look up and understand documentation. If a junior developer asks something you don’t know, show them how you would look up the answer. Instilling a curiosity about how applications work will lead to maturity over time and better project outcomes.
Breaking the Rules
Software development is full of rules. Phrases like “don’t repeat yourself” and “don’t test private methods” are blunt recommendations that help avoid maintenance nightmares. Junior developers need to learn these recommendations AND the reason why they exist. Even though these rules sound black and white, they gloss over important trade-offs. Repeating code twice is better than a hasty abstraction that is harder to use but it’s important to map out where those boundaries are.
Teaching junior developers why decisions are made and what tradeoffs we accept is key to them being able to take the lead on their work. Discussing how competing concerns play out will help developers figure out how to apply that teaching in the future. And flexing this thought process can lead to real innovation. Senior developers may have patterns they’ve internalized that are no longer relevant due to platform-level changes.
Lots of skills outside of programming have a huge impact on a project’s success. Structures like Agile methodologies and Pull Request (PR) review restrictions should support goals like iterating on ideas and enforcing checks. But poorly understood processes become roadblocks. PRs are a great example of a process with a lot of value if used appropriately. They provide opportunities for direct feedback on code conventions and architectural decisions. PRs are also an opportunity to learn from other developers senior or junior and ask questions about what a confusing piece of code does. Too often PR reviews are a formality when they can be important communication tools.
Practices like scrum retrospectives are a great place for junior developers to hear and learn about the process. But more intentional reviews of a team’s expectations will smooth the way for developers to meaningfully participate. Ultimately, having a culture of feedback is what allows everyone to improve over time. This also includes communication with designers, business stakeholders, and other engineering teams. Otherwise, junior developers will continually be slowed down by blockers. By including process information in onboarding training, additional team members will empower your team rather than being a drag.
Well-oiled teams will have lots of touchpoints for sharing knowledge with junior developers. But consider intentionally adding more structured times as well. Junior developers can even initiate these meetings if their team lacks an existing coaching initiative.
In order to establish consistent skills and expectations, it helps to get everyone in the same room. Meeting time can be expensive, but an hour a week to discuss an important topic can provide huge returns to your junior developers and your team morale. These meetings can be structured like a lecture from an expert or opened up to a discussion. Here are some suggested topics:
- Application architecture
- Maintainable code practices
- Pull Request expectations
- Programming language deep dive
- Library deep dives
- Automated testing approaches
- Information security & secure coding practices
- Performance & scalability considerations
As long as the conversation is engaging and relevant to the work the team is doing, it can be beneficial. One of the best parts of this approach is that it can be helpful for the whole team and can be opt-in. It’s also helpful to keep a record of the content discussed such as meeting recordings or links to relevant documentation so developers can review the content later as needed.
Agile methodologies like Extreme Programming include the practice of pair programming for good reason. It enables real-time feedback, improves code quality, and is great for leveling up junior developers. Even a couple of hours a few times a week can have a significant impact. With screen-sharing tools now ubiquitous, it’s easier than ever to start a call and work together on a task.
While pairing, both developers should take turns driving the session. This allows the more senior developer to demonstrate their approach and for the junior developer to get feedback while they practice. Throughout the process, the developers should discuss what they are thinking, including what they are doing, why, and any potential concerns or decisions to figure out. Probe the reasoning of the other developer’s decisions in a non-judgmental way. It’s a great opportunity to explore assumptions and share experiences. Let junior developers make their own choices as long as they take the time to explain why. Sometimes it makes sense to prune a dead-end path but let junior developers feel ownership of their work.
Developers are Human
It’s important to acknowledge, being a newbie can be intimidating. Fear of not being good enough holds many people back and it’s one of the reasons too many developers drop out of the field after a few years. Asking for help is an important skill but also scary. To help junior developers reach their potential, we need to treat them with kindness and respect. Offer tips you find helpful but don’t be condescending and assume they don’t know anything. Be relatable and acknowledge the fears you’ve had in the past. If someone is willing to learn and challenge themselves, the freedom to make little mistakes can change their trajectory for the better.
Most software teams underutilize their greenest members. Growth takes time, but a little investment in fundamentals and hands-on training can empower junior developers to become highly productive members of the team. Instead of seeing who sinks or swims when thrown into a complex project, give people the tools to get curious about the code, understand why decisions were made, and get regular feedback so they can grow. Knowledge sharing can happen in PRs, team discussions, and one-on-one pair programming sessions. If done with empathy and respect, you may be surprised by who’s leveling up your team next year.