During my early career, I was often the most skilled, or most experienced tech guy in the room. It provided a great sense of self worth, or importance, that naturally felt pretty awesome. But as I learned later in life, that was a bad thing for my career progression.
I started using Internet in the late 1990s - early 2000s, when memes hadn’t been invented yet. Instead, you had chain mails, where friends forwarded funny stuff to each other through email. At that time, a friend of mine enjoyed collecting funny motivational phrases, like “You should walk a mile on another man’s shoes; that way you’ll be a mile away from them and you can keep their shoes,” or “Remember that no matter where you are, you’ll always be there.”. He had set up his email software so that every time he’d send an email his signature would include one of those phrases randomly.
Although those phrases were supposed to be purely about hilariously absurd fun, I was surprised to discover that some of them actually carried an unexpectedly deep wisdom within. Out of them, two really stuck with me over the years. The first one was “It’s better to keep your mouth shut and appear stupid, than open it up and confirm it.” The second one was “The most important thing in life is not to know everything, but to know the phone number of the one who does”.
Have you heard about the Dunning-Kruger effect? It’s a well-documented cognitive bias that makes people who are comparatively less competent in a certain field overestimate their own knowledge or abilities. Conversely, as people get more competent, they become more acutely aware of the things they don’t know or are unable to do on their own.
Young, skilled developers, as I once was myself, fall perfectly in this scenario. This is why you often see those people wasting valuable time reinventing the wheel (as I too did myself). “Nah, we won’t use that boring standard framework. I’ll build one myself, and it’ll be way better – just wait and see. It will only set us back a few months, but it will be worth it.” But it never is. This has made countless startups fail, and is the reason behind the mess the Javascript ecosystem has become in recent years. The thing is, when you’re young and full of confidence, if you don’t have any gray headed people around you to prevent you from failing, the only way you can learn is from your own mistakes.
When I landed my first job in a successful company with a large engineering team, I was no longer the most senior developer in the company. For the first time, I had to work with people who had more experience and better skills than me. It was also the first time I had to go through peer review (as opposed to doing the reviews myself on VCS).
Having other, more skilled developers, challenge my choices, was destabilizing to say the least. At first, I resisted and fought those comments, sometimes hard, unconsciously trying to save face. In reality, the feedback was legitimate. But accepting my work being corrected by someone else was a hard pill to swallow. At the same time, no one seemed to be judging me for not getting my work merged on the first try, they considered it normal.
As time went by, I started becoming more open to those feedbacks, and learning from them. I was surprised to see that although I wasn’t the best developer there, people valued me because I was nice to work with as I was always open to move things forward. Before I knew it, I had started looking forward to that valuable feedback. At one point, I got offered the possibility to work on a new important project, on the condition I would do it under the supervision of the company’s senior architect, on pair programming.
At first I was weary – I had never done that before, and I was afraid of thinking out loud with a more skilled person by my side. What if I’m slow? What if I can’t articulate my thoughts? What will they think of me? I took my chances, and it ended up being one of the most enlightening experiences of my career, from which I learned skills that ended up being decisive to help me land my next job.
I joined a new company as lead developer. The stakes were high, and I had to recruit my own team, almost from the ground up. People who have to hire their own team are often afraid of having very skilled people under their responsibility, for fear of being outperformed by them. Not me. At that point, I insisted on recruiting only the smartest, most skilled candidates I could find. I had understood that, as a leader, my job would not be judged by my engineering skills, but by my ability to have my team performing at top level and deliver. And the best way to do that was not by telling them what to do, but by listening to their professional advice (often better than my own), and arbitrating accordingly.
And whenever my boss asked me something I didn’t know about, I had nothing to fear – I always had the phone number of my teammate who did. I had recruited them for that.