His colleagues hate him for how good he is 😎 Learn his 3 secrets to being a successful developer!

(This article is mainly about software development and debugging, but the non-listicle part is probably true for all walks of life)

His colleagues hate him, but you still want to learn his secret? Quite the conundrum, isn’t it? If you don’t want the context, scroll to the title text with the numbers and emojis in it for your easy to consume readymade answers list — I mean, you have already skimmed past this part, haven’t you?

Clickbaity titles are back in season, but you have to really be over-doing it not to seem try-hard — another weird oxymoron, but it’s true.

So, what are his secrets, and why his colleagues hate him?

They hate him because he knows all the answers, and they don’t. We all know that guy (may as well be a girl, but for the sake of example, let’s go with a guy). He’s just faster, smarter, and on the point about seemingly all topics.

What the heck is his secret?

Well, nothing. There’s no secret to knowledge, lest the secret is that there’s no secret. There was no secret to elementary school maths, you just do it until it starts to be second nature. Same thing with engineering, coding, music, and probably all things learning. The part that people fail to admit, is that learning some things are hard, and it takes time, and these are such trivial statements, that no-one would follow them.

So they hate him, for actually doing that you already know, but you just can’t follow.

Here’s a high-quality photo, so my story gets better impressions. Source: https://knowyourmeme.com/memes/rtfm

Learning needs to be hard because that’s the nature of knowledge (and your brain). You need to bend your brain repeatedly until it’s shaped like the brain that has the new knowledge. And here’s one more important thing: pay attention to what you’re doing often because you’ll become good at doing those. If you skim through listicles to find the answers quickly, you’ll not read Node.js’ error output, unless it starts with a blinking red: “3 things you should fix in your Node.js code right now!” — and that’s exactly something you shouldn’t do.

If this all seemed too trivial, you’ll be shocked how trivial the list is:

1. Read the error messages 🚨

You’d be surprised how often the answer is right in front of your eyes. Often the first answer you should get is this: It’s right in front of you, dummy, just read it, make sense of it — but your colleagues are too nice/afraid to confront you with your inability to read what’s right in front of your eyes.

DOs: Do read the error messages. Do learn where your usual tools output the valuable part. Do try to follow suggestions from the error messages.

DONTs: Don’t skim through, looking for emojis, and ordered lists of “things to fix”. Don’t paste the error message to someone, without reading it yourself first.

2. Understand what you’re working with 📚

Also known as RTFM. Documentation and manuals are around for a reason. They try to detail how to use the tools. Yes, documentation can be poor, it can be incomplete, outdated, or just, in general, a pain to read, but it’s ultimately the key to working with the systems/libs you have at hand. If the source code is also available: great! Give that a read too if things still don’t work.

DOs: Do practise reading manuals and understanding tools. Do investigate inconsistent/incorrect documentation, and do report it to the authors. Do

DONTs: Don’t start “how to” issues on a Github repo, when your answer is in the docs. Don’t skim through contextual information about your tools, in some cases, the context and the conceptual knowledge is more important than the controlling interface.

3. Take your time ⏳

… and if it wasn’t obvious what I’m trying to say in general: Don’t rush your work and your learning. Invest time in what is important, and make this your habit: read docs, read error messages, understand what your tools do, and what they’re for. Convenience is your enemy when it comes to learning.

Your boss will probably hurry you (or you might think they’re pressuring you on OUTPUT) but imagine being in their shoes: they see nothing about your work, only the outputs. So why wouldn’t you focus on the output by KNOWING what you do, and producing value, not only code?

DOs: Do push back on a rushed implementation. Do understand how you got to an output.

DONTs: Don’t think your time is for typing out code. Don’t stay at a place where you don’t learn anything new — the world is full of new opportunities.

The key takeaway: you probably know these things already, but they seem too trivial to be useful. They are, but that’s it. There’s no secret, just banal platitudes.

Here’s a sad-happy fact: if you’re a junior engineer now, and you are climbing the ranks to be a proper senior, you have about 5–6 years ahead of you (don’t let the inflation of titles confuse you: your classmate, Jeremiah isn’t a senior after working his 4th 5-month job). 5–6 years is about 10000 hours. That’s a lot of hours. More important than money, start investing your time in the right things now.

As a closing statement: The “guy” in the story is not me, I don’t claim to be perfect or to be doing everything according to these “golden rules”, but at least I’m aware, and I’m constantly trying to swerve the right way.