That is, some notes on helping junior developers focus on execution when they are surrounded by the twin distractions of novelty and outright broken things. With apologies to Love in the Time of Cholera1.
Faced with a junior developer who finds themselves stuck, what questions could you ask them to help them get back on the happy path without all the distractions that junior developers face:
The trick for juniors, is they’re always learning more than one thing at a time, often on accident. They want to build a feature, but it requires a new library, and it requires learning the library. They went to start up my development server, but then something weird happens with Unix. It’s the essential challenge of being a junior – they’re just getting started, so they’re always learning a couple of things at a time2.
Is this a side quest?
Compared to senior developers, juniors often find themselves down the wrong rabbit hole. Senior developers have a better sense of when they are chasing the right lead. Over the course of months and years, they develop a sense of when we’re looking at a red herring. More so, they learn to recognize issues caused by development environment rot, bad data, unrelated bugs, and other sorts of non-essential annoyances.
In those situations, it’s helpful to ask junior developers if they’re pursuing the essential problem or if they’re on a side-quest. If it’s a side-quest, write it down and get back to the essential issue. If it’s the essential problem, then…
What do you need to know to focus or make progress?
At all experience levels, software developers face the frustration of “it just doesn’t work”. Occasionally, this is down to outright broken software. Often it’s not knowing about or misunderstanding a crucial detail of how the sub-systems work together.
It’s extremely tempting to skip ahead, tell a junior developer what they need to know, and move along. That’s how it works on the internet2. It’s time efficient. The ability to swoop in with an answer feels wizardly, and that’s pretty fun.
Unfortunately, that’s the “give a man a fish, you feed them for a day” approach. Junior devs are a source of endless questions, sometimes excellent and sometimes not. Answering one question, no matter how decisively, is unlikely to change the shape of the ‘questions per hour’ graph.
Better questions, better information
Better to teach junior developers to generate better questions. Nudge them to lead with what they know about the non-working situation. Encourage them to steer clear of trying magical solutions3 and whack-a-mole troubleshooting4.
This teaches a junior developer two things:
- They probably know more than they think.
- They’re more likely to find their answer by answering questions than by fixating on what doesn’t work
Which questions can you answer right now?
Now that our junior developer is armed with better questions, it’s time to answer them. Given all the questions that might help them make progress, they should start from the ones we know how to answer right now. Sometimes luck strikes and the problem is solved. Other times, the issue and the tricky questions remain.
This is the scenario where senior developers5 can help a junior developer the most and teach them to fish, so to speak. Senior developers are often more adept at using REPLs, debuggers, automated tests, documentation, static code reading, inspecting data, or observing runtime behavior to turn good questions into answers. In one session, a mentor can show an apprentice how to use an unfamiliar tool, think about problem-solving, and solve the original question. The mentor will probably learn something too!
Luck happens
There is a bit of chance in solving problems. Recall what you already know. Pattern match on the (correct) factors that likely won’t bring you closer to a solution. Ask answerable questions that narrow the issue space. If you make a mis-step at any of these, you could end up confusing yourself even more!
Stick with it. Maybe step away if you’re already drained, or it’s getting late in the day. But stick with it. Persistence beats luck and chance, most of the time6.
Thanks to Wade Winningham and Henrik Nyh for sharing ideas on this topic via ruby.social.
- Which I have not read but is a pretty snappy title. ↩
- e.g. Stack Overflow and its ilk ↩
- e.g. restart the computer, reinstall something ↩
- Trying random changes, repeating one test in hopes of seeing a different result, blindly applying suggestions from similar problems posted on the internet. ↩
- Senior developers appear to have the superpower of seeing circumstances and going directly to the root cause. That usually happens by quickly enumerating what they know about the problem and pattern matching on the circumstances to reduce the problem space to a few possibilities worth eliminating or verifying.
This happens via answering enough questions that the problem or behavior of the system becomes obvious. It’s a bit of crafting a theory until you trip over the actual situation. ↩ - Casinos and rigged games are notable exceptions. ↩
