I know it’s a joke, but I do not enjoy being in the position with the stick.
Like, man, they’ll sometimes check in some stupid stuff. Yesterday, I told two juniors to implement a unit test and they could use annotations like on another unit test, which I also explained.
Problem is, I had introduced that unit test a week ago and had given it an ignored-annotation, to document that that’s currently broken.
And you guessed it, they copied that ignored-annotation, too, complete with the comment “//TODO currently broken”. The test they implemented was not run, not even once.
And like, what the fuck do I do with that? Sure enough, it was a miscommunication, I’ll try to be clearer next time.
But I’d also really like to explain to them whatever information they were missing, if they were missing any. Like, did they not know what the ignored-annotation does? Did they not think at all and just verbatim copied everything?
And then the problem is, this is kind of so dumb, that even just bringing it up is going to be embarassing for them. It’s already me beating them with a stick.
I’d much rather praise them when they do something well, but this is so hard to spot when just reading over committed code. All the obstacles they cleared are not visible in there.
Sometimes it takes a little unintentional embarrassment to drive a point home. It’ll make them think twice next time.
What I mean by that is that as long as you’re not intentionally or maliciously trying to embarrass them, then you shouldn’t feel bad. You cannot always control how somebody receives information; nor should you. The best you can do is to be clear and polite in your communication. If someone’s feelings get hurt, that’s on them to reconcile, not you.
This is genuinely like parenting a child: they need to develop their critical thinking skills, and to gain their own confidence. So they must be left to make their own mistakes to learn from. Your job is to give show them the tools to use, give advice when necessary, and be there to catch them when they fall; because they will fall.
Doing this will help bolster their self-confidence and make them better mid-/senior-developers later in their career. Coddling them and constantly holding their hand will make them reliant on other people and prevent them from learning anything.
I see coding tasks with juniors a way to actually have a two-way conversation with said juniors and get them engaging.
What I tend to do is I’ll give them an objective, and then I’ll ask them what they think needs to be done. Each step of the way I’ll try and correct them and get them going in the right direction.
If all is well, everything is cleared up, the junior knows what to do at each step, and then they go off and do it. Then I do the code review and the conversation restarts.
More often than not, the junior dev will get mentally stuck on a problem that they cannot conceptualise. That’s fine - I tell them to leave it, work on the stuff they can do, and then we’ll tackle it together.
Generally speaking, good junior devs can conceptualise a task about 50-80% and will get stuck on the other 20-50%. An excellent junior dev can be given a task and independently complete it - the code may not be perfect or up to a middle-senior coding quality, but they can get the job done.
The bad junior developers are the ones who need their hands held at every step of the way and never seem to improve or improve at such a snails pace that it is taking effective resources away from the team (i.e. senior devs - 1 or more) to explain the task repeatedly.
At this point, you need to raise that up to your line manager and have a serious discussion about whether you and your line manager think it is worth the investment to keep teaching this person while making said line manager aware of the problems (and make this based with facts that both you and the line manager can clearly observe and/or have observed).
For the others, you should go from a path of having to explain fundamental concepts (mostly because you both missed out on the weird edge cases of the task at hand) to in months being able to leave said juniors to the task and have them mostly complete it without any help from senior devs. And seeing that progress is why mentoring & code reviews is great - seeing that personal development in real time is an incredibly rewarding feeling.
The point is just differentiating your behavior between what you call a “bad” or a “good” junior.
And from experience the difference is whether they want to learn (regardless of their skill!!) or not (i.e are they passionate or it’s just a job?).
Passionate seniors get frustrated when they try to teach bad juniors, but there is no point on doing that, the problem was just that the senior was not involved in the hiring process…
Completely understand the frustration here. Mistakes happen, even competent people sincerely trying to do a good job can overlook things, etc. But if it’s a pattern of just copying and pasting code without really even trying to understand what it does, that’s a big problem that needs to be addressed. And frankly they should feel embarrassed if it happens more than once or twice.
OTOH, delivering criticism in a way that winds up productive for all involved is difficult at best, and the outcome depends on the junior as much as it does the senior. What good is being right if it ultimately just alienates you from your team? Tough situation for sure, and one of the many reasons it’s so important to hire carefully (which is itself a whole huge can of worms too!).
Can you simply ask them to walk through their submission line by line with you, explaining what it’s doing? If you’ve never asked that before it might come across as a strange request, but if you phrase it well it’s possible this causes them to notice their poor understanding without you ever seeming to point it out.
Can you simply ask them to walk through their submission line by line with you, explaining what it’s doing?
This. Code reviews, especially with junior devs, should always be done as a conversation. It’s an opportunity to learn (from both sides), not just a a bunch of “bad implementation. rewrite” thrown in the PR.
Completely agree! It’s SO much easier to lighten the mood and keep things upbeat and productive in an actual conversation vs. just text-based feedback. For example it makes it easy to throw in self-deprecating anecdotes of your own when discussing mistakes / needed changes, which can really help put juniors at ease. It’s just worlds better in >90% of scenarios.
And you guessed it, they copied that ignored-annotation, too, complete with the comment “//TODO currently broken”. The test they implemented was not run, not even once.
Junior dev here, this is the kind of stuff that is supposed to prompt you to ask questions. Literally one slack message when you see it, and give it a few hours for whenever you have time to see it and respond. I know it’s annoying messaging y’all with stuff but… C’mon you gotta do it sometimes, especially if it’s something you can reasonably predict will come up in review or is a simple question that doesn’t require a lot of time to answer.
Yeah, we had a hard bottleneck for seniors, so they kind of got told to walk on their own as much as they can, but after just two weeks or so, I had to push hard against that, because they would frequently walk into wrong directions and then rectifying that would cost me significantly more time. At one point, I had to review a story three times, because they misunderstood the goal twice.
Similarly, we had a student, who would run off doing things for two weeks, and then suddenly she’d come up to you and tell you that she did this and this and that and now she’s stuck.
And then if the second ‘this’ was an incorrect decision, you have to sit down with her in that exact moment and redo a lot of her work to get everything back on track.
So, yeah, juniors who know when to ask questions are extremely helpful. Otherwise I have to poll them for questions, which takes up time, too.
I’d much rather praise them when they do something well, but this is so hard to spot when just reading over committed code. All the obstacles they cleared are not visible in there.
This is SO true and exactly why code reviews always feel like a beat down (even when they’re not). There’s no visibility into the truly good work that’s already been done.
It’s even worse when you can tell they really tried and still end up with spaghetti. Even mid- to senior developers do this. Rhe more senior they claim to be are, the more embarrasing when you have to get the stick.
Some people try to be so clever with fancy design patterns or bit-tricks, instead of just solving the problem, you now have two problems and a solution to one of them.
I know it’s a joke, but I do not enjoy being in the position with the stick.
Like, man, they’ll sometimes check in some stupid stuff. Yesterday, I told two juniors to implement a unit test and they could use annotations like on another unit test, which I also explained.
Problem is, I had introduced that unit test a week ago and had given it an ignored-annotation, to document that that’s currently broken.
And you guessed it, they copied that ignored-annotation, too, complete with the comment “//TODO currently broken”. The test they implemented was not run, not even once.
And like, what the fuck do I do with that? Sure enough, it was a miscommunication, I’ll try to be clearer next time.
But I’d also really like to explain to them whatever information they were missing, if they were missing any. Like, did they not know what the ignored-annotation does? Did they not think at all and just verbatim copied everything?
And then the problem is, this is kind of so dumb, that even just bringing it up is going to be embarassing for them. It’s already me beating them with a stick.
I’d much rather praise them when they do something well, but this is so hard to spot when just reading over committed code. All the obstacles they cleared are not visible in there.
Sometimes it takes a little unintentional embarrassment to drive a point home. It’ll make them think twice next time.
What I mean by that is that as long as you’re not intentionally or maliciously trying to embarrass them, then you shouldn’t feel bad. You cannot always control how somebody receives information; nor should you. The best you can do is to be clear and polite in your communication. If someone’s feelings get hurt, that’s on them to reconcile, not you.
This is genuinely like parenting a child: they need to develop their critical thinking skills, and to gain their own confidence. So they must be left to make their own mistakes to learn from. Your job is to give show them the tools to use, give advice when necessary, and be there to catch them when they fall; because they will fall.
Doing this will help bolster their self-confidence and make them better mid-/senior-developers later in their career. Coddling them and constantly holding their hand will make them reliant on other people and prevent them from learning anything.
Edit: also remember KISS. 😊
I see coding tasks with juniors a way to actually have a two-way conversation with said juniors and get them engaging.
What I tend to do is I’ll give them an objective, and then I’ll ask them what they think needs to be done. Each step of the way I’ll try and correct them and get them going in the right direction.
If all is well, everything is cleared up, the junior knows what to do at each step, and then they go off and do it. Then I do the code review and the conversation restarts.
More often than not, the junior dev will get mentally stuck on a problem that they cannot conceptualise. That’s fine - I tell them to leave it, work on the stuff they can do, and then we’ll tackle it together.
Generally speaking, good junior devs can conceptualise a task about 50-80% and will get stuck on the other 20-50%. An excellent junior dev can be given a task and independently complete it - the code may not be perfect or up to a middle-senior coding quality, but they can get the job done.
The bad junior developers are the ones who need their hands held at every step of the way and never seem to improve or improve at such a snails pace that it is taking effective resources away from the team (i.e. senior devs - 1 or more) to explain the task repeatedly.
At this point, you need to raise that up to your line manager and have a serious discussion about whether you and your line manager think it is worth the investment to keep teaching this person while making said line manager aware of the problems (and make this based with facts that both you and the line manager can clearly observe and/or have observed).
For the others, you should go from a path of having to explain fundamental concepts (mostly because you both missed out on the weird edge cases of the task at hand) to in months being able to leave said juniors to the task and have them mostly complete it without any help from senior devs. And seeing that progress is why mentoring & code reviews is great - seeing that personal development in real time is an incredibly rewarding feeling.
The point is just differentiating your behavior between what you call a “bad” or a “good” junior.
And from experience the difference is whether they want to learn (regardless of their skill!!) or not (i.e are they passionate or it’s just a job?).
Passionate seniors get frustrated when they try to teach bad juniors, but there is no point on doing that, the problem was just that the senior was not involved in the hiring process…
Completely understand the frustration here. Mistakes happen, even competent people sincerely trying to do a good job can overlook things, etc. But if it’s a pattern of just copying and pasting code without really even trying to understand what it does, that’s a big problem that needs to be addressed. And frankly they should feel embarrassed if it happens more than once or twice.
OTOH, delivering criticism in a way that winds up productive for all involved is difficult at best, and the outcome depends on the junior as much as it does the senior. What good is being right if it ultimately just alienates you from your team? Tough situation for sure, and one of the many reasons it’s so important to hire carefully (which is itself a whole huge can of worms too!).
Can you simply ask them to walk through their submission line by line with you, explaining what it’s doing? If you’ve never asked that before it might come across as a strange request, but if you phrase it well it’s possible this causes them to notice their poor understanding without you ever seeming to point it out.
This. Code reviews, especially with junior devs, should always be done as a conversation. It’s an opportunity to learn (from both sides), not just a a bunch of “bad implementation. rewrite” thrown in the PR.
Completely agree! It’s SO much easier to lighten the mood and keep things upbeat and productive in an actual conversation vs. just text-based feedback. For example it makes it easy to throw in self-deprecating anecdotes of your own when discussing mistakes / needed changes, which can really help put juniors at ease. It’s just worlds better in >90% of scenarios.
Junior dev here, this is the kind of stuff that is supposed to prompt you to ask questions. Literally one slack message when you see it, and give it a few hours for whenever you have time to see it and respond. I know it’s annoying messaging y’all with stuff but… C’mon you gotta do it sometimes, especially if it’s something you can reasonably predict will come up in review or is a simple question that doesn’t require a lot of time to answer.
Yeah, we had a hard bottleneck for seniors, so they kind of got told to walk on their own as much as they can, but after just two weeks or so, I had to push hard against that, because they would frequently walk into wrong directions and then rectifying that would cost me significantly more time. At one point, I had to review a story three times, because they misunderstood the goal twice.
Similarly, we had a student, who would run off doing things for two weeks, and then suddenly she’d come up to you and tell you that she did this and this and that and now she’s stuck.
And then if the second ‘this’ was an incorrect decision, you have to sit down with her in that exact moment and redo a lot of her work to get everything back on track.
So, yeah, juniors who know when to ask questions are extremely helpful. Otherwise I have to poll them for questions, which takes up time, too.
This is still a good practice to find out who is actually working and who is thinking Zero-effort copy&paste will do.
This is SO true and exactly why code reviews always feel like a beat down (even when they’re not). There’s no visibility into the truly good work that’s already been done.
It’s even worse when you can tell they really tried and still end up with spaghetti. Even mid- to senior developers do this. Rhe more senior they
claim to beare, the more embarrasing when you have to get the stick.Some people try to be so clever with fancy design patterns or bit-tricks, instead of just solving the problem, you now have two problems and a solution to one of them.