How to think like a developer

When you try to build things, do you stare at a JavaScript file and feel unsure about how to begin?

If this happens to you, you’re probably afraid of failing — you’re so scared that you rather someone give you answers than face the possibility of getting it “wrong”.

Many people who get stuck here call this the coder’s block — it’s similar to writer’s block, where a writer doesn’t know what to write.

But the good news is, there’s no such thing as a coder’s block — it’s a myth.

You can overcome any coder’s block easily once you know what to do.

Breaking out of coder’s block

To break out of coder’s block, you need to accept that failure is part and parcel of building things — you’ll get stuck, you’ll write shitty code, and you may feel like you’ll never be able to make that thing.

Once you accept this, you can put aside your fear of failure and focus on these four steps:

1. Break down the problem into small problems
2. Find solutions to your small problems
3. Assemble the solutions
4. Refactor and improve

Step 1: Break down the problem into smaller problems

Answer this question: How do you put an elephant into the fridge?

If you’ve heard of this question before, you know what the modal answer is:

1. Open the fridge
2. Put the elephant in
3. Close the fridge

Problem solved.

Now this answer is a big joke because you still don’t know how to actually put an elephant in the fridge…

But even though it’s a joke, many people approach web development the same way — they throw out a big question and expect to get an easy answer (like put the elephant in and close the fridge).

In reality, you need to be able to break the problem down into many smaller problems. And you do this by asking questions…

For the elephant example, here are some questions that pop up:

1. What fridge are we talking about?
2. What kind of elephant are we talking about?
3. If the elephant is too huge to fit into the fridge, what do you do?
4. Where do you find the elephant in the first place?
5. How do you transport the elephant to your fridge?

Don’t worry about the correctness or size of the questions you think up — just write them all down and break down them into smaller questions. If you can’t break your smaller questions down further, that’s fine.

Step 2: Find solutions to your small problems

Now pick one of your small problems — any one of them — and start trying to solve them. Be as detailed as possible. If you can code, code.

For example:

1. What fridge? – The fridge that sits in your kitchen
2. What kind of elephant? – The african bush elephant
3. What if the elephant is too big? – Get a shrink gun (🔫) to shrink the elephant 😎
4. Where do you find the elephant? – Africa
5. How do you transport the elephant? – Put it in your bag after you’ve shrunk it, then take a plane back home.

At this point, you may realize that some problems remain too big to be solved. When this happens, you break that problem down into even smaller problems.

In the example above, answers #3 and #4 are still too vague. So, let’s break it down further and get some answers.

1. Where do you get the shrink gun? – Borrow from the mad scientist next door.
2. Where in Africa can you find the elephant? – Addo Elephant Park in South Africa.

Once you have the answers to all your small problems, you’ve effectively solved the big problem. What’s left is to piece them together so your solution works.

Step 3: Assemble the solutions

For the elephant example, you can probably follow along with the steps now:

1. Get a shrink gun from the scientist next door
2. Fly to South Africa
3. Travel to Addo Elephant Park
4. Find an elephant in the park
5. Shoot the elephant with the shrink gun
6. Put the shrunk elephant in your bag
7. Travel back to the airport
8. Fly back to your country
9. Travel to your house
10. Put the elephant in your fridge

Problem solved. Sounds logical, yeah?

It’s important to get practice by breaking bigger problems down into smaller ones — once you get to a small enough problem, you’ll naturally come to an answer. It might not be the best solution, but at least it works!

And when you have one answer, you’ll gain the confidence to work out the rest of the problems you had… and after a while, you would have solved the big problem without even noticing.

When you have a solution that works, you can improve the solution if you want to — this is where we go to step 4.

Step 4. Refactor and improve

You probably have spaghetti code the first time you piece your solution together — it’s messy, it’s ugly, and it goes all over the place.

That’s ok.

When you can spare some time, you can clean up the clutter and refactor your solution — so you improve your code to a point where it doesn’t feel hacky and messy.

We’ll go through the refactoring process together later in the course so you’ll understand when you should refactor and why.

Wrapping up

Coder’s block is a myth.

If you don’t worry about the quality of your code, you won’t get blocked.

Everyone starts somewhere so your best action right now is to start — start by breaking problems down and writing shitty code to solve those problems.

And don’t worry about improving your code for now because we’ll do it together in a later chapter.

With this, you’re ready to begin coding.