Early in my career, I managed to land a great job that would allow me to work on a bunch of interesting features, with amazing people, while getting hands-on skills that I could use at other companies, and also paying a good salary: It was the whole package!

After so many attempts at landing a good job like this, I wanted to do a great job to show them that they had made the right decision in hiring me. And that almost cost me the job!

The story goes like this. In one of my first assignments, I needed to write a Perl script for a specific feature. My manager and I discussed the requirements, and we agreed on the best approach for solving our problem. Once this was sorted out, I started coding.

It’s probably worth stopping here for a few minutes to set some relevant context. This story is from about fifteen years ago, and a lot has changed since then. Long procedural scripting was still very common, and even though the code was being split into functions, it was mostly spaghetti code. Automated testing was unheard of at the company yet, so yeah, all testing was done manually. Keeping this in mind, let’s continue with the story.

After a couple of days, I managed to finish my script, ticking every box in the requirements, just as my manager and I had discussed. There was only one problem though: there was a nasty bug hidden somewhere, and the script refused to run. No matter what I did or where I looked, I just could not find this elusive bug.

And this is when I made one of the worst mistakes of my career (but not the last). I needed to prove that I was a great programmer, so “of course” I could not acknowledge that I could not find this bug, so I did not tell anyone, and I did not ask for help.

Instead, I deleted all the code I had written, and I rewrote the whole thing following a totally different approach. This time it took me only one day to complete the new script, as I knew most of the tricky parts. I was a happy engineer, because I finished the assignment all by myself, and it just took me one extra day.

I’m pretty sure we did not do code reviews at the time either, so I just told my manager that I had finished. He stopped what he was doing and sat by me to look at my code, together.

I can still remember how the smile on his face faded as he scrolled down. His joy turned into astonishment at seeing this code he was not expecting. After a few seconds, that felt like hours, he finally asked me, rightfully, why I had not done what we had agreed.

My manager was visibly upset, and he didn’t need to use words to express his disappointment. I am thankful that what came out of his mouth was a lesson I would never forget.

Teams don’t need superheroes that can do everything by themselves. Teams need team players that can help others, and that are humble enough to ask for help when they need it. That is not just a nice attitude, but it’s also the most practical thing to do. if I had asked for help, we might have caught the bug in twenty minutes or less: this means that if we had invested forty minutes of combined time, we could have saved the whole extra day that I spent working on the new version.

If you’re just starting your career, please be a team player, and know that you are allowed to make mistakes, and everyone expects that you will (but that you will learn from them). And if you’re seasoned, please give new developers the space to grow and make mistakes, let them know they can approach you if they have issues, and help them find the right timing for when to stop trying by themselves and reach out for help.

I am not proud of this mistake, but I find it’s important to share stories like this to show that, after all, there will always be a time when we’ll make bad decisions and that we should take them as opportunities to grow.

Cheers!
José Miguel

Share if you find this content useful.
Follow me on LinkedIn to be notified of new articles.