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.
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.