DEV Community: Omkar Gawde

Why I Started Building One Backend Project Every Day (And You Should Too)

Omkar Gawde — Mon, 15 Sep 2025 15:14:48 +0000

Three months ago, I was that developer who could build a decent React frontend but turned into a deer in headlights the moment someone mentioned "database schema" or "API endpoints." You know the type - great at making things look pretty, terrible at making them actually work.

Then I got tired of being the "frontend person" in every conversation and decided to do something completely unreasonable: build a new backend project every single day for a month.

Spoiler alert: It was one of the best terrible ideas I've ever had.

The Problem With "Learning Backend"

Here's the thing about backend development - it's intimidating as hell when you're coming from frontend land. Frontend feels immediate and visual. You change a color, boom, you see it. You add a button, click it, it does something.

Backend? You're dealing with invisible stuff happening on some server somewhere, databases that might explode if you look at them wrong, and error messages that read like they were written by someone who hates you personally.

Most tutorials don't help either. They're either:

Too simple ("Here's how to make a hello world API!")
Too complex ("Let's build Twitter but with microservices and Kubernetes!")
Too boring ("Today we'll learn about database normalization...")

I needed something that would force me to actually understand this stuff without making me fall asleep.

The Daily Project Rules (AKA How to Not Burn Out)

I set some rules to keep myself sane:

Rule 1: Keep it stupidly simple
No fancy architectures, no trying to build the next Facebook. Just basic CRUD operations that actually work.

Rule 2: Different tech each time
One day Express.js, next day FastAPI, then maybe some Go. The goal was breadth, not depth.

Rule 3: It has to DO something
No more tutorial hell. Each project had to solve a real (even if tiny) problem I actually had.

Rule 4: Document the pain points
Every time I got stuck, I wrote down what confused me. This became gold later.

Week 1: Everything Is On Fire 🔥

My first project was a simple expense tracker API. Should be easy, right? Track expenses, get expenses, done.

Four hours later, I'm googling "why does my database keep saying connection refused" at 2 AM like some kind of backend goblin.

Turns out I had:

Wrong database connection string
Forgot to actually start the database
Mixed up async/await syntax
No idea how middleware works
A profound confusion about what a port number is

But you know what? By day 3, I wasn't googling basic connection issues anymore. By day 7, I could set up a basic REST API without wanting to throw my laptop out the window.

Week 2: Things Click (Sort Of)

Started building random stuff:

A URL shortener (learned about redirects)
A simple chat API (discovered WebSockets exist)
A weather app backend (API keys are a thing)
A note-taking API (CRUD operations finally made sense)

Most of these projects were terrible. Like, really bad. But they WORKED, which was a huge mental shift from "I have no idea what I'm doing" to "I can figure this out."

Week 3: The Breakthrough

This is when it got interesting. I started recognizing patterns:

Most APIs follow similar structures
Error handling is basically the same everywhere
Databases aren't trying to personally attack me
Authentication is confusing but not impossible

I built:

A habit tracker backend (finally understood user sessions)
A file upload service (learned about middleware properly)
A simple job queue (discovered background processing)
A basic analytics API (aggregation queries clicked)

Each project built on lessons from the previous ones. It felt like those moments in video games when you finally understand the mechanics and everything becomes fluid.

What Actually Changed

The Technical Stuff:

Went from "what's an endpoint" to building functional APIs
Actually understand databases now (shocking, I know)
Can read documentation without crying
Know enough to be dangerous with Docker and deployment

The Mental Shift:

Backend stopped feeling like black magic
Started thinking in systems instead of just components
Gained confidence to take on full-stack projects
Realized most "complex" backend stuff is just simple stuff connected together

Should You Actually Do This?

Look, building a project every day is kind of insane. But here's what I'd recommend:

Start with 3 projects a week - gives you time to actually understand what you're building

Focus on solving real problems - even tiny ones from your own life

Use different tools - don't get stuck in one ecosystem

Document everything - future you will thank present you

Deploy your stuff - it's not real until it's running somewhere

The Bottom Line

Most people overthink learning backend development. They want to understand everything before they start building anything.

But here's the secret: you learn by building, not by reading. And you build confidence by shipping things, even if they're small and terrible.

Three months later, I'm not a backend expert. But I'm also not intimidated by backend work anymore. I can spin up an API, connect it to a database, and deploy it without having an existential crisis.

Sometimes the best way to learn something is to just start doing it badly and improve as you go.

What's stopping you from building that project you've been thinking about? And what's the smallest version you could actually finish this week?

From Hunt-and-Peck to 50+ WPM: My 30-Day Typing Journey

Omkar Gawde — Sun, 14 Sep 2025 06:24:09 +0000

So here's the thing, I wanted to get better at coding faster. Simple goal, right? Turns out learning to type properly is like trying to retrain your brain while your fingers stage a rebellion. But after 30 days of deliberate practice, I went from a pathetic 15 WPM to a solid 50+ WPM, and I'm here to tell you exactly how I did it (spoiler: it's not what most typing tutorials tell you).

The Wake-Up Call: Speed ≠ Flailing Your Fingers

Like most people, I thought typing fast meant mashing keys faster. I was wrong. Really, embarrassingly wrong.

My journey started at TypingClub, where I learned the basic letter mappings. Nothing fancy - just figuring out which finger hits which key. But after finishing their course, I was stuck at a miserable 15-18 WPM. That's when I discovered Keybr.com, and everything changed.

The Accuracy-First Revelation

Here's the brutal truth nobody talks about: speed is a byproduct of accuracy, not the other way around.

I spent weeks obsessing over WPM targets, trying to hit 60 WPM because that sounded impressive. But every time I pushed speed, my accuracy tanked, and I'd plateau harder than a bad sitcom after season 3.

Then I had my "aha" moment. Instead of chasing speed, I focused entirely on mistakes:

Week 1: Maximum 4 mistakes per test
Week 2: Maximum 3 mistakes per test
Week 3: Maximum 2 mistakes per test
Week 4: Maximum 1 mistake per test

Guess what happened? My speed naturally increased from 30 WPM to 50+ WPM while maintaining 95%+ accuracy. Magic? Nope. Just muscle memory doing its job when you stop fighting it.

The Letter B Conspiracy (And Other Finger Placement Disasters)

About two weeks in, I discovered I'd been typing the letter B with my RIGHT index finger instead of my left. For weeks.

This was like finding out you've been brushing your teeth with the wrong hand your entire life. Fixing it meant deliberately slowing down, accepting temporarily worse performance, and retraining muscle memory one painful keystroke at a time.

Pro tip: If you're using the wrong fingers, fix it NOW. Bad habits compound faster than interest debt, and they're twice as painful to fix later.

The Keybr Settings That Actually Matter

Most people mess up their Keybr settings and then wonder why progress stalls. Here's what actually works:

Keep "Unlock next key only when previous keys are above target speed" UNCHECKED.

I know, I know. It sounds counterintuitive. But here's why: you don't want your slowest letters holding back your overall progress. Let some letters be at 25 WPM while others hit 40 WPM. The weak ones will catch up naturally through repetition.

Set your target speed conservatively. I started at 20 WPM, then moved to 25 WPM, then 30 WPM. Small increments, big results.

The Problem Letters (Every Typist's Worst Enemies)

Certain letters are universal troublemakers:

Q, P, B: Pinky and finger-stretch nightmares
J, X, Z: The rarely-used rebels
Letter combinations that make you question reality: r/t, y/u, f/g, h/j

For these, I created custom practice sessions on MonkeyType with targeted word lists. Eight-minute speed drills focusing purely on problem letters. No accuracy pressure, just building speed patterns.

Example drill: "quick quiet queen quote question baby book bubble bobby jump just major enjoy"

Boring? Yes. Effective? Absolutely.

The Metrics That Actually Matter

Forget about your top speed. That one time you hit 60 WPM means nothing if your average is 35 WPM.

Track these instead:

Average WPM across multiple tests (your real speed)
Accuracy percentage (never sacrifice this for speed)
Mistakes per test (the most honest metric)
Consistency score (smooth typing beats erratic bursts)

I logged everything daily. Sounds obsessive, but data doesn't lie to make you feel better.

The Plateau Breakthrough Moments

Around day 20, I hit my first major plateau at 40 WPM. Nothing I did seemed to help. That's when I learned about the "performance anxiety" phenomenon.

Picture this: you're typing along, everything's flowing, then you glance at the speed counter and see 68 WPM. Your brain goes "HOLY CRAP I'M DOING IT!" and immediately your fingers seize up like a Windows 95 computer trying to run modern software. Speed crashes back to 45 WPM.

Solution? Cover the speed counter during tests. Focus on rhythm and accuracy, not numbers.

The 30-Day Reality Check

Can you hit 60-70 WPM in 30 days starting from scratch? Probably not.

Can you build a solid foundation that gets you to 40-50 WPM with excellent accuracy? Absolutely.

Here's my realistic timeline:

Week 1: 15→25 WPM (learning finger positions)
Week 2: 25→35 WPM (building accuracy habits)
Week 3: 35→45 WPM (speed naturally increasing)
Week 4: 45→50+ WPM (plateau breaking and refinement)

The journey from 50 WPM to 70+ WPM? That's another 2-3 months of consistent practice.

Tools That Actually Work

Keybr.com: Best for systematic letter progression
MonkeyType: Perfect for custom practice and real-world text
10FastFingers: Good for quick accuracy checks
Your own mistake tracking: Seriously, keep a log

The Coding Connection (Why This All Started)

Remember, I wanted to get better at coding. After 30 days, typing common patterns like const handleClick = () => {} or className="flex items-center" became automatic. No more hunt-and-pecking through React components.

The speed improvement in coding felt even more dramatic than in regular typing, probably because code has so many repeated patterns.

The Bottom Line

Typing improvement isn't sexy. It's not a life hack or a secret technique. It's just consistent, deliberate practice with the right focus.

Focus on accuracy first, speed follows. Fix bad finger habits early. Track your real metrics, not your ego metrics. And for the love of all that's holy, use your LEFT index finger for the letter B.

30 days of proper practice beats 6 months of flailing around. Trust the process, embrace the plateau moments, and remember - even professional pianists practice scales.

Now stop reading about typing improvement and go actually practice. Your future coding self will thank you.

Currently at 50+ WPM average with 96%+ accuracy. Still working on that damn letter B, but we're getting there.

post check

Omkar Gawde — Sat, 13 Sep 2025 20:16:50 +0000

Got dev++ free on github student pack