Most software applications today are just too big for a single person to handle, therefore projects are built by teams of people. Often these teams have junior members, and therefore it's essential to help these junior members learn and grow - i.e. they need to be mentored. Now sometimes it's an "emergency project", and there simply isn't time to mentor someone, but this is a dead-end approach. The successful, on-going projects are constantly mentoring the junior guys so that they have an every-growing pool of capable developers.
The beauty is that if you've got an eager dev, and you spend a few hours training them on a task or technique, then they can handle that technique going forward. This frees you up from that type of task, and lets you focus on higher level problems. In one sense, if you're to "move up", you need to ensure that the current class of problems you have are handled. You have a few options here:
Work lots of overtime, so that you're handling both your old problems, and the new one's you'll encounter at the new position. This approach isn't sustainable.
Make those problems go away, usually by solving them properly and simplifying the maintenance with automation. This is a good temporary solution, but ultimately the automation breaks, or the process itself needs to be modified, and then you get blindsided at the most inconvenient time.
Mentor someone else to take over your automated process. This is ideal. It involved other people on the team, and encourages that newly-mentored developer to understand and improve the process you original set in motion.
I personally find a good way to mentor people (and be mentored myself) is to emphasize the skills that they like and are practical to them, initially work with them one on one, then let them toy around with it on their own, then connect them with another person who can answer questions (your "backup"), while always keeping your door open to questions.
I've seen many senior devs, with good intentions, declare that they're "too busy to mentor people right now". Sometimes this is because the company only rewards immediate coded features, as opposed to long-term team growth, and a dev isn't jumping to do what they won't get rewarded for. Other times it is because the dev just doesn't know about mentoring - no one mentored them and they "toughed it out" the "old fashioned way". Still, other times it's because the senior dev is, to put it politely, being short-sited. As the saying goes: "Give a man a fish, feed him for a day. Teach a man to fish, feed him for life."
If you spend 4 hours ("but that's half a day!") mentoring a junior dev on how to fix security hacking issues, or use the new validation framework, and they then do those tasks for the next year, which saves you even 2 hours a week - you've just been spared 100 hours. So, there are many benefits to mentoring:
An hour of mentoring could easily give you 20 hours back - now that's a good return.
There's a great feeling in helping others.
Perhaps someday that junior dev will learn a technology that's new to you, and they'll return the favor.
Teaching something to some else truly forces you to understand it yourself.
It helps build a closer team.
I think because of all this, the best companies will always be actively mentoring each other.
No comments:
Post a Comment