shityy commits

There is this idea people carry about programmers. People tend to look at successful programmers who are getting their apps shipped and maybe even doing well financially and think that they sit down at their desks every morning feeling like a million dollars, feeling great about who they are and how much talent they have and what a great solution they have to build; that they take in a few deep breaths, push back their sleeves, roll their necks a few times to get all the cricks out, and dive in, typing fully formed code as fast as a compiler. Like it was never hard. Like it didn't cost them anything. But that is just the story the uninitiated tell themselves. I know some very great programmers, engineers whose code you'd read and feel embarrassed by your own, and not one of them sits down routinely feeling wildly enthusiastic and confident. Not one of them writes elegant first commits. All right, one of them does, but we do not like him very much. We do not think he has a rich inner life or that anyone can even stand him.

Very few programmers really know what they are building until they've built it. Nor do they go about their business feeling dewy and thrilled. They do not type a few warm-up lines and then find themselves bounding along like huskies across the snow. One programmer I know tells me that he sits down every morning and says to himself nicely, "It's not like you don't have a choice, because you do -- you can either type, or kill yourself." We all often feel like we are pulling teeth, even those engineers whose final code ends up looking the most effortless and clean. The right logic and structure just do not come pouring out like ticker tape most of the time. Now, there are those rare programmers said to have felt that the solutions just came to them every morning, sitting there, one supposes, humming away, typing without struggle. But this is a very hostile and aggressive position. One might hope for bad things to rain down on a person like this.

For me and most of the other programmers I know, coding is not some beautiful thing. In fact, the only way I can get anything built at all is to write really, really shitty first commits.

The first commit is the child's draft, where you hack all over the place, knowing that no one is going to see it later. You just let this childlike part of you come through and onto the screen. If one of the voices in your head wants to hardcode everything and name your variable `x_final_FINAL2`, you let her. No one is watching. You let yourself get into really sloppy, embarrassing, copy-pasted territory and just get it down on screen because there may be something in that terrible nested loop, in that function you'd never show anyone, that you would never have gotten to by more careful, rational design. Something in the very last line of the very last function that is so clarifying or strange that you now know what you are actually building, more or less, or in what direction it needs to go. There is no way to get there without first getting through the mess. You want to skip it. You can't.

I used to build features for a startup under constant deadline pressure. Those features had nothing to do with clean architecture. In fact one particularly bad commit did cause a couple of outages, not helped by my stuffing logic into a single function the size of a short story. My commits always took two days. First I'd sit down at my desk with the ticket and stare at it. Like if I looked long enough, the solution would just surface. It never did. I'd try typing a couple of dreadful lines, delete them, try again, and feel despair and worry settle on my chest like a wet blanket. I'd think to myself, calmly: I'm not going to be able to figure this out. I don't understand the codebase. I'm toast. Maybe, I'd think, I can find a library that does this for me. Probably not. I'd get up and stare at the ceiling, remember to breathe, make a few Slack messages, close them without sending. Eventually I'd go back and sit down at my desk. Finally I would pick up my one-inch picture frame and every time the answer would come: all I had to do was write a shitty first commit of, say, the one core function. And nothing more.

So I'd start writing without reining myself in, just making my fingers move. And the code would come out in one long function that was forty lines long even though it should have been five, and then I'd start building out logic branch by branch, and the variable names would be insane, sitting there like cartoon characters. They'd be pretending to handle edge cases, failing at every one, no matter how hard I tried to rein it down, no matter how conscious I was of what a mess it was. I once showed a senior engineer one of my first commits during my early days of programming. "Sandesh," she said, "this is like watching someone eat a whole cake with their hands, one fistful at a time. But you ate the whole cake."

But because by then I had been coding for some years, I had eventually let myself trust the process -- sort of, more or less. I'd write it out as long as it needed to be, with self-indulgent variable names, sprawling descriptions in the comments, lots of hardcoded values that made the whole thing sound more like a ransom note than functioning software.

The whole thing would be so long and incoherent and hideous that for the rest of the day I'd obsess about getting hit by a car before I could write a decent second draft. I'd worry that people would read what I'd written and believe that the accident had really been a suicide, that I had panicked because my talent was waning and my mind was shot.

The next day, I'd sit down, go through it all with fresh eyes, take out everything I possibly could, find the real logic buried somewhere in the middle, figure out a clean place to end it, and then write a second draft. It always turned out fine, sometimes even elegant and clever and useful. I'd go over it one more time and open a pull request.

Then, a month later, when it was time for the next feature, the whole process would start again, complete with the fear that people would find my first commit before I could rewrite it.

Almost all good code begins with terrible first efforts. You need to start somewhere. Start by getting something -- anything -- running. A friend of mine says that the first commit is the down draft -- you just get it down. The second draft is the up draft -- you fix it up. You try to say what you mean more precisely. And the third draft is the dental draft, where you check every function, every abstraction, every dependency, to see if it's loose or bloated or broken, or even, help us all, clean.

You think writing shitty first commits means you are bad at this. It doesn't. It means you are doing it. The ones who never ship are the ones waiting to feel ready. You can't win against yourself by waiting. You just have to open the file and start. Even if what comes out is ugly. Even if it doesn't resemble anything you meant to make. You get it down first. Everything else comes after.