Introduction
A few years ago, I had a clean GitHub profile, dozens of bookmarked tutorials, and big dreams of becoming a “solid engineer.”
What I didn’t have?
Shipped projects. Production bugs. Real feedback.
I kept telling myself I was “preparing.”
The truth was uncomfortable:
Dreams don’t work unless you do — and in software engineering, doing means writing imperfect code, breaking things, and showing up consistently.
This article is about what finally clicked for me — and why this mindset matters more than any framework you’re learning right now.
The Backstory (Why This Matters)
Most developers I meet aren’t lazy.
They’re:
Over-preparing
Afraid of building the wrong thing
Waiting to feel ready
I was the same.
I believed:
“Once I finish this course, I’ll start building”
“Once I understand everything, I’ll apply for jobs”
“Once I’m confident, I’ll share my work”
That moment never came.
What changed my trajectory wasn’t motivation.
It was action without confidence.
The Core Idea
“Dreams don’t work unless you do” sounds like a motivational quote.
For developers, it’s actually a system design principle for your career.
In practice, it means:
Learning happens after implementation, not before
Clarity comes from feedback, not thinking
Confidence is a side effect of repetition
You don’t become a better developer by planning to code.
You become one by shipping → breaking → fixing → repeating.
Implementation: What “Doing the Work” Looked Like for Me
- Building Before Feeling Ready
I stopped asking:
“Am I ready to build this?”
And started asking:
“What’s the smallest broken version I can ship?”
That meant:
Ugly UI
Hardcoded values
Missing edge cases
But it also meant momentum.
- Treating Side Projects Like Production
I gave my side projects real rules:
Proper README
Clear problem statement
Deployed somewhere (even if imperfect)
That shift alone taught me more than months of tutorials.
- Learning Through Bugs (Not Courses)
One production bug taught me more than five blog posts.
Here’s a retry function I once wrote without thinking deeply about failures:
export async function retry(
fn: () => Promise,
retries = 3
): Promise {
try {
return await fn();
} catch (error) {
if (retries <= 0) throw error;
return retry(fn, retries - 1);
}
}
Looks simple.
In production, it raised real questions:
Should retries use exponential backoff?
Which errors should retry?
When does retrying actually make things worse?
👉 Doing the work exposed the gaps.
What Went Wrong (Lessons Learned)
I made plenty of mistakes:
Built projects nobody needed
Over-engineered early features
Ignored fundamentals while chasing trends
But every mistake had a hidden benefit:
👉 It created context.
Without context, advice doesn’t stick.
Best Practices I’d Share With Any Developer
Consistency beats intensity
30 minutes daily > 10 hours once a month
Build in public (even imperfectly)
Feedback accelerates growth
Finish small things
Completion builds confidence
Treat learning as iterative
Learn → Build → Break → Fix → Repeat
Common Pitfalls
Tutorial hoarding
Waiting for confidence before starting
Comparing your chapter 1 to someone else’s chapter 20
Optimizing tools instead of outcomes
If this feels personal — it was for me too.
Community Discussion
I’d love to hear from you:
What’s one project you planned but never shipped?
What finally helped you move from learning to doing?
What’s holding you back right now?
👇 Drop your thoughts in the comments — this is a shared journey.
FAQ
Is motivation overrated?
Yes. Systems and habits outperform motivation every time.
What if I don’t know what to build?
Build something boring. Real problems teach real skills.
Does this apply to senior developers too?
Absolutely. The tools change, but execution still matters.
Final Thoughts
Dreams are important.
They give direction.
But in software engineering, execution is the multiplier.
You don’t need more inspiration.
You need:
A pull request
A deployed app
A broken feature you fixed yourself
Because in the end —
Dreams don’t work unless you do.
Top comments (0)