
Ask HN: How to Guide a Junior Developer? - gh0zt
I recently started a new position as a senior developer in a small company. The setup is basically CTO&#x2F;Lead Dev - Me - Junior Developer.
The junior is a newcomer with a non IT background. We do webdevelopment and I have a bit of a hard time to understand how I can lead him to be a better developer. He seems motivated to learn but has a bad intuition on how to do things the &quot;right&quot; way.
Happy about tips on literature or any practical advice how to guide him. We do Kanban style development with code reviews, CI&#x2F;CD for context.
Tried to break down tasks together, to a point where I rather have implemented the stuff myself. I can spend roughly about 20% of my time to invest in him for a couple of month.
Lead dev seems happy to not be involved in the process as they have worked together for quite a while without any substantial progress on the juniors side.
======
9wzYQbTYsAIc
> 1) Make it their time 2) Mentor the whole person 3) Don’t give answers,
> provide strategies 4) Give homework 5) Don’t prevent all mistakes, just
> horrible ones 6) Don’t try to create a you-clone

[https://humanwhocodes.com/blog/2014/01/07/how-to-be-a-
mentor...](https://humanwhocodes.com/blog/2014/01/07/how-to-be-a-mentor/)

~~~
emagdnim2100
> 5) Don't prevent all mistakes, just horrible ones

I think this is critical, and engineers seem to struggle with it more than the
average person. Remember your codebase is a business tool, not an art project.
It's okay if some of your junior person's inelegant code ships as long as it
works acceptably well. If you try to make every line exactly what you would
have written, you'll drive yourself crazy.

------
chasingthewind
I've been mentoring junior engineers for fifteen years and I've found a lot of
techniques that work but there are two ingredients that I think have to be
present:

1) You're motivated to help

2) The junior engineer is motivated to improve

I don't think it matters what techniques you use if these two things are in
place. If they're not in place then it is very likely not going to pay off
regardless of how you approach the mechanics.

Code reviews are critical. Pair programming can be a valuable technique. Going
over concepts and best practices can help. Creating a plan for the junior
engineer to study the craft. Books like Clean Code can be great at starting
discussions.

Good luck!

------
dangerface
> I can lead him to be a better developer

You can lead a horse to water but you cant make it drink, people are more
stubborn than horses and will just act out if you try to lead them.

You should act as an example of how the junior should behave. If you want the
junior to ask for advice when they need it and value that advice then you will
have to demonstrate this.

Don't limit yourself to asking the lead or asking about things you don't know
about. Valuing other peoples advice even when you don't need it is a sign of
seniority not a sign of being incapable, it shows that you understand that
improving your skills never stops and you can find improvement in anything.

When the junior asks you for your advice your job is to act as a sign post
point them down the right path. Tell them warn them of gotchas and encourage
them but don't carry them for the journey or spoil whats at the end, thats for
them to figure out.

------
digitalsushi
That 10,000 hours of work to master some process - that happens after 4 years
of full time, salaried work, and after a quarter century, balloons towards
60,000 hours of doing this stuff. I never feel like I know very much, but as I
start to notice grey hairs here and there, it occurs to me that I do know a
_lot_ of stuff. Broad stuff. None of it makes me a genius, and, I'm not a
genius so the math works out. My junk drawer is just 50 feet deep.

But taking someone with more like 150 hours of experience, who has just barely
been indoctrinated into a complex process, who has no idea what they don't
know they don't know ... yikes! We have to sometimes literally pretend that we
have magic, and then work backwards from that so as not to overload them. I
have found myself adopting a naive persona as I teach, a sort of fool that is
also discovering as I demonstrate, to try and relieve some of that
intimidation.

Is such a thing patronizing? I think, yes, but that without it being
nefarious.

~~~
mcpeepants
Not patronizing, I think that's just empathy. Knowing that what _you_ know
isn't "known" just by being told. Otherwise you just end up dumping the
contents of your 50 ft junk drawer (and your ego) on the floor of your open
office space, and sure, maybe they sift through and find a few useful
nicknacks to push them forward in their work. But they don't become better at
discovering, collecting, or curating nicknacks.

------
lukewrites
Ask them to keep a written log of the stories they work on, and during
“mentoring time” use it for things to talk about. (Why did you do this? What
did you think would happen? Etc)

> Lead dev seems happy to not be involved in the process as they have worked
> together for quite a while without any substantial progress on the juniors
> side.

With the lead dev define what “progress” would look like as specific,
measurable goals and then work towards those goals with the jr.

In the classroom a common technique is I Do (E.g. the jr watches you break
down a story), We Do (break it down together), You Do (it’s all them, but you
give support and feedback).

------
nobodyandproud
Intuition is built-up over time. I would try and carve out smaller, well-
defined tasks for the individual.

It may also be worth your company’s time and money to find some online
training courses to target specific weak-points.

~~~
macando
Intuition indeed. Nothing can replace a stream of several-hour long hyper-
focused sessions of debugging bizarre multi-layer multi-language multi-concept
bugs. The mind needs to expand and adjust to that.

------
afarrell
One of the most important skills for a junior developer is the ability to ask
good questions. As a lead, you're never going to be able to perfectly set them
up with _all_ the context they need for a task, so they're going to need to be
able to get the bits that they're missing.

The best guide I've seen so far on how to do this is by Julia Evans:
[https://jvns.ca/blog/good-questions/](https://jvns.ca/blog/good-questions/)

------
protonimitate
> ... as they have worked together for quite a while without any substantial
> progress on the juniors side.

Seems like a misalignment on ability and expectations of the jr. What is
"substantial" progress defined as? Was that definition shared with jr? It's
hard to make progress towards something if that something is nebulous.

>He seems motivated to learn but has a bad intuition on how to do things the
"right" way.

What is the "right" way in context? Is it the difference between a non-working
and working a solution? Or is the difference between a sub-optimal solution
and the best possible solution?

To me this sounds like an ideal jr hire. Eager to learn, and still green. This
sounds ultimately like a case of poorly defined expectations.

What do you expect the responsibilities of the jr to look like in 6 months? A
year? If you start there you can work backwards and help set smaller goals.

Without a strong idea of where you want them to end up, you're just asking
them to "get good" which is bound to be frustrating for all parties.

------
jtonz
A key focus that I always have when mentoring juniors is confining their work
scope to something they can refer back to. It is a common mentality to simply
allow them to browse around the code and perhaps solve some simple bugs. To
allow them to understand the system and how it all works. My thoughts on this
is that doing so is akin to giving someone new to a spoken language a novel,
suggesting they peruse the book and perhaps find a typo. Understandably this
can be a lot to take in.

For me I assign them a fully refined task to create something and go through
the full end to end process with them. It will allow them in the future when
hitting a road-block at any step of the process to go back to this code, ask
themselves "what did I do here which was right" and try to apply it to their
current work.

------
cbanek
There's a lot of great advice here already.

> Tried to break down tasks together, to a point where I rather have
> implemented the stuff myself

I know this happens. I've felt it myself sometimes. But I just try to remind
myself that this is the investment part - sometimes it takes a lot longer, but
the question is what will they be able to produce this time next year? It's a
good feeling when someone goes from taking a long time and having bad
intuition, and seeing them get to a better place. The red flag is when they
don't seem to improve over quite some time.

Hopefully if you're taking that much time together, you enjoy each others
company, which I think is a good sign!

------
macando
Get them to read at least the first 13 chapters of "Clean Code" by Robert C
Martin. I read it 6 months into my first professional engagement and it helped
my development a lot. It will make your life easier too.

------
suyash
Answer their questions and encourage them to ask anything (there is no stupid
question).

------
sircastor
Code reviews with explanatory feedback, pair programming for both your code
and his. Celebrate wins.

