Let Them Fail or The Art of Delegating
When I hired my first engineer, I used to go through his code with a sieve and rewrite a major portion of code to better fit my style and “embody my wisdom”. I would then walk him through my changes, and explain how and why it’s better. Contrary to my belief, he did not get any better and the amount of rewrite I am doing didn’t go down. So what went wrong?
The Ego Trip
It took me a while to realize that I am the problem. Instead of nudging the engineer in the right direction, it became a show of superiority. I am just flaunting I am better than you and you should learn from me. The second part of that is me not wanting to let go. I built this beautiful garden and I want it to stay exactly the same. However, this is extremely detrimental to employee morale and growth.
The “Learn-by-Watching” Fallacy
The second issue is that no one really learns by watching. They learn by doing. By not letting him make and fix the mistakes himself, I robbed him of the opportunity to learn. Mistakes are after all the corner stone of growth and enlightenment.
For example, why do I use version control diligently now? I once wrote a script that deleted itself with no way to recover. Why do I commit and push often? I once lost my code because I mistakenly discarded 3 days' worth of local changes. Why do I convert one page at a time to react instead of one small component at a time? The small component ended up leaking memory and crashed the page.
Most of my learnings came from making mistakes. By denying my engineers the chance to make mistakes, I am stunting their own growth.
The New Workflow
I decided to change things up a little. The new approach is simple. The engineer submits a pull request. If it's a small change, I quickly look for anything glaringly wrong and push it to production. If it's long, I just pull it on my machine, run it, do a simple sanity check on the UI, and push it to production.
If this causes a bug, I will forward the bug to the engineer to fix. Sometimes, I will fix it if it's time-sensitive, and if I do, I will forward the fix to the engineer for review.
This part caused a bug. This part needs these considerations. Bugs happen, so don't worry about them. Just be more thorough with your testing next time.
Finally, I don’t penalize them for the bugs. We all make mistakes and as long as we are not repeating the same mistakes all is well.
At the end of the day, I hired these engineers believing in their promise, it’s high time I trust them to do their job.
The End Result?
My senior engineer not only codes like a beast but also single-handedly contributed the most to V2. My junior engineer has even pointed out a couple of mistakes I've made or issues I've overlooked. I am now free to work on other features, knowing that I don't have to keep looking over my shoulders. It feels good not to be the only expert on my codebase.
Life's hard. Let's not make it harder by micromanaging.