Comparison Time

You hear a lot of people giving some form of this piece of advice:

Don't compare yourself to others. Comparing yourself with someone with more experience only leads to disappointment and discouragement. Comparing yourself to someone with less experience leads to a false sense of pride.

I think that this is great advice. But, I think that I can refine it a little to add a bit more value.

Definitely Compare Yourself to Others

"That's a pretty substantial refinement!" you say. To this I say, "Yes. Yes it is. It is also a shameless attention-grabbing subtitle." Let me clarify. I think you should compare the appropriate moment in time of "you" to others. Do you see someone who is super amazing and it seems like they know everything? Are you thinking to yourself, "Oh, man, I can't believe how much stuff they know. I barely know anything in comparison. Therefore, I suck and should just give up."? Take a moment. How many years of experience does that person have? Or — possibly a better metric — how many projects/teams/technologies has this person worked on. In how much depth? How many mentors has this person had? OK, with that information, we can reframe the question to an even comparison.

Picture yourself after that same number of years, projects, technologies, teams, and mentors.

Now, how does this future you compare to this person right now? Does it seem like "future you" could be just as smart/skilled/knowledgeable? That's a good comparison to have.

Example: Grumpy Senior Engineer (15 years with the company)

In our example, let's imagine you recently got hired at software.io, neat, trendy software company. You've been working there for a few months. There's another employee that's been with the company for 15 years! They are grumpy, and that's being polite about it, but they really know their stuff. Based on their skill and their seniority, you generally look up to them. This, combined with their grumpiness makes them kind of intimidating. You're trying to do your best as you work and things are generally good, but every so often, they'll snap or make an off-handed comment about junior developers or explain something using the words simple and obviously a lot. This is discouraging, because it starts to seem like you should know all of this stuff. I mean, this senior engineer does! Maybe there's something wrong with you. You're probably dumb. Maybe this programming thing just isn't for you. You start to keep an eye open for data entry jobs.

Stop. That's enough of that nonsense. Let's practice our scale leveling. This employee has worked at this company for 15 years. Is it possible that, given 15 years, you could get to a point where you know as much as this employee does? Or even more? How much work would you have to put in over that time period for that to be the case? Does that seem reasonable? Easy? Difficult, but doable if you really work? If you answered yes to some of those questions, then stop worrying. You're exactly where you need to be. Or, using this logic, you can figure out that you have actually been just cruising and need to be putting more time/effort into your learning. Less episodes of NBC's hit TV series Parks and Recreation and more side projects. One fewer scroll through InstaTwitFaceSnapBlr and one more coding challenge on Exercism. Any way you look at this, you'll get some valuable insight and hopefully feel more motivated and less… um… de-motivated? Bad? Like 💩.

Example 2: Question Filled Newbie

It goes the other way. Let's say you have a bit more experience. You know your way around a class definition. You're a real hotshot. But there's this intern who is a sophomore in college who never. stops. asking. questions. Questions that any poor fool knows the answer to. Any poor fool, that is, except apparently for this intern. But they are your poor fool and you're supposed to be a mentor to them. Let's apply our scale leveling again. Think of the questions this person is asking. How long have they been with the company? How long have they been programming? It takes a certain amount of time and practice to figure out that most things are Google-able, and it takes even more practice to figure out how to ask the right questions. Think about yourself at that level (I know it's tough). Think about what it was like to learn the very, very basics. Think about learning about functions and the difference between parameters and arguments and why one didn't have to match the other, but sometimes they did because that was the best name for the variable. Think about hearing about each new technology that you were "supposed" to know. For me, I learned Python, but as I started to get into Django (a web framework), I was like, "Oh, crap, now I'm supposed to know HTML, CSS, SQL, and JavaScript." And then there's something called jQuery, which is JavaScript, but it's not. And there's something called JSON, which is also JavaScript, but it's not. And then, and then, and then...

Once you've done this, three things happen.

1. The questions the intern asks stop being so annoying (or maybe, they become less annoying).
2. Feeling superior to them becomes less important (which is good since feelings of superiority are pretty much never useful).
3. You begin to see the questions from their eyes, which helps you pinpoint the most effective answers, shortening the list and duration of each of the questions as you explain things better. This saves both of you time and helps them to feel less like a burden (because — trust me, if they are anything like me — they do).

Conclusion

So, to wrap up, this is very good advice.

Don't compare yourself to others, only to past and future you.

But, I propose that this is possibly even better advice.

Don't compare current you to others. Only compare equivalent versions of you to others and evaluate the work needed to get there (or the work it took to get where you are).

Hopefully this helps. Anything I can do to help keep Codenewbies from giving up is one more person who can use technology to help make the world a better place. Let me know what you think!

Originally posted on assert_not magic?