How to Start a Coding Project (Without Freezing Up)

You know the feeling. You have an idea for a project—an app, a tool, a game, whatever—you open your editor, you stare at a blank file, and then somehow 45 minutes later you're watching YouTube instead of coding. Not because you're lazy. Because starting is genuinely hard and nobody teaches you how to do it.

That exact problem is what Jonas Birch, who goes by "dr Jonas Birch" on YouTube, is trying to solve in a recent video. His pitch: a three-step method he calls data type driven design that works for any language, any project size, and requires "little to no planning." I watched it, I immediately opened a side project I'd been stalling on for two weeks, and I tried it for about 30 minutes. Let me tell you what happened.

The Method (It's Simpler Than It Sounds)

Birch lays it out in three steps, and I want to be real with you: the name "data type driven design" sounds scarier than it is. If you've heard of domain-driven design—a broader software architecture approach that was codified in a well-known 2003 book and has since become a whole community practice—this shares some DNA with that. And if you've used TypeScript or taken any statically typed language seriously, you've probably half-done this already without knowing it had a name.

But Birch isn't writing for senior architects. His framing is approachable: just start by thinking about your data.

Step one: Define your data types. Before you write a single function, ask yourself how your program is going to store information. What are the things in your program? A banking app has accounts, transactions, and money. A to-do app has tasks, lists, and users. Write those out as data structures—classes, types, structs, whatever your language uses. Birch says the goal here is that "the whole program" should be describable just by reading your type definitions. That's the real move: you're not planning an architecture, you're just naming the nouns.

Step two: Write utility functions. Here's where it gets interesting. Once you've defined your types, you'll almost automatically start noticing the gaps. Birch uses a great example: if you're building that banking app and you store money as an integer of cents (so $1.50 becomes 150), you immediately realize you need a function that converts 150 back into a displayable "$1.50." And probably a reverse function for when users input dollar amounts. He says: "as you create the data types, you'll automatically start thinking about these things." You're not forcing it—the types are surfacing the functions for you.

Step three: Connect the dots. At this point, Birch says, you have "a lot of dots on a board" and you just need the lines between them. Write the functions that make your data types interact. How does an Account use a Money type? What happens when a Transaction modifies an Account balance? You're not inventing logic from scratch—you're following the shape that your types already created. His description of this stage is worth quoting directly: "all you need to do is take one of these at a time and link them together by writing the rest of the functions. And that is it. That's the whole program."

I Tried It. Here's What I Found.

Okay so the project I'd been stalling on: a small CLI tool that scrapes pricing data from a couple of sites I track for a buying guide series. I'd been frozen because I kept trying to think through the whole scraping pipeline before writing anything. Classic overthinking.

I followed step one. What are the things in this program? A Product (name, URL, price history). A PriceSnapshot (timestamp, value, source). A Report (a collection of snapshots, a date range). I wrote those out as Python dataclasses in maybe 10 minutes. Nothing fancy.

Then step two happened almost by itself. I immediately thought: I need a function that formats a price for display. I need something that compares two snapshots and tells me if a price dropped. I need a way to serialize a Report to JSON. None of that required me to think about the scraping architecture yet—it was just filling in the obvious helpers that the data shapes demanded.

By the time I hit step three, I had maybe 15 or 20 lines of actual skeleton code and I knew exactly what I still needed to build. The blank-file paralysis was just... gone. I can't say the project built itself, but I can say that starting it stopped feeling like climbing a wall.

The Real Value Here (And Where I Have Questions)

What Birch is actually selling isn't a technical methodology—it's an anti-paralysis strategy wrapped in a technical methodology. The insight is psychological: your brain freezes on big abstract problems but moves fine on small concrete ones. "How do I build this whole app?" is paralyzing. "What are the nouns in my app?" is not. Step one is easy enough that you can always do it, and doing it pulls you into momentum that carries you through the harder parts.

That's actually a pattern that shows up in professional software development under much more intimidating names. Type-driven development is a real thing practiced in communities around statically typed languages—the idea that designing your types first constrains the problem space in useful ways. Birch isn't claiming to have invented something brand new; he's distilled a pattern that experienced developers often use intuitively and given it a clear, teachable structure.

So: does it work on weird projects? I genuinely don't know. If you're building something event-driven, heavily procedural, or where the data model isn't obvious upfront—a generative art tool, say, or a game with emergent behavior—I'm less sure that "figure out your nouns first" gets you as cleanly unstuck. Birch acknowledges that for big projects you might cycle through the steps multiple times per module, which feels honest, but it also means the "one go" simplicity has some asterisks on it depending on what you're building.

And yes, you will probably refactor your data types after you've written a bunch of utility functions and realized you modeled something wrong. That's not a flaw in the method—that's just programming—but it's worth knowing that step one isn't permanent, it's a starting point. You're sketching, not architecting.

Is This Worth Your Time?

Straight answer: yes, and it costs you almost nothing to find out. The video is under 8 minutes. The method requires zero new tools, zero new languages, zero investment beyond 20 minutes of trying it on whatever you're already building. If it works for you the way it worked for me on that scraper project, you've just solved one of the most consistent friction points in learning to code.

If you have a friend who keeps saying they "want to build something" but never gets past the idea stage, this is the video I'd send them. Not because it answers every question about software design—it doesn't, and Birch doesn't pretend otherwise—but because the hardest part of any project is the part where the file is blank and you don't know where to put your hands.

"You can always do the first step, defining the data types. No matter what project, no matter how much you have planned, you can do it. And then it just grows from there."

That's the whole argument. It's a small promise, not a grand one. And in my experience, small promises you can actually keep beat grand ones every time.

---

— Tyler Nakamura, Consumer Tech & Gadgets Correspondent