shitty first commits

Sandesh Bhandari — Sun, 10 May 2026 05:35:53 +0000

A few weeks ago I was scrolling through GitHub at 1am. I don't know why I do this to myself. I guess it's the same energy as scrolling through the Instagram of someone you used to know. You're not gonna find anything good. But you keep going anyway.
I ended up on the profile of an engineer I've always quietly looked up to. The kind of person whose name shows up in the contributor list of every library I use. The kind of person I assume reads the docs cover to cover and writes pseudocode on a whiteboard before they touch the keyboard.
Their commit history was so clean. So neat. So intentional. Every message was perfectly worded. Every diff was tiny and surgical. Every branch was named exactly what it should be named.
I sat there in the dark and thought to myself. Do people actually code like this? Or are they just performing? Or am I just bad at this?

It made me feel small. Not in a dramatic way. Just in the small way you feel small when you realize the gap between the engineers you admire and the engineer you actually are is wider than you'd like to admit.

Because the truth is, my own commit history is a horror movie. It's the kind of thing I would not show my mother, my therapist, or my future child. If a reviewer ever scrolled through it without context, they would assume that whoever wrote this had a stroke halfway through every Tuesday.

But that's me. And I think after a few years of doing this, I've finally accepted that this is just how I work.
I used to think being a "good" engineer meant sitting down with a clean plan and typing out beautiful, correct code on the first try. I used to think the best engineers carried an architecture diagram in their head at all times. I used to think one day I would grow into that kind of person. The kind who knows what he is building before he builds it.

But I've been doing this long enough to know that's just not true. At least not for me. For me, the only way I can get anything built at all, is to write a really, really shitty first commit.

I mean it. The first version of anything I write is embarrassing. The variables are named things like data, data2, finalData, actualFinalData, pleaseWork. There are nested if statements buried six layers deep. There are functions that are forty lines long when they should have been five. There are TODOs sprinkled like breadcrumbs that I will absolutely not come back to clean up. The whole thing is held together with duct tape and prayer.
And honestly? I don't think there's any other way to do it.

Maybe it's because I'm not as talented as I want to be. Maybe it's because I never really learned the "right" way to architect a codebase. Maybe it's because nobody actually writes clean code on the first try. They just don't show you the version before.

The first commit doesn't care about your senior engineer. The first commit doesn't care about the linting rules. The first commit doesn't care about the contributing guide. The first commit doesn't care about your PR template.

The first commit only cares about getting the thing on the screen in some shape, however ugly. Because if it's not on the screen, it doesn't exist. And if it doesn't exist, you can't make it better.

I think that's the part nobody really tells you when you're new.
There was a Tuesday last year I'll probably never forget. Or maybe I'll forget eventually, who knows. Memory is funny like that.

It was around 3am. I had been staring at the same function for six hours. The deadline was the next morning. I had promised myself I'd sleep at midnight. Then 1am. Then "just one more fix." There was an empty mug of cold coffee on my desk and a half eaten bowl of instant noodles I had forgotten about. The function still didn't compile. I was crying a little. Not the dramatic kind of crying. Just the kind that happens when your eyes are too tired to do anything else.

And in that moment, I had this realization. This is how it works. This is how it has always worked. Every piece of code I've ever shipped started as some hideous draft I wrote at 3am with shaking hands and zero confidence.

The next morning I sat down with fresh eyes and rewrote half of it in an hour. It was fine. It's always fine.
A while back I got assigned my first "real" feature ticket. The kind of ticket that goes into a planning doc and gets discussed in standups. The description was so vague, it sounded more like the title of an indie movie than an actual specification. I was so excited.

I wanted to prove myself. I wanted my senior engineer to look at my pull request and think, "Wow, he actually knows what he's doing." I wanted clean code. Deliberate code. The kind of code that looks like it was written by someone who deserved her job.
Instead I wrote 240 lines in a single function. I named one of the variables "thingy." I pushed straight to main at 2am because I had forgotten about the branch policy. I wrote my commit messages in past tense, which apparently violated the contributing guide that I had not read. Who reads those anyway? Be honest.

The next morning, the senior engineer left a comment on my PR. It just said "interesting." That was it. One word. And somehow that one word made me want to delete my account, change my name, and live in the mountains forever.
Could anything be more humiliating? Probably. But not in that moment.

Could I have written it better? Maybe. Maybe if I had planned more. Maybe if I had read the docs. Maybe if I had asked for help. But I didn't. And the truth is, even if I had asked for help, I still would have written something messy. Because the messy version is the only version I know how to write first.
I've been thinking lately about why we hide our shitty first commits. Why we squash them, rebase them, force push them out of existence before anyone else can see them. Why we pretend the clean version was the only version.

Maybe it's because we're scared of being seen as mediocre. Maybe it's because we don't want to look like we don't know what we're doing. Maybe it's because the internet has trained us to only post the polished cut.

But I think there's something honest about the shitty first commit that we lose when we delete it. The shitty first commit is the version of you that wasn't performing. The version that didn't care if anyone was watching. The version that just wanted to figure something out.
And isn't that kind of beautiful?
It's funny, actually. We spend so much time pretending we always knew what we were doing. We rewrite the history of the codebase. We rewrite the history of our careers. We rewrite the story so that the messy parts disappear and the clean parts shine. As if anyone has ever built anything good without first building something bad.
There is a beauty in a function that doesn't compile.
There is a beauty in a variable named "temp2."
There is a beauty in a commit message that just says "fix."
There is a beauty in a 3am push to your personal branch.
There is a beauty in not knowing what you're building until you've built it.
There is a beauty in being unfinished.
There is a beauty in being too tired to care.
I named one of my branches "shitty-first-commit" once. I never deleted it. I wanted to remember it. I wanted to keep the version of me that wrote it. The one who was trying so hard. The one who didn't know better yet. The one who would eventually rewrite the whole thing and never look back.
Maybe in a few years I'll grow into the kind of engineer who writes clean first drafts. Maybe one day my GitHub profile will be the one some junior dev is scrolling through at 1am, wondering if I'm performing or actually that good.
Or maybe I'll just keep writing shitty first commits forever.
And maybe, if I'm honest, that's okay. Because the shitty first commit is the part nobody else can write for you. It's the part where you find out what you're actually trying to make. Everything else is just cleanup.
So here's to all the shitty first commits we've hidden.
And here's to keeping them anyway.

Forem: Sandesh Bhandari

shitty first commits