Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
try to figure out if they're just people with a more steady pace, or if they have specific tasks that take them a long time.
try to figure out if there's tasks they are more efficient at, and assign more work like that if possible.
ask them how they think about the situation. but emphasize the good work, don't demotivate by the situation as problematic (unless they're so slow, it actually _is_ a severe problem)
zlice421889dput them in a corp position where everyone is an asshole =p
Fast-Nop3999889dPutting more time pressure on the junior, reminding that the probation period is there for easy firing, not being available for support, yelling at the junior (ideally over totally unrelated things), and giving unclear instructions in the first place because that's how real dev life is.
One common misstep is waiting too long to ask for help or report that you're stuck somewhere. Ideal search reflex:
1. Internal docs
2. Online docs
3. Ask colleague for help/ report to team
The first 2 steps should never exceed 2 hours together. I admit to going down the rabbit hole and losing track of time periodically
Frankistan44789didgaf personally, it's entirely normal for a junior.
What would set me off is slowness from a senior who is single with no kids. Oh man this breed really makes my blood boil.
It's fine for people to have struggles but in some situations you just need to be communicative even if it's annoying to open up to your coworkers.
If your kids won't leave you alone and you don't tell anyone: they'll get pissed off at you.
If you tell only your boss: you will get a treatment of favor which will piss everyone even more.
If you tell everyone: You'll get understanding and support from everyone, it may start a discussion within the company about increasing parents pay so they can afford help.
There is never anything good about not communicating.
Oktokolo830789dWhen you are happy with the quality, that probably is the cause of the low speed. You can convince some people to sacrifice quality for speed. Obviously, you will then get lower quality output faster - enabling you to spend more time on maintenance.
Some people are generally slower than others. Can't do much about that.
I would strongly advice in just ignoring the speed and continueing training the junior. Some get faster with more experience, some don't.
As the junior is working hard, you might also have to somehow prevent a burnout. Some devs degrade permanently when you let them burn out.
Speed is subjective.
How do you measure / what is your comparison?
The big trap is usually to take yourself as the measurement without looking at how the intern spends their time.
First months are rough...
Crost420589dTo be more clear. 2 years experience. Basic crud.
webketje168789d@tosensei in that case the task
should be divided (testing, R&D, analysis). I meant on a development task.
@Crost "Normal" and "it's just" can still hide a lot of the complexity (eg deployment process, auth, UI specificities, constraints of the working environment). Is there at least another senior/ medior working alongside him? That can do wonders, though it depends on the pedagogic ability and will of the other a bit. Personally I love to help/ teach others and am grateful for that look on their face when they're like "this is amazing" or "I get it"
Root8250988dFigure out why they’re slow. If it’s something you can address, they’ll be happier and more productive, and you’ll be happier too.
Maybe the codebase has a difficult learning curve.
Maybe they don’t know when to ask for help.
Maybe it’s overhead like spinup time — that’s my big one. I must wait 2+ minutes to launch a local server, or run a spec, or test new code changes even with hot reload. Totally kills my zone.
Maybe it’s constantly changing directions or priorities.
Maybe it’s research on docs, APIs, etc. Maybe it’s bad docs.
Maybe it’s meetings and people talking to them constantly. Or maybe they need longer recovery periods after context switches (like meetings). This is me.
Maybe they don’t get along with a few people and that saps their motivation. Personality conflicts are a thing, professional (and therefore hidden) or not. This doesn’t mean they’re touchy or a bad person. It might mean they don’t fit anywhere at the company, but they probably fit somewhere.
Maybe it’s undue amounts of process and ceremony.
Maybe it’s the hours — some people work best in the mornings, some at night. Some work best for long periods of time and need longer downtime to recover — 4x 10+ hour days instead of 5x8, etc. This is me.
Maybe their machine is slow. Maybe they much prefer a different OS or other tools.
Maybe they’re a perfectionist and are making the features extra solid and foolproof. If so, don’t chastise them for it! Instead, assign them to projects where that is important. This is me.
Maybe they’re bored and/or burned out. Are their tasks interesting to them? A good match for their skills? Too difficult? Too tedious?
Maybe it’s medical. Maybe they’re depressed.
Talk to them, figure out their pain points, and find a way to improve those. Not everyone can work in the same way and be as effective. But if you figure out their needs and help with them, they can excel.
(Or maybe they just suck.)
KDSBest46288dGo to him and say, we value speed more than quality. RUN FASTER! FASTERRRRRR!
Do pair programming and shout every 20 seconds or so "FASTER!!!".
Or coach him and give him time to properly learn his craft. He will become faster by repetition?