6 Essential Things I Wish I Knew When I Started Programming
I could probably achieve 300% more in 6 years as a programmer if I knew these things when I started.
Coding Is Not About The Coding
What do you think programming is about?
Writing good code?
It's just a part of the truth.
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 no one cares what technologies Google search is using under the hood. Until people can find relative information with it, they will use it.
It’s the number one thing I wish I knew when I started programming.
I would spend less time writing “best code” and more time solving customer’s problems best.
Don’t write code just to write code, solve customer’s problems with the code.
Communication Skills More Important Than Coding Skills
When I just started my career, lack of social skills was not my main problem. But when I moved higher, to the middle, senior, and 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), communication is the only thing that makes you a “team” and helps you effectively develop the product.
Lack of social skills does the opposite, it decreases the product development time and overall productivity.
Here is the 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 are doing a rough calculation and tell, “I need 20 hours.”
The Product Manager is not satisfied with your answer. He wants to release it as soon as possible and show the management that he can deliver results fast (this is a very common situation).
So he asks you, “Can you build it for 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.
Product Managers often have good social skills, from my experience. So if you can’t convince him that refactoring later is worse than spending 20 hours right now, he will easily argue with you and convince you that “refactoring later is okay.” And the whole team will lose additional 30 hours for this refactoring (I don't count the time to fix unpredictable bugs after).
But if you have good communication skills you will be able to convince him 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.
Regular Breaks Help To Program Better
For 4 years I always feel exhausted after work. Somehow I could productively work only for a couple of hours. After that, I didn't have much energy. Until I learned about the Pomodoro technique.
It’s quite simple. You work for 25 minutes and take a break for 5 minutes.
Your working routine becomes:
8:00-8:25 – Work
8:25-8:30 – Break
8:30-8:55 – Work
8:55-9:00 – Break
I tried it for a week and was surprised at how focused, energetic, and productive I became (the science behind Pomodoro)
Then I went further and implemented the 52+17 system and my productivity levels spiked by 200%.
So take regular breaks if you want to operate at your maximum capabilities.
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 don't deserve my current position, my salary, that I am a “fraud.” So I started to follow every popular developer on Twitter, read every technical news, and thousands of developer blogs just to convince myself that I deserve what I have and to feel more close to the title “great developer.”
This was not a healthy behavior.
But it helped me to discover that a lot of people I followed (I thought were 10X engineers) actually didn’t know a lot of things. They may know how to do some complex things that require a lot of different deep knowledge in a couple of fields and at the same time don’t know some primitive things. Like to know how to design highly scalable database architectures but don’t know how vertical-align an element with CSS.
Big thanks to those developers, like Dan Abramov (creator of Redux) for this article, they cured my imposter syndrome and showed me that it is okay not to know something.
Programming Is Not Hard If You Know How To Learn
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 deliberate requires focused attention and is conducted with the specific goal of improving performance.
So here is what you need to perform deliberate practice on your own:
- Teacher: provides practice activities designed to help you improve performance.
- Perform at maximum effort: constantly being taken out of your comfort zone.
- Well defined and specific goals: not just “overall improvement.”
- To be in focus: give your full attention, no distractions.
- Do conscious actions: no autopilot.
- Instant response to feedback and modifying your strategy.
When you start learning a new language, technology, framework, whatever, stick to these rules to get big results as quickly as possible.
There is no “best programming language”
There is no best "something" in our world. Only best in something.
Let’s take cars. How can we choose the best car in the world? By speed? By safety? By what criteria?
We can only choose the best car in a certain category. Like the safest car. Or the best offroad car.
And if we look deeper, every category solves some problems.
Problem: We have children and we take them to school every day, we want our children to be safe on the way to school.
Solution: Buy the safest car.
Problem: We go camping every weekend, so we need some vehicle that can easily get us to places that are difficult to access.
Solution: Buy the best off-road car.
The same is with programming languages. Some languages and tools are better at solving some problems than others.
If we want to go with ML/AI, we choose Python.
Remember, there is no best programming language, there is the best programming language to ...
So start with a problem first, then pick a language to solve it.
In the end...
If you like this article, share it with your friends and follow me on Twitter.
Also, every week I send out a "3–2–1" newsletter with 3 tech news, 2 articles, and 1 piece of advice for you.