A: Welcome to management, it's a sneaky thing sometimes
B: My advice is pretty simple - whenever possible, don't fix their mistakes for them or tackle the cleanup on something they've made a mess of. It's tempting - you'll spot the issues coming way before they do and you'll have a better fix in mind fast, but they need to be able to touch the fire and feel the burn... It builds confidence for them when they do fix it, it shows you have made them responsible and they own something, and in the long term it builds team trust (use your 15 years of judgement here about what can be allowed to fail for a bit without breaking the bank).
C: There are some junior devs (not always labeled junior) who manage to keep their jobs by routinely going through their contacts and getting them to "teach them the code" which really translates into "doing their work". Politely stop doing this - a 5 minute conversation (or less) and a link to some relevant code is enough before you pat them on the back and tell them to go work on it themselves again.
> a 5 minute conversation (or less) and a link to some relevant code is enough before you pat them on the back and tell them to go work on it themselves again.
so, you never work with issues with colleagues for > 5 minutes at a time? Is that normal? I understand you shouldn't do their work for them, but surely there's times when a longer coworking session is appropriate
Pairing is fine, long sessions (1 to 3 hours) can be genuinely helpful and good experiences.
They are less helpful if your colleague requires that session to get anything done. If their answer to the question "Show me what you've got so far?" is "ummmmm" or otherwise blank... time for the link and a pat on the back.
If it's "I tried this and it didn't work" or "I have this thing on this branch but I'm stuck" or "This is close but I can't figure out this error" - sure, dig in.
B: My advice is pretty simple - whenever possible, don't fix their mistakes for them or tackle the cleanup on something they've made a mess of. It's tempting - you'll spot the issues coming way before they do and you'll have a better fix in mind fast, but they need to be able to touch the fire and feel the burn... It builds confidence for them when they do fix it, it shows you have made them responsible and they own something, and in the long term it builds team trust (use your 15 years of judgement here about what can be allowed to fail for a bit without breaking the bank).
C: There are some junior devs (not always labeled junior) who manage to keep their jobs by routinely going through their contacts and getting them to "teach them the code" which really translates into "doing their work". Politely stop doing this - a 5 minute conversation (or less) and a link to some relevant code is enough before you pat them on the back and tell them to go work on it themselves again.