Progress vs Perfection

Mentoring is a tough task. Not only is it time consuming and often require you to step outside of your regular work to assist and develop another person, but it is also means that you are essentially playing a vital part in this person’s future development. Something which should never be taken lightly. Often though in our over-zealousness to make sure we are mentoring the person to become the even better versions of ourselves we can end up hindering their development, but not allowing them to develop and learn their lessons over time.

When we learnt to walk as babies, we didn’t get there without falling many many times and although our parents probably didn't like watching us fall, it’s the only way we were ever going to get it right. And the reason for that is learning is all about self-confidence. The more confident we are, the more we learn. And self-confidence is bred by doing it ourselves and not not just through what others might teach us. The same applies to our learning and development as adults and in our careers too. If you want a person to learn and develop, you need to create an environment for them to flourish and feel good about themselves in. They need to feel like they can walk, fall and get back up again and keep making progress. Focusing on the end goal of walking across the floor rather than the next misstep which might trip them up. If they’re going to be constantly focusing on the areas where they could fall, chances are they will keep falling.

One of the things I have learnt through my years of mentoring others is the need to prioritise progress over perfection. Too often I see people’s personal development hamstrung because the feedback they get is overly critical or there is too much focus on the things they don’t know rather than do know and while there are many good mentors out there doing this right, there are still too many falling short in this area. And in our organizations, we need to be careful that we are not mistaking falling into the latter category and potentially hampering our more junior staff from growing effectively.

So, what do I mean by progress over perfection and how does this apply to an actual mentoring scenario? Well, let’s take coding for instance as that is my area of specialisation. Often when reviewing people’s code it’s easy to become overly pedantic about their lack of optimisation, poor linting or poor test coverage, rather than focusing on the progress made and encouraging them to move forward. We hold up wanting to merge their code because it’s not like we would write it without understanding that it might not need to be and it could be more beneficial for them to at least see their code get submitted, even if it’s not ideal. I’ve seen many people become discouraged when their merge requests sit there for a few days because it hasn’t met the high standards expected of them and becoming frustrated with the process and feeling like they aren’t making a valuable contribution.

And while there is merit to these things that they need to work on, it shouldn’t become the focus of a person’s development and we need to allow a few mistakes here and there to be allowed if it means they will feel more encourage to grow and get better. That doesn’t mean that code quality should be compromised in any way, as tags can still be made to the coding areas that need to changed and improved in the next update, but just that we should approach these learnings as incremental development rather than perfection.

The biggest issue here though is that many people don’t realise they are doing it as there is a fine line between what we should allow and accept versus when to correct. We want people to get it right sooner rather than later, but it’s not always beneficial to their development. Similarly, it opens up the questions of exactly how many issues or development areas we should allow or correct. Tough questions to answer though perhaps something that can be solved by having a minimum acceptance threshold for wok that is differs with the experience of the individual. For experienced developers and tester you want to be rigorous and expect high quality throughout, but for more junior people, you can soften expectations on their work and accept code that is of a lower quality.

Does this mean you launch code into production that is inferior? Of course not, your release exit criteria should be tired to the standards of the senor developer – time must just be provision for the senior person to perhaps help it get there. It sounds convoluted and like double effort, but what it does is actually speed up the learning of the person involved, while simultaneous making them feel more a part of the process. It’s important that you think about this long-term. Do you want a developer who is learning and contributing positively in a few months’ time or one who is getting increasingly frustrated by the small details they might be missing and getting frustrated that their work counts for nothing?

I will add a caveat here that obviously we shouldn't excuse people not learning from their mistakes and as much as we need to give people the chance to learn and shine, we need to hold them accountable when they don't. We just can't hold them accountable until we've actually allowed them to fail and then learn from their failures. Some people expect this from individuals before they've failed - and that's not right.

I’m sure there will be many seasoned professionals out there who could read this and disagree with my approach, but I’ve honestly yet to find any other approach that works effectively. I want people to feel positive and compelled to learn more and to want to get better naturally, rather than forced to get their quickly and to please another person. So, while you want to keep your standards high and ensure you are developing your team to excellence – don’t overburden them to a level they’re not ready for. Give people room to make mistakes and feel accomplishment and you’ll be amazed at what the results can lead to long-term.