fear of starting a new project

Introduction

So in the chapter 7 of this book, I read about how it's common for devleopers to get anxious when trying to start a new project. The blank editor can be intimidating, and the fear of making mistakes can be paralyzing. But the key is to overcome this fear and take the first step towards building something great. In this post, I'll share some tips from the book on how to overcome the fear of starting a new project and get into the flow of coding.

This is Part 2 of the series — Part 1, A Pragmatic Mindset, covers the book's foundational chapter on philosophy and critical thinking.

Problem

By fear of starting, I mean the hassle to write code, getting stuck in the blank editor, and not knowing where to start. This is a common problem among developers, but we should think about it's origin,the impostor syndrome, the fear of failure, and the fear of making mistakes. So Matin, what exactly do you mean? I mean most of us(or at least me) have this fear, that comes when we think we are not competent enough for this project, so you get it? we sacrifice the joy, the learning, and the experience of building something new just because we are afraid of making mistakes.

Solution

So how do we overcome this fear? The book suggests this strategy that can help you get started on a new project without feeling overwhelmed.

Prototype:

Instead of wanting to aim for the perfect solution, get a sticky note and put it on your monitor, write "I'm prototyping" on it. This will remind you that it's not necessary to get everything right the first time. You can just write code to throw it away later. This will help you get started without the pressure of perfection.

For example, say you need to add search to an app. Don't start by designing the "correct" architecture — indexing strategy, caching layer, ranking. Just hardcode a WHERE title LIKE '%query%' against the existing table and wire it to the UI. It'll be slow and wrong in a dozen ways, but you'll have something on screen in twenty minutes instead of a blank editor after two hours of "design." Once it's ugly-but-working, you actually know what the real requirements are, because you've hit them.

Do the easy 80% first:

The book's observation is that the last 20% of a feature — the edge cases, the error handling, the polish — usually takes as long as the first 80% combined. If you start by trying to handle every edge case up front, you never get past the blank editor, because you're trying to solve the hardest version of the problem before you've solved the easy version at all. Write the code for the case that obviously works first. The edge cases become much easier to reason about once you have a working skeleton to hang them on.

Ask "What's the next tiny step?" instead of "How do I finish this?":

"Build a new project" is not a task, it's a category of tasks, and your brain correctly refuses to start on something that vague. The fix isn't motivation, it's decomposition: the next concrete action is almost never "start the project," it's something boring and small like "create the repo" or "write one failing test." You can always do the next tiny step. You often can't hold "the whole project" in your head long enough to start.

Rubber duck the plan before you touch the keyboard:

If the blank editor is intimidating specifically because you don't know where to start, it usually means the plan is still fuzzy, not that you lack discipline. Explain out loud (to a person, a duck, or just a comment block) what the project needs to do, in order. The moment you get stuck explaining a step, that's the actual source of the anxiety — and now it's a concrete unknown you can go research, instead of a vague dread.

Conclusion

None of these techniques remove the fear entirely — they just make it small enough to start moving despite it. The blank editor stops being the enemy once you stop expecting the first version to be the right one. Prototype badly, ship the easy 80%, take the next tiny step, and say the plan out loud before you type it.

If you haven't read Part 1 yet, A Pragmatic Mindset covers the book's foundational chapter on agency and critical thinking — the mindset underneath these techniques.

❓ FAQ

How do you overcome the fear of starting a new coding project?

Stop aiming for the right solution first: build a rough, throwaway prototype so you have something on screen instead of a blank editor, then handle the easy 80% of the feature before touching edge cases. When "start the project" feels too big to begin, break it down into a next tiny step you can actually do right now, like creating the repo or writing one failing test.

Why does the blank editor feel so intimidating?

Usually because the plan is still fuzzy, not because you lack discipline or skill. Explaining the project out loud, step by step, surfaces exactly which part you can't explain yet — that's the real unknown driving the anxiety, and now it's something concrete you can go research instead of a vague dread.