Working with Junior Developers: Teaching, Training, and Mentoring

Show Notes

Prices subject to change and are listed in USD

Support the show from as little as ~$1/month
Get a shoutout at the end of the episode (while supplies last) for just ~$3/month
Help support the HTML All The Things Podcast: Click Here

We receive a monetary kickback when you use our link

Learn to code using Scrimba with their interactive follow along code editor
Join their exclusive discord communities and network to find your first job!
Use this URL to get 10% off on all their paid plans: https://tinyurl.com/ScrimbaHATT

Instagram reel
- https://www.instagram.com/reel/C0KXN7CgJjS/?igsh=MTljZzlqd3U0d3NrOA==‍
Meme about toxic workplaces training their junior developers through verbal force
Polarizing comments range from disbelief that toxic workplaces exist like this, through people that experienced it and eventually people that expect it/have dished out it

The polarizing comment section got me thinking about how I would treat a new junior developer on my team, assuming I’m no longer a junior myself
This lead me to think about my own experience as a new IT tech, how I grew out of that beginner stage, and how I would handle helping someone new (or would I even help them)
The conclusion:
- It makes more sense helping a junior developer out of the junior developer stage so that they’re a reliable team member
- It does not make sense to make the workplace toxic as a sort of “trial by fire” or “sink or swim” as it may work on some people, but others that could have been really valuable team members may be turned away
- A new junior is experiencing a new workplace with all new people, and they’re new to the trade…so the situation is already a “trial by fire” arguably

Some people believe in the sink or swim method, piling work that would be expected from an experienced team member onto the back of a new junior dev
Others will make the situation more extreme than the normal workload expected from an experienced team member in order to “see what the junior dev is made of”
Reasons for this management style:
- Current team members feel as though it isn't their job to teach a junior dev
- Workload may be too high on team members so they feel as though they don't have time to do any training (this may be true)
- Some believe that it this is the way to weed out the weak, only those “worthy” make it on their team
Beyond some light joking like “oh give this crappy task to the new guy haha” I find this management style can easily give way to a toxic workplace
This does not mean that there aren’t useful parts of the “trial by fire” method, it can be good to challenge yourself and team members as a way to push yourself through difficult tasks or to see what people are made of - within reason

My preferred management method is more so about helping the junior dev “grow” into a fully fledged team member
Having another set of fully capable hands on the team is more helpful than hurtful

Gauge where you junior dev is coming from
-If they’re transitioning from another office job, maybe even another tech office job, then they may not have much of a transitionary period outside the new tech they’re working with
- But if they’re just come out of school (potentially their first “real” job ever) then the transition will be more of a shock
Teach the work and team culture
- Instead of having your junior dev not ask any questions out of fear, or ask too many questions out of turn (ie breaking people’s deep work time) teach them the ins-and-outs
- For example, maybe everyone from 1-3pm on the team does a couple hours of deep work, let the new team member know that
Teach their place in the company
- Ensure your junior dev knows what their tasks are, where the team stands in the company, and what their role is within the team
- This prevents stepping on toes, or under stepping and seeming lazy accidentally
Teach proprietary company methods
- All companies are organized a little differently internally
- If something is not Googleable…(examples below)
-- The company has a specific way they’d like tickets filled out and responded to
-- Pull requests are done in a particular way
-- Commit messages must be written in a certain way
- Teaching these methods whether verbally or through documentation will help problems stay more technical than logistical

Assign Useful Not Pertinent Tasks
- Assign your junior dev tasks that will allow you to see their strengths and weaknesses - so you can gauge where they are overall
- A useful way to to do this is to assign them tasks that if completed successfully will be really helpful to the team, but if they don’t it won’t affect the team negatively
- For example, a task that is a few months out that the team isn’t planning on touching soon may be a good task for a junior who is slower and may fail at to attempt. If all their work is scrap, the team wasn’t going to touch it any, and if their work is good but just slow, there was time allotted to it‍
Figure out how they learn
- This is time consuming and may be challenging for some teams to balance, but if you can figure out how your junior dev learns best by investing some initial learning time, you can help speed up the learning process by directly teaching the way the junior learns best
- Some people are example based, written based, need help once all the way through then extrapolate

Challenge your junior dev
- You can’t handhold someone forever, you will need to let them go and prove themselves at some point
- The best way to do this is to give the junior dev challenges that they have a good chance of rising too but may fail at, in a controlled environment
- That means that you shouldn’t be:
-- Giving them a huge deployment to do on their own
-- Giving them a huge task that the whole team relies on, even though they will likely fail and be ridiculed for it
-- Expecting for everything to be perfect so the team can move on to the next thing
- Challenges should increase with the skill of the dev and sometimes will outpace, or underpace their skill as you (the team member training them) figure out where they’re at in their learning and how fast they learn new things
- Think of this as a trial by fire with a huge safety net underneath

Sometimes helping a junior developer in this way is not possible because of:

Tight deadlines on the entire team
Extremely high workloads
Company culture - the entire company may believe in a “trial by fire” training method and therefore as an individual (or a single team) you may not have the pull to change that
You may be assigned to train a junior dev, but the tech lead above you may tell you exactly how to do that
Competition in the workplace, especially amongst layoff season, can make people standoffish to new team members - leading established team members to want the new guy to fail, or to use them as a way to prove that they themselves are really needed in comparison to the shotty work the newbie is doing (trying to give themselves job security)