Nobody tells you this when you start.
Your first project is going to be bad. So is your second. Probably your fifth too.
Most people treat this as a problem to fix. Something to push through on the way to the "real" work. But bad projects aren't a phase you survive. They're the mechanism. Ten bad projects, done on purpose, will teach you more than one good project you spent six months protecting.
The single-project trap
Here's the pattern. You pick an idea. You decide it's going to be the one. Your portfolio piece. The thing that proves you can actually build.
So you slow down. You research the "correct" architecture before writing a line. You refactor the same feature three times because it doesn't feel clean enough. Six months in, you're still not done, and the thing hasn't taught you nearly as much as it should have, because you spent most of that time protecting it instead of testing it against reality.
One project can only teach you one project's worth of lessons, and it teaches them slowly, because you never let it actually break.
Quantity beats quality, and there's a reason it's not a coincidence
There's an old story from the book Art & Fear, about a ceramics teacher who split his class in two. One half would be graded purely on how many pounds of pots they turned in. The other half needed to hand in just one pot, but it had to be perfect.
When grading day came, the best pots in the room all came from the quantity group. While they were busy making pot after pot and learning from what went wrong each time, the quality group had spent the semester theorizing about the perfect pot and had little to show for it beyond some dead clay.
Web development works the same way. You don't learn to structure an app by reading about structure. You learn it by structuring ten small apps badly and noticing, around project six, that you're making the same mistake again.
What "bad on purpose" actually means
This isn't an excuse to write sloppy code and call it a strategy. Bad on purpose means something specific: you accept, going in, that the project won't be good, and you build it anyway instead of waiting until you know enough to do it right.
That's an important distinction, and it comes from actual research on how people learn, not just from folk wisdom about ceramics.
There's a concept in learning science called productive failure. The idea, studied by Manu Kapur and others, is that people who struggle to solve a problem before they're taught the "correct" way end up learning more than people who get the correct way handed to them first. In one study of pharmacy students, the group that struggled first didn't do any better on the immediate test. But a week later, when asked to apply what they'd learned to a new, related problem, they clearly outperformed the group that had been taught directly from the start.
The struggle isn't a detour on the way to learning. It's what makes the learning stick.
There's a caveat worth taking seriously here. The research is clear that this only works when the struggle is short, bounded, and followed by some kind of reflection or correction. Flailing at a project for six months with no plan and no follow-up isn't productive failure. It's just being stuck. The value comes from the loop: attempt, fail, notice why, move to the next attempt. Not from the failure alone.
Ten reps, not one masterpiece
This is also just how skill works, structurally. There's an old model of skill acquisition from researchers Stuart and Hubert Dreyfus, first built from studying Air Force pilots, that lays out how people move from novice to competent to expert. At the novice stage, you don't have any real context to draw on. You're just following rules with no sense of when they apply and when they don't. That only changes with repeated exposure to real, messy situations, not with more preparation before the first situation.
You can't think your way into that kind of context. You have to rack up the reps.
Ten small, bad projects give you ten separate collisions with reality. Project one teaches you that your local setup lies to you about what will work in production. Project three teaches you that the feature you were proudest of is the one nobody touches. Project seven teaches you that the bug you assumed was in your code was actually in a library you didn't read closely enough. None of that shows up in a tutorial. It only shows up when something you built actually breaks in front of you.
What each bad project is actually for
If you're going to do this on purpose, give each one a job.
Project one just needs to exist. Something small, ugly, deployed. A page, a button, a tool that does one dumb thing. The goal is only to go from nothing to something live, because that path has more friction than people expect the first time.
Project two through four are where you start breaking things on purpose. Rebuild a layout you like without looking at the source. Remove a piece of a working app and see what falls over. Ship something with a bug still in it and watch how it fails.
Project five through seven are where patterns start to repeat. You'll notice you're making the same structural mistake for the third time. That's not a sign you're bad at this. That's the first real signal that you're starting to see your own habits, which is the whole point.
Project eight through ten are where you start adding constraints on purpose. One hour only. No frameworks. No AI. Rebuild something that already exists from scratch. Constraints force you to solve problems instead of copying solutions, and copying solutions is the easiest way to finish a project without learning anything from it.
The part people skip
None of this works if you never look back at what you built.
A bad project you never revisit is just a bad project. A bad project you glance back at in a month, wincing at a decision you made, is the thing that actually teaches you something. That wince is the whole mechanism. It means you now know something you didn't know when you wrote that code, and the only way to know it was to write the bad version first.
So don't aim for one great project. Aim for ten bad ones you're willing to look at again later. The tenth one will still have problems. But it will have different problems than the first one, and that difference is what learning actually looks like.
Did you learn something good today as a developer?
Then show some love.
© Muhammad Usman
Don’t forget to subscribe to Developer’s Journey to show your support.
Top comments (0)