Yes. Without a doubt.
Junior developers cannot learn by being isolated from the team, and the most infuriating way in which they get to be isolated is by not being included in day to day team activities. You may be thinking watercooler. I am thinking pushing code and having someone use it.
If we don’t include junior developers in the entire software development lifecycle, we aren’t training them to succeed.
There is no better teacher than shipping.
So if you are a junior developer wondering if pushing code that makes it into production is a reasonable expectation, let me reassure you that it is, and that you should be wary of environments where the code you write isn’t being used.
The company should have enough safety rails to protect junior developers from making terrible mistakes or recovering from them, but other than that, writing code is something we do to achieve a goal, and we cannot achieve the goal of serving users if users don’t get to have the features a junior developer writes, or the bugs they solve.
I advocate for getting a tiny commit into production as early as Day ONE of your new job, but if that isn’t feasible, Week ONE is good enough as a goal.
Learning how code goes from your precious code editor and into users lives is a critical skill for engineers At All Levels while they onboard into a new job.
This post is part of my series for remote software developers. You can check it out and subscribe here https://rowasc.com/engineers-working-remotely/
Latest comments (4)
There's something I actually don't understand: what else would they do if not contribute right away to the project? They're junior, sure, but you hired them, and if not for working on your projects, then what for?
Give them tasks adapted to their skills, that will make them explore the code base and discover the contribution process (we have mandatory code reviews for example). Code review or whatever you put in place should prevent them doing any harm, and make them learn and improve their skills, from day/week one.
Fwiw, we do have a few training sessions (approx. 4 days in total) about our internal processes, how to use git, how CI and code reviews work, and a few sessions on the basics of HTTP, SQL, and frontend development (things they'll probably use whichever the project and team). Those come while they're already in their team so they can directly relate what they learned to what they're tasked to do.
Ha. Yeah, honestly I have seen a lot of cases where the junior dev is just thrown in a random useless task to Train Them (TM) so they spend a month writing code that will go straight to the trash, or reading stuff... but as you mention, it doesn't work that way! You cant expect junior engineers to grow if you don't let them learn with their team.
Completely agree! After the onboarding process and training. First thing is a commit adding themselves to the seeders. Simple task and allows for exploration of the system and good confidence boost for the new team member.
Yes, exactly. It doesn't have to be a big thing, but that first commit going live is a huge learning moment and it gives the junior dev confidence that they belong.