Any specific wisdom that has made the process best for everyone?
How do you approach working with juniors working their first professional programming job?
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (14)
It's crucially important to give new folks space to learn. I send a very clear message that I don't expect learning programming to be extra-curricular work - we need to make space for that to happen on-the-job. It's easy enough to burn out without forcing people to do more work outside of work. With the members on my team who are learning new tech, I set aside a lot of time, something on the order of 1-2 days a week, to do nothing but read + explore.
It's also important to give people real responsibility + real freedom to make choices. I give new folks important jobs in real systems, and let them make decisions about how things ought to be put together. At first, each decision goes through review, and we scale back the amount of review as more independence is gained.
Mentoring is also crucial. Code review, pair-programming and group brainstorming are amazing learning tools! Each new person needs to be able to escalate their confusion without fear of judgement or reprisal.
This sounds great, I wish to start working with people like you.
Keep up!
There re was a great talk by Netta Bondy on the subject.
My approach, if someone's been hired as a programmer, has been to assume they know what they're doing unless they ask for help. Bondy says-- and this matches my own experience, looking back on the last time I was tasked with mentoring a junior dev-- that you should assume they need help or oversight until they demonstrate independent competence.
If put in this situation again, I would be explicit about it: "You have my permission to interrupt me, even if I look like I'm engrossed in something and wearing my giant aviation grade go-away headphones. My priority-- and my job-- is to make sure you know what you're supposed to be doing and have the information and tools to do it."
Also, I would check in at least once a day with them, until it's clear that they do know what they're doing and will ask for help whenever they don't. Come to think of it, taking this approach with all new teammates seems like it would make sense, even for folks with 20+ years of dev experience; one would just expect that more experienced folks get to the point of semi-independence quicker (even after that point, checking in every few days can't hurt).
Slowly, and visibly, as not to spook them. :)
Be a good mentor, not a dickhead
I write this from the perspective of having been the junior and received the mentoring and guidance from an experienced colleague.
Be gentle, work with them, allow them to explore the code-base and to experiment.
Take things slowly, do pair programming, discuss what is needed to be achieved and how to do it; this is even better if options can be discussed with their individual pros and cons.
The first few months are likely to be tough, though don't choose massive huge features, start with something useful but small, maybe even a bug to investigate; though that could go the other way of being painful.
If you do pair, don't do so in a way that you would work by your self, you have to go slowly and have a really open dialogue. Those thoughts that zip through your head have to be slowed down and verbalised; your newbie will learn a lot of the process of programming as much as the technical stuff.
Admit when you don't know something and that it's something that can be worked out later together or individually.
Don't assume their skill level; it might be their first pro job, but they may have been writing for a while...
Whilst all this sounds like you're holding their hand, give them the space to do their own tasks, then do the code review together to be able to discuss the change; requirement specs, solution, implementation, etc...
You mentoring \ training them makes you a better pro.
I hope these help.
This was on a new product. But I think I would do it again for an existing product.
My approach was to give them materials (tutorials, examples) to work through at their own pace. These materials were common, online resources for the techs we were using. Then I kept some availability for questions they might have. Periodically, I would hold an impromptu session to explain a few other topics I wanted them to be aware of. These were emergent based on what I was hearing from their learning experience.
After a couple of weeks, I had them start working on small product features. But with no immediate deadline... sortof work on it until its done. That gave them a chance to practically apply the knowledge gained so far. I'm sure they wrote and rewrote things multiple times. And of course, I was available to help, peer, code review, etc. And at this stage, you have to have a light touch in peering and code reviews -- just bring up the most important things. (Generally, that it meets the business need. Followed directly by using the simplest solution.) In code reviews (and not just with juniors) I suggest but very rarely insist. They are free to choose a different way. If I'm right they will have to come back and follow my suggestion later and then they will understand why too. So it was a valuable learning experience. We were using Elm, so it is straightforward to refactor later to fix mistakes they made. IOW, there was a low risk of permanent harm to the product during the learning phase.
After another 2 weeks or month of working through features at their own pace, we started estimating and planning out their work. And then we more or less settled into a cadence of releases.
I suppose I would call myself a Junior Developer. I've been coding for a year and a half, but I've only got an official role within the last month. I've taught myself HTML, CSS, Javascript, SQL, PL/SQL, jQuery, and a little more. But I have done it all practically myself. Our "Senior Dev" has done very little to help me, and in some ways that has made me a better Developer. I very rarely ask questions now, as I know I won't get an answer and it's better if I use my time figuring it out myself.
But I also feel that means we don't share knowledge like I see people talk about. It is frustrating at time, and I won't lie, sometimes it makes me hate my job. But it also means I want to be better than him and I know that if I was in his position, I would do things very different.
I tell them: If you code software for a living, there is no middle ground, either you ship or you die!
Joke aside, I tell them what I want them to do and check on them later. Some get up and running on their own, some need a bit help here and there...
I want people to be creative and cruious :)
The approach I've used is to start out by giving them training spikes. Spikes are usually timeboxed to 2-3 days. For example, the spike might be study a set of stored procedures in XYZ database and prepare X number of discussion questions about them for the senior developer(s). This would be followed up with a mentoring/pairing session. The idea is to get them acclimated to the development process, collaboration and cadence of the team. This allows them to be able to participate in stand-ups and sets up a mentoring and communication process with more senior developers.
A friend of mine acts all pissed off in front of juniors because someone pushed code with breakpoints on, so the build is all blocked.
After that he pairs with them just to see them remove breakpoints prior to pushing their code.
Kinda cruel, but funny at the same time.
Yeah, I get that this is kind of amusing. But having been in the junior dev's shoes, this isn't fun. Everyone breaks the build once in a while. Have a good laugh, update your git hooks/linter, and let it go.
I tend to think that at some point your friend will break the build. When that happens, those junior devs may not say anything, but they'll remember that when they made the same mistake, he made them feel small.
Be patient and make it clear that no question is a silly question : it's best to sort out any unknowns or blockers sooner and to become productive rather than to wonder and struggle in silence.