Your Side Project Never Launches, and It Is Not Because You Are Lazy

Last Saturday night I was cleaning out my hard drive and found a folder called side. I created it in 2024. Inside were six projects, each one holding nothing but a README. My mouse hovered there and I sat still for a few seconds.

If you are also a developer trying to build a second income, there is probably a folder like this on your disk too. This piece is about where that "it never gets off the ground" actually jams, and why it is mostly not a discipline problem.

First, what those six projects look like.

Every one of them stops at line three of the README, with nothing under "## Tech stack". Creating the repo, naming it, listing a roadmap: I do all that fast, ten minutes each. And then nothing follows.

I remember it on the weekend and eagerly spin up a new one. Monday I am back at work. I get home tired: "I will rest today, do it tomorrow." A week passes, next weekend I remember again, decide the old one had a sloppy opening, and just create another new one. This loop ran for about a year.

The time was there. On those evenings I could scroll my phone until past 1am; the three or four hours in the middle were plenty to write two hundred lines of code. The skill was not missing either: it is literally what I do at work all day.

The jam is very specific: the five minutes between "open the editor" and "actually type the first line". Every time, it is in those five minutes that I talk myself back onto the couch. Too late, do it tomorrow. Environment is not set up, skip it for now. This version of the tech stack needs more thought. The excuse is different every time. The outcome is the same every time.

Later I looked into what is actually happening in those five minutes, and dug up something from 1949.

That year the psychologist Donald Hebb proposed a mechanism in a book: if two neurons repeatedly fire together, the connection between them strengthens. In 1992 someone boiled it down to a catchy line, "neurons that fire together wire together". In plain terms: the more often you walk a sequence of actions, the cheaper it gets, and the less it needs your attention.

To put it in terms we know: this is like the branch predictor in a CPU. For an if branch you have taken the same way ten thousand times, the processor assumes you will go that way again and fetches and computes the following instructions ahead of time. Actually go the other way and the pipeline has to flush and start over, stalling for a dozen-plus cycles.

"Get home, collapse, scroll, sleep": I have walked that path several hundred times over the past year and more. Now, the moment it hits 8pm, that path is the default branch. Predicted, prefetched, executed automatically.

You think you are deciding whether to work tonight. Actually that decision was made for you before you were conscious of it.

A contrast makes it clear. During the day you get handed a dev task, and you do not need resolve to start: you sit down and do it. Because that path is worn in too, also a default branch, just pointed at working. The evening one points at resting. Neither takes effort. What takes effort is jumping from one to the other.

So launching a new project is hard because every single time you are forcing that prediction to fail; the project own complexity is the small part. What you are fighting is not laziness, it is a path that is already worn in.

One boundary worth stating: not every "cannot get moving" has this cause. Sometimes the direction genuinely is not thought through and you are uneasy about it. In that case stopping is the right call; do not force yourself with this framing.

Once you know it is this mechanism, at least the direction is clear: resolving to do better does not work.

Resolve is a one-off firing; it does not change connection strength. The only thing that changes strength is repetition, actually walking the new path enough times.

What I do now is shrink the starting action. Tonight task is one sentence: open that project, type for twenty minutes, close it when time is up. No two-hour goal, no target to hit. Twenty minutes is a quantity you can still fool yourself into on an evening when you do not want to move, and once you have sat down and started typing, you usually run over.

The cost has to be owned too: accepting the twenty-minute version means accepting that progress is slow. For the first couple of weeks you will not get the "I am building something" rush, just a tally sheet that moves. If you want the thrill of one big push in an evening, this method will not give you that.

And do not break the streak. Skip a day and the new path connection strength slides back a notch; the accumulation is wasted. I stuck a piece of paper next to my monitor and mark tally strokes for how many consecutive days I have opened the editor. Today is day fourteen. One of the six empty projects finally has a README that runs past the first screen.

Tonight when the time comes, I will open the oldest one in side and type for a full twenty minutes. No goal, no roadmap, just twenty minutes. This is day fifteen.