DEV Community

Discussion on: Should I allow my teammates to make mistakes, so that they can learn from them?

Collapse
 
tiguchi profile image
Thomas Werner

Gotcha! My team works home office, so I don't deal with that situation at the moment. So basically the only point in time when I notice problems while my team mates are working on something is when I'm on a pair programming call with them. That's more of a collaborative setting though where both sides can make mistakes and it's OK and definitely not too much to correct each other.

As for an office setting, I agree, you shouldn't feel obligated to intervene while your devs are working on something and be able to step back and delegate as much as possible. That could come across as micro-managing and would probably backfire in the long term.

I guess it's really about finding some balance between trust / letting go of control and ensuring that your product is in a good state and allows for easy continuous maintenance. It's also a balance between the individual needs of the devs, their personal growth, and the "greater good" of having a reliable product that meets the set quality standards.

The quality and system health aspects can be covered to some extent by being diligent about writing unit tests, using linters and by enforcing those automatically when committing something. A range of beginner mistakes can be automatically caught by that, which allow the dev to correct themselves and also learn from it (e.g. "why did my modification make that test fail?").

But unit tests and linters don't catch situations where something could be done in a different, improved way. That requires the experience of someone more senior.

And yes here it can get problematic when personal opinion and preference of a more senior dev plays a role. That might cloud their judgement when it comes to letting some minor issue slip.

To address that, I think it's also important for the team to set the expectations right from start and come up with a set of code style requirements and coding conventions that define how the code is supposed to be written. After all, software development is a team effort, and when going inside the code base it shouldn't be obvious who wrote a particular method or function just by looking at the code style.

By setting those standards you can basically avoid any discussions and arguments about code style related issues and focus on more pressing things. Some of that can be also covered and enforced by linters.

When it comes to improvements that have nothing to do with code style and personal taste, but really with something that could affect the performance or readability of a feature (e.g. redundant "if-else-if" checks that can be reduced and simplified), then I would say: go ahead and explain and correct. I think it wouldn't be fair towards the junior dev to withhold that wisdom and let them try to figure that out. It can take many years to get there.

It's probably more of a matter of "how" to do that, so it doesn't come across as condescending or overbearing.

But if the right expectations are set from the start (e.g. have guidelines in place the whole team agrees on), and there is some setup within the team where (several) more experienced developers are assigned as mentors to more junior developers, then this could work as a learning experience, all while making sure that mistakes are caught and corrected.

In that regard I have to say that I was actually yearning for a mentor when I started my software development journey, and I wouldn't have minded being corrected while I was working on something. When I was younger I had a longer internship at a big software development company. They did assign me a mentor. But he never had time for me, so I was mostly on my own there, which wasn't great either, and there was little I took away from that experience.