The best piece of advice I ever got from a CTO was to stop coding and open an almost blank PR.
Around 10 years ago I was working at a company called The Book of Everyone. It was a cool product that would create a personalised book for someone for special occasions like birthdays, anniversaries, etc. As the gift giver, you would enter the person’s date of birth in a form and it would create a book all about events that happened in the year they were born etc. They were wanting to introduce a new feature that would schedule a daily job that would query the database for all the book subjects whose birthday was two weeks away but the gift giver had never bought the book and send an email to the gifter to remind them how special the book was and what a good gift it would be.
I was really excited to build this feature as it felt like something that could have a big impact in the sales of the product. Because I loved the idea so much, I wanted my implementation to be perfect. I wanted to appear one day on my horse with my shiny feature and save the day, which was such a mistake.
While I wouldn’t encourage handing in a lackluster piece of work, making something perfect is so time consuming and debilitating. I was working on this feature for weeks. I was developing it only on my laptop without pushing anything to GitHub and I didn’t want to share it with anyone until it was perfect. Until I was 100% happy with everything and nobody could add a comment or suggest a change. I know I’m not alone in doing this as I’ve seen it time and time again. I’m not sure why we do this. I guess we want the recognition of our peers, to look like we’re the smartest one in the room (every developers downfall) and make ourselves look like the hero of the day.
Each morning in standup I would give an update on my progess, and it would always sound something like “yeah, I’m still working on it. I’m getting closer but it’s not quite there yet”, or “I’m almost done, I should be done in the next few days”. After working on this feature for almost a month with no visible progress, the CTO (and now one of my really good friend’s) Zi Makki came to me and broke the paralysis. He encouraged me to open a PR with one simple commit and put a description of what the PR was going to be before pushing any of the changes that I had been working on. His idea was to get rid of that fear that I was clearly feeling. When you’ve been working on a feature for so long, you get into this spiral where you don’t want to push what you’ve been working on because you almost don’t want people to think “wow, it’s taken you 3 weeks to do THIS” and then decimate all of your changes. I’m not sure why we really think that though, because who does that? Who would comment that on someone else’s PR?
One benefit that he helped me see of doing these smaller incremental changes as I went, is that it allows your team mates to look at your progress and make comments as you go. It’s way less expensive to rewrite or refactor a feature at the beginning of it’s lifespan than at the end. It also helps avoid knowledge silos and encourages cooperation. If I code a feature in a cave like a gremlin and then present it to everyone when it’s fully finished, it’s hard for them to understand the approach and provide meaningful feedback. Especially if the PR I end up submitting is 100 files long. But long PRs is for another blog post.
So after talking with Zi, I created an empty PR and then pushed everything, it was messy, clunky but it got me out of the paralysis.
Zi completely changed my mindset and the way I work. I no longer code in a cave, and share my progress with my team mates (both with Ellie but also our clients) as much as possible. Being a knight in shining armour isn’t necessary in software development and causes way more problems that it solves. So I really owe my career to Zi in a way. The development team at The Book of Everyone was really the best and most productive one that I’ve been a part of. There was so much love at that company and we produced a lot of cool stuff at a quick pace as a result. Rather than favouring the old-school IT hierarchy method, we really embraced horizontality and shared our knowledge so that everyone had the same understanding and anyone can pick up any piece of work.
Zi really engrained into me the “do it anyway” philosophy and to ship less more often and check that it works. I owe a lot of my career to him to be honest, so a huge shout out to him. Without him, there probably wouldn’t be a BEAMOps at all. So thank you, Zi, love you 💜.
If the hero complex is something you see in your team then let us know. That’s what we love to help teams with, and try to be the Zi Makki in their lives.
📬 Email us at info@beamops.co.uk
📅 Or book a free 30-minute call, and we can see if we can help!