Encountered some code I wrote a year ago and was disgusted. It’s good, I’m still improving. But does make me wonder how I can ever train the junior coders with a straight face. So many little details they might pick up from me that they maybe shouldn’t.
@cbowdon Imagine what I'd think looking at code I wrote in 1995--that is still being used at my old company. :)
No worries when it comes to mentoring. It's less about what you know than it is about genuinely wanting to help them, and your experience in problem resolution is really what they're after, not just coding specifics.
Mentoring is probably my favorite part of this job--best part is keeping track of your "project" people as they develop their careers.
@cbowdon You're not alone in this, brother
@cbowdon Tell them just that. It helps for them to realize that at no point will they become an infallible, all-knowing code machine.
You (and them) will make mistakes. They should pay attention, judge if your advice applies, question, call you out if they think you make a mistake.
@ricardojmendez @sajith @DragonIV I think you guys have all hit the nail on the head here. Next week I’ll show them some code I’m not proud of (anymore) and we can talk about why.
This aside, training people is very rewarding. 🙂
@ricardojmendez This reminds me - in the Checklist Manifesto, the author gives examples of where nurses in surgical teams reduced accidents when empowered to call out the surgeon for skipping steps. They used a checklist to support this. We still have some manual processes that would benefit from something like that.
@cbowdon A junior on my team was concerned this week about how much he hates his code, how far he feels he still has to go. Being open about that never fully going away helps.
I told him that I hate going back to code I wrote six months or a year ago, because I know chances are I’ll find something that will irk me.
They need to know that moment you stop finding fault in your old code, it’s because you stopped learning.
@cbowdon My approach is to tell them that no one is infallible. That you may be the Senior Developer/Code Monkey/whatever but you still make mistakes and are always learning (which you should be).
Give them the opportunity to learn from you but also to point out if they think they can do something in a better or more efficient way and explain why. It makes for a more relaxed, cooperative, open team and - in my experience - better code overall.