The following post is reproduced from Orientation — Code School’s internal documentation system. I wrote it many years ago when we first decided to build out the team that took care of codeschool.com. I was an early member of that team and many things we had built were created under very different circumstances by a rotating cast of developers who rarely stuck around for more than a few weeks or months. This could be very disorienting for someone joining to work on the largest codebase in the company by far, which is why our approach to onboarding was so important.
Whenever someone joins our team and I have the chance to talk to them at the very beginning, the first thing I make sure to have with them is the Immunity Talk.
It shouldn’t be this way, but in many companies the first few months after you join are generally the ones during which it seems like your opinion matters the least. You haven’t built relationships with people yet. You don’t know who’s receptive to criticism and comments yet. You feel like you have everything to prove and so whenever you encounter something odd — something that doesn’t quite make sense to you — you tend to brush it aside.
A lot of people do this, and it makes me really sad.
Whenever you’re stuck working on something for too long it’s common to ask for a “fresh pair of eyes”. You want someone with a different perspective or a different set of assumptions to look at what you’ve been struggling with. It often works amazingly well because after working on the same thing for a while, lots of things become part of the noise. You don’t notice typos. You don’t realize that there’s a glaring mistake or a bad assumption. People with fresh eyes, however, can often spot what the problem is instantly.
This logic is so obvious to so many people that we’ve even invented a way to simulate it: Rubber Duck Debugging. That’s when you pretend to talk to a Rubber Duck on your desk and explain every step of the problem you’re facing to them. Just like the fresh pair of eyes, it’s often within the first few steps that you realize you’ve made a fundamental mistake that can easily be corrected. It avoids you the embarassment of asking for help and having someone immediately realize that you forgot a single semicolon in the most obvious spot.
Somehow though, this logic is never applied to new hires or recent additions to a team. We don’t realize the value of their fresh eyes on this thing we’ve been working on for so long. In our context at Code School, it could be some code that we forgot about and is causing obvious performance issues. Or it could be a policy that we’ve established years ago and never really reconsidered, until someone asks: “Why do we do this?”. And we realize that no one has a clue.
So instead of thinking of yourself or your new teammates as people with not enough knowledge to hold a valuable opinion, I challenge you to think of all the things that could be fixed by a few pairs of fresh eyes and some well-needed critical thinking.