Hi, I am Nick. I wrote my first line of code 9 years ago.
Like everyone else who started programming, the only thing I cared about was writing code.
For me coding was some kind of magic, you type something on the keyboard and the computer instantly shows you the result of your work on the screen.
But...
This magic started to come to the end when I met the real world and got my first job as a full-stack developer 6 years ago.
During these years I have faced the good, the bad, and the ugly side of a programming job. And I've learned 4 essential things about coding and having a coding career that could have easily helped me achieve 297% more over these years if I knew them when I started.
Coding Is Not About the Coding
What do you think programming is about?
Writing code?
Writing good code?
No.
That's just a part of the whole.
Programming is not about coding, programming is about solving problems with coding.
End customers don’t care what technologies, languages, frameworks, or methodologies you use. They care only about one thing: whether your product solves their problem or not.
That’s why relatively few people care what technologies Google search uses under the hood. As long as people can find relevant information with it, they will use it.
This is the number one thing I wish I knew when I started programming.
I would spend less time writing the “best code” and more time solving the customer’s problems in the quickest and best way I could.
Don’t write code just to write code. Solve your customer’s problems with the code.
Communication Skills Are More Important than Coding Skills
When I just started my career as a programmer, my lack of social skills was not my main problem. But when I moved higher, to a middle, senior, and then leadership position, my weak soft skills became my Achilles heel.
When you work on a product with a group of different people (engineers, designers, managers, and so on), communication is the only thing that makes you a “team” and helps you effectively develop the product.
A lack of good communication or social skills does the opposite. It increases your product development time and decreases overall productivity.
Here is a real situation you might face:
The leadership team tells your product manager that they want to create a new product feature and put it in the next product release. It’s not urgent, they just want to release it as soon as possible (as always).
The product manager calls you on Zoom, tells you what you need to build, and asks, “How much time do you need to build it?”
You do a rough calculation and tell them, “I need 20 hours.”
The Product Manager is not satisfied with your answer. They want to release it as soon as possible and show the management that they can deliver results fast (this is a very common situation).
So they ask you, “Can you build it in 10 hours? We really need this feature in the next product release!”
And you know that you can if you cut the corners (no tests, messy code) but then you will need to refactor it, and it will take an additional 30 hours. Because other engineers will work with your messy code when you release it. And after refactoring, you will need to integrate their code with yours.
So here’s what will happen next. If you have bad social skills, you will not convince the Product Manager that you actually need 20 hours to build this feature.
Why?
Product Managers often have good social skills, from my experience. So if you can’t convince them that refactoring later is worse than spending 20 hours right now, they will easily argue with you and convince you that “refactoring later is okay.”
And then the whole team will lose that additional 30 hours while you're doing this refactoring (I'm not counting the time it might take to fix unpredictable bugs, either).
But if you have good communication skills you will more easily be able to convince you PM of the opposite.
So improve your social skills as well as coding skills (send memes in the group chats on Slack or something :) ).
And remember one simple truth:
People work with people, not machines.
Programming Is a Lot Easier if You Know How to Learn
When I started to learn JavaScript, it was hard. Because I learned the wrong way.
Read a lot of theory without the practice, no routine, no end goal. Chaos.
I thought it was normal to learn like this. Until I discovered deliberate practice.
It’s a purposeful and systematic type of practice (learning).
The difference between normal practice and deliberate is that to engage in deliberate practice, you need to really focus. And you have to have the specific goal of getting better and improving your performance.
After I applied a deliberate practice, I began to notice how fast I was progressing with learning JavaScript. My knowledge started to stick for a long time, not just for 5 minutes after tutorials. I created my end goal, articulated why I was learning JavaScript, and understood what I needed to learn, and what I didn't.
So here is what you need to perform deliberate practice on your own:
- Find a teacher: provides practice activities designed to help you improve performance.
- Try to perform at maximum effort: constantly being taken out of your comfort zone.
- Have well-defined and specific goals: not just “overall improvement.”
- Make sure you focus: give your full attention, no distractions.
- Complete deliberate actions: no autopilot.
- Respond to feedback right away and modify your strategy.
When you start learning a new language, technology, framework, or whatever, stick to these rules to get big results as quickly as possible.
10X Engineers Don’t Exist
At the beginning of my career, I thought that a great programmer is a person who knows tons of programming languages, frameworks, and methodologies.
I was wrong.
Such a mindset only gave birth to my impostor syndrome. I thought that I didn't deserve my current position, my salary, that I was a “fraud.”
So I started to follow every popular developer on Twitter, read every technical publication, and pour over thousands of developer blogs just to convince myself that I deserved what I had and to feel closer to the title “great developer.”
This was not a healthy behavior.
But it helped me to discover that a lot of people I followed (who I thought were 10X engineers) actually didn’t know a lot of things.
They might have known how to do some complex tasks that required deep knowledge in a couple of fields, but at the same time they didn't know some basic things. Like they knew how to design highly scalable database architectures, but they didn't know how vertical-align an element with CSS.
Big thanks to those developers, like Dan Abramov (creator of Redux) for creating resources like this article. They helped cure my imposter syndrome and showed me that it is okay not to know something.
In the end...
If you like this article, share it with your friends and follow me on Twitter.
Quick note: I’m creating a JavaScript course where I’m using deliberate practice to combine modern and practical JavaScript theory with a lot of real-world practice to teach you how to become a skilled JavaScript developer with knowledge of modern language features. Join here.
Also, every week I send out a "3–2–1" newsletter with 3 tech news, 2 articles, and 1 piece of advice for you.