Read on Twitter
One of the interesting challenges of mentoring fresh graduates is getting them enthusiastic about the reality that 95% of dev work is maintenance (if you're lucky). Everything's greenfield at uni. I thought I would share some ways that I do this. (thread).
Before I begin, I like to make sure that I've built strong enough rapport with them that I can ascertain what might be a good motivator for them, and they trust me enough to tell me. It takes time. Pair a lot. Be there for them. Make yourself available. Value THEIR time.
Part of valuing their time is making sure they have real valuable tasks to work on. Tasks should be challenging but not require massive amounts of context they won't yet have. Assign via normal sprint work. Those small wins to start off should be useful wins. Pair a LOT.
While pairing, encourage them to drive. Pointedly take the back seat. Be extremely careful not to patronize even by accident. They may be embarrassed by lack of knowledge in some area. Make yourself relatable by being vulnerable with your limits too. Show them this is normal.
That's the key point. Your mentee is vulnerable. So are you, and you remember how hard it is for them. Make your recognition of this obvious by actions, it doesn't need to be a blunt announcement. Let 'em know everyone makes minor mistakes, design errors, big fuckups, and it's OK
... because this business is all about iteration. Evolution. We're not NASA, we're making web sites. But we do have tools to make sure we do a good job (monitoring, feature flags, logging, perf analysis, forensic techniques, CI/CD etc etc). Plant seeds of awareness of these.
Respect their intelligence and curiosity when planting these seeds. For god's sake don't just lecture and/or mansplain. Be selective about what's relevant or important in the moment. Use pairing to create those moments, the seeds will help them when they're not pairing.
Be subtle when ascertaining what stuff they do and don't know yet, while pairing. I try not to be blunt with "do you know X?" as an endless stream of that and having to say no can be demoralizing. Instead say stuff like "ever had a chance to play with X?" or "let's pair up on X".
If nothing else, try really hard to build that trust, respect their time, knowledge and intelligence, create an environment for self-directed growth but give complete confidence that support (not just from you, don't be a gatekeeper) is available. You're a peer not a manager.
This is all I can write about on half a cup of coffee. I would love to hear from my peers (at all levels of experience) what their thoughts in this area are.
Oh, I lied. Back to my original point. This was about making sure new developers can get interested in the reality that ALL CODE IS LEGACY CODE. Once you've built enough of that rapport as described above.
They're going to be challenged by swimming in all that code that has come before. There are going to be really interesting challenges. There are going to be the results of difficult decisions, compromises, things unfinished, things redundant and human errors made by predecessors.
New people's super power is being able to spot things which make no sense. Point this out, use it together Undocumented, verbose, unclear, complicated or "clever" code. Convey the value of clarity and valuing one's successors' time and mental effort.
Convey the likelihood of predecessors' good intentions and smarts. We have the chance to make things better as we work on it. To evolve it. To embrace the challenge of redesigning the plane while it's flying. To make our users' experience more pleasant.
The code is fun, the building is fun, but in the end the purpose is to make things better for your users and to empower your peers to make that happen. You can accelerate bunches of other people a lot faster than you can accelerate yourself. This is a senior engineer's duty.
