Yesterday I had lunch with a newly promoted lead and realized I have opinions on mentoring engineers. Here they are.
The goal of mentoring is to build engineers that you can trust to take on bigger and bigger tasks, projects, and even products. It might feel like a constant level of support, but the results get bigger over time.
This is how you scale a team superlinearly.
Without training, every new member adds less and less. With training, you have a chance. Every mentee will help you train future additions to the team.
My approach
- Engineering is a tacit skill. To learn you have to do. You need to get your hands dirty and build a bunch. Reading and talking about it solidifies the learnings.
- Work together. The best way to learn tacit skills is to work alongside an expert. Pairing shows you those little things the expert wouldn't even think to mention because they're so ingrained.
- Explain your reasoning. When you give feedback, explain how you got there. What factors did you consider? Why this feedback in this situation? What spidey senses are tingling? This later helps your mentee make the same decision without consulting you.
- If you don't know, say so. Always say when you don't know the answer. Go on a journey together to figure it out. Seeing how you navigate ambiguity is a great skill to learn.
- Warn but don't block. Your job is to point out the rakes. But they need to step on some rakes to internalize the lessons. Make sure it's not dangerous and let them get smacked.
- They own the mess. Your mentee should clean up their messes. Don't jump in to rescue the situation. Point out the bug or the bad code, help them go faster, sit and pair through a fire, but they own the work. It's the best way to learn about the rakes.
- Make them king (or queen). A piece of code under your full control is a wonderful thing. Nothing teaches you that software engineering is programming over time as much as dealing with your own stupid decisions 5 months later when it's time to add new functionality.
- You advise, they decide. They'll do things differently than you would. It's fine. Make your suggestions, explain how you'd do it and why, then let them do their thing. Reserve blocking demands for big problems (data consistency, security, money bugs, unrecoverable prod issues)
- Use just-in-time teaching. Focus on the problem at hand and teach by example. Your philosophical treatise on the one true way to build software will wash right off. Your "ah I see you got smacked by a rake, here's why" will stick forever.
- Don't overload with feedback. You get 1 or 2 core lessons per code review. Let the small things slide. This saves time and makes your feedback feel helpful. Don't beat them over the head for trying :)
- Discuss architecture early. The best time to discuss architecture is before the work starts. That 10min system design exercise before they start coding is your highest point of leverage.
As a lead you build software through others. The better they are, the better your software will be.
Cheers,
~Swizec
Continue reading about My mentoring philosophy
Semantically similar articles hand-picked by GPT-4
- It's like surfing
- How to go from Senior to Lead
- Principles of high output engineering teams
- How to grow as a senior engineer or why I got a new job
- What you can expect from the Senior Mindset Retreat
Learned something new?
Read more Software Engineering Lessons from Production
I write articles with real insight into the career and skills of a modern software engineer. "Raw and honest from the heart!" as one reader described them. Fueled by lessons learned over 20 years of building production code for side-projects, small businesses, and hyper growth startups. Both successful and not.
Subscribe below 👇
Software Engineering Lessons from Production
Join Swizec's Newsletter and get insightful emails 💌 on mindsets, tactics, and technical skills for your career. Real lessons from building production software. No bullshit.
"Man, love your simple writing! Yours is the only newsletter I open and only blog that I give a fuck to read & scroll till the end. And wow always take away lessons with me. Inspiring! And very relatable. 👌"
Have a burning question that you think I can answer? Hit me up on twitter and I'll do my best.
Who am I and who do I help? I'm Swizec Teller and I turn coders into engineers with "Raw and honest from the heart!" writing. No bullshit. Real insights into the career and skills of a modern software engineer.
Want to become a true senior engineer? Take ownership, have autonomy, and be a force multiplier on your team. The Senior Engineer Mindset ebook can help 👉 swizec.com/senior-mindset. These are the shifts in mindset that unlocked my career.
Curious about Serverless and the modern backend? Check out Serverless Handbook, for frontend engineers 👉 ServerlessHandbook.dev
Want to Stop copy pasting D3 examples and create data visualizations of your own? Learn how to build scalable dataviz React components your whole team can understand with React for Data Visualization
Want to get my best emails on JavaScript, React, Serverless, Fullstack Web, or Indie Hacking? Check out swizec.com/collections
Did someone amazing share this letter with you? Wonderful! You can sign up for my weekly letters for software engineers on their path to greatness, here: swizec.com/blog
Want to brush up on your modern JavaScript syntax? Check out my interactive cheatsheet: es6cheatsheet.com
By the way, just in case no one has told you it yet today: I love and appreciate you for who you are ❤️