I was thinking about a loose curriculum the other day for my own mentee and started putting together a list of areas to cover. They’re not all technical but I think they’re all beneficial
This will vary on depending on the person and context but I would initially focus on peripheral skills they may not have much eposure to beforehand.
1 – Version Control
Getting comfortable with a Version Control System like Git (commits, branches, pushes, pulls, merges, revert etc)
2 – Code Reviews
Submitting to and performing code reviews. Important to read other people’s code, learn from their approaches and get feedback on your own code.
3 – Frameworks
4 – Mini project
My mentee already had a project underway from college so we’ve been looking at extending that.
If they don’t have one, get them to have a go at something small that interests them and incorporates all of the above. Could be a simple web-app or whatever.
I’d be looking for all the usual stuff off our “definition of done” checklist: automated tests, clean modular code, secure functionality, good logging, have it deployed somewhere other than the IDE etc. It’s much easier to get a handle on those aspects while the project itself is small and simple.
Often neglected but just as important as technical skills. I’ve read Google are obsessed with a lot of this stuff and have empirical studies to back all its benefits up.
1 – Communication.
This is crucial. Nowadays it’s rare to work alone, it’s all about collaboration via face-to-face, email, chatroom etc.
I did an effective business writing course years ago and I still use its lessons today.
Being able to communicate clearly makes both the recipient and the senders life easier.
Fewer misunderstandings, fewer mistakes, less time wasted on back and forth clarifications. Now multiply that by the number of meetings, emails and documents you do over a career.
Put yourself in the shoes of your recipient when composing your message. How much context do they already have? What gaps do you need to fill in for them?
Be concise and use the simplest language possible.
The responsibility of understanding lies with the sender, not the recipient. If they don’t understand this time, you just need to try a bit harder next time. It takes practise but it’s worth it
2 – Asking Questions.
Being afraid to ask questions doesn’t help anyone, especially when you’re starting out.
Foster an atmosphere where anyone can ask a question no matter how dumb they may think it is. Chances are someone else is wondering too and you’re doing them a favour by asking. Alternatively consider it an oppurtunity for the expert to consolidate their own understanding of the topic. If they can’t explain it, they don’t understand it.
I suppose this applies to mature teams as well as the mentees.
3 – Measure twice, cut once. Don’t rush.
Sprints, Agile, Scrums: they’re all about speed but at an organisational level.
Coding itself should be a careful and thoughtful activity.
When pondering a solution, I’d encourage trying to come up with at least one alternative way of doing it. The first one’s not always the best.
4 – Constructive criticism as a good thing.
At the start criticism can be hard to swallow but it’s ultimately the only way to improve.
Seek out people who are better than you and learn from them. Always look for ways to be more productive.
Eventually you’ll soak up enough knowledge to become a mentor yourself!