The single most important part of your job as a lead developer, the one where you can most directly be a force multiplier for your team, is by being an effective mentor.

Mentoring Is Not Teaching

Being a mentor is not the same as being a teacher; in fact, being a teacher may be detrimental to your career.

A teacher and a student draw math diagrams on a clear board.
Photo by Science in HD / Unsplash

A teacher's job is to make sure their pupils understand the subject at hand;. teaching requires skill at both the task being taught and in communication. The problem is that teaching requires considerable time and effort both in the teaching of the subject and in confirming whether or not the pupils have understood the lesson, and we are often better served spending said time and effort on other tasks. Professional programmers generally do not have time to both do their job effectively and be a competent teacher to someone else.

But we can be mentors. Mentoring is a very different beast from teaching.

Mentors:

  • Are not expected to teach new material, but rather show their mentees how to learn it for themselves. Mentors demonstrate how to learn, not what to learn.
  • Provide guidance, not instruction. A good mentor is available for questions, listens to their mentees, and provides direction to the best of their ability.
  • Assumes their mentee will get the work done. Unlike a teacher, who must check their pupils' work to make sure they understand a given lesson, a mentor does not check work except to provide guidance on things like best practices.

These are all traits of a good mentor, and they all touch on what, in my opinion, is the single most important skill for a good mentor to have: to provide useful, insightful feedback, without being mean or too critical.

Giving Good Feedback

Feedback, if it is useful, is the primary way we learn how to do our jobs. The problem, as I see it, is that most developers in lead positions simply don't know how to give feedback, because the rest of the job makes it difficult.

Two puffins perch on a lush, green mountainside. One is in the middle of making a sound.
Dude, we need to catch fish. Lizards are cool and all, but... Photo by Wynand van Poortvliet / Unsplash

A lot of developers have a particular mindset, one in which most things are binary. The code either works or it doesn't work, and there is no in-between. The test either passes, or it doesn't. The button is either clickable, or it isn't. This is a great thing to have when dealing with code! But often we don't stop there.

As time goes on, suddenly the mindset expands to things that aren't really binary. The requirements are either understandable, or they aren't. The other person is either wrong, or right. More pertinently, the code is either wrong or right, no in-between. We lose all sense of nuance, all ability to see small distinctions.

That nuance, and the understanding that comes with it, is critical to have when giving good feedback. Poor feedback is things like "this is wrong, now fix it."

Good feedback is:

  • Specific enough to be actionable. Describe what is wrong, why it is wrong, and (potentially) suggest ways it can be fixed.
  • About the code, not the person. As reviewers, we are criticizing the work and not the person doing it. We must be careful to say things like "this is wrong, here's a way you could fix it" and not "you are wrong".
  • Timely. If a person requests feedback from you, do it immediately, or as soon as you are able. Feedback that takes forever to get is much less useful.
  • Part of a larger conversation. As leads, we are not dictators; we do not get to say "this way is the only way to do X." We should invite honest conversation about why a certain part of the code is incorrect and how it can be improved. Feedback should be a part in a longer conversation about how to make our work better, more robust.
  • Balanced between criticism and praise. We should point out the good parts and praise our teammate for them, in addition to identifying what can be improved.

Most of the work of being a mentor comes when providing feedback. Practice with the tips above in mind, and you'll have this skill down in no time.

End of a Series

This concluded our "leading teams" mini-series. Thanks for reading!

I'm taking ideas for the next few issues of The Catch Block. Got something you want to see discussed in this space? Let me know by emailing me at exceptionnotfound1 at gmail dot com. Looking forward to hearing from you!

Previews and Announcements

  • Announcing .NET 5.0 RC 2 (Richard Lander) - The release of .NET 5 is getting closer!
  • Game Development with .NET (Abdullah Hamed) - I really want to learn how to do this but it seems like it would take SO MUCH effort. Maybe it isn't as complicated as I think it is?

Quality Reads

Catch Up with the Previous Issue!

The Catch Block #29 - Delegate!
Delegation is an art. Here’s a few tips to get better at it.
Exception Not FoundMatthew Jones

Thanks for reading, and we'll see you next week!