I could probably achieve 297% more in 6 years as a programmer if I knew these 6 essential things when I started my coding career.

Time for a MEGA thread

Coding Is Not About The Coding

What do you think programming is about?

Writing code?

Writing good code?

No.

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'll need to refactor it, and it'll take an additional 30 hours.

Because other engineers will work with your messy code when you release it.

And after refactoring, you'll 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 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)

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.

Then I went further and implemented the 52+17 system and my productivity levels spiked by 200%. https://twitter.com/nickbulljs/status/1303037682294173699

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 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 vertically-align an element with CSS.

Big thanks to those developers, like @dan_abramov for the article below, they cured my imposter syndrome and showed me that it is okay not to know something. https://overreacted.io/things-i-dont-know-as-of-2018/

Programming Is Not Hard 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 deliberate requires focused attention and is conducted with the specific goal of improving performance.

After I applied a deliberate practice, I began to notice how fast I'm progressing with learning JavaScript. My knowledge started to stick for a long time, not just for 5 minutes after tutorials.

And I created the end goal, why I am learning JavaScript, and understand what I need to learn, and what I don't.

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



@jsthatworks

So here is what you need to perform deliberate practice on your own:

1. Teacher: provides practice activities designed to help you improve performance.

2. Perform at maximum effort: constantly being taken out of your comfort zone.

3. Well defined and specific goals: not just “overall improvement.”

4. To be in focus: give your full attention, no distractions.

5. Do conscious actions: no autopilot.

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

It’s impossible.

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.

For example

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 build an interactive website, we choose JavaScript.

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.

If you find this thread helpful give it a and RT to share!

Also, every week I send out a "3–2–1" newsletter with 3 tech news, 2 articles, and 1 piece of advice for you.

Join the latest frontend news https://nickbulljs.com/