Setting Up Guard Rails

Senior developers are biased when it comes to learning. Because they already know what the playing field looks like, they can easily skim through reading material, take shortcuts, choose the right trade-offs, and explain to you why they did what they did, in a snap.

On the other hand, junior developers have zero knowledge of the playing field. As a result, they'll implement solutions based on the limited knowledge they have. This can often be seen in the form of archaic-looking code or brute-force attempts to solving a problem.

A senior developer won't have all the time in the world to guide a junior developer. But you also cannot leave a junior developer learning aimlessly. To resolve this, what you need are what I call "guard-rails" - a combination of documentation, tooling, and process.

Documentation. Document everything to the best of your abilities. Write a readme, a dedicated docs section, a wiki page, or even comment code where odd decisions were made. You don't have to document everything, especially when you can just cross-link to external resources. Just write down unique procedures, shortcuts taken, odd quirks.

Tooling. Set up scripts that junior developers can use to validate their work without you having to do it. Automate mundane tasks like linting, testing, and deployment. Make sure warnings are verbose and informative, while breakages fail fast and hard. Do not leave anyone guessing what happened.

Process. Enforce a consistent process across all your work. For instance, Kanban sets a process for tracking work, Design Systems for developing the UI, Frameworks for writing code, Pull Requests for reviewing code. Having a consistent process makes everything predictable and repeatable, removing the guesswork and the overhead that comes with it.

Once these three are set, development should be like a fine-tuned assembly line. Everyone has a defined set of duties, a defined set of tools, and usable documentation should anything look out of the ordinary.

Conclusion

Let loose your junior developers. Let them thrash in the codebase, that's how they will learn. But set up guardrails to keep juniors within safe boundaries. Keep thrashing to a minimum so that teaching them doesn't take up too much time. Experience is the best teacher. But senior developers have the power to make it even better for their juniors.

PS: One way to identify a junior developer by code is when there's a lack of use of native APIs. For example, in JavaScript, using loops when array methods are available for the said operation. In this case, looping can be seen as a brute-force way of doing it.