Gritty code

I met with a colleague today while wearing my “code is poetry gritty” t-shirt that was given out at last month’s WordCamp. He talked a bit about gritty code vs poetic code, and how gritty code can be a necessary step towards poetic code.

I completely agree.

I write a lot of gritty code as part of my research, but almost never while working in industry for obvious reasons. Gritty code is my favourite type of code to write.

I’ve heard startups call gritty code “founder code”. It’s the stuff you write when you’re exploring a concept or trying to do something new. It’s usually done fast and without regard for maintainability or scalability.

Gritty code is different than “sloppy code”. Sloppy code involves practices like copy-and-paste coding that leave you with problems like code clones. Rushing work can lead to sloppy code. A lot of “sloppy code” does the job well enough, so economically speaking it makes sense that we see a lot of it.

Gritty code might look sloppy, but the key difference is that while gritty code is intended to be refactored later, sloppy code is not exploratory and is done as a general (poor) practice.

And gritty code really should get refactored into the more beautiful poetic code. It’s a lot easier to map out what code should look like when you have code that actually works. When you’re still trying to figure out how something complicated enough can work it’s difficult to simultaneously determine how it optimally should work.

As developers get more experienced they can write less and less gritty code. They’ve seen the same problems enough to know what will work best. It’s fun to write great, poetic code. I like to think I’ve done it a few times, mostly in Haskell and OCaml. I find it fun because I know it can last a long time. Maybe even a really long time.

But I love writing gritty code, because it means that you’re doing and/or learning something new.