The Shape of Code
Some code’s like an office building on a skateboard. Or a car launched from a catapult. And sometimes like you’ve wandered into a dark basement with too many cats, some strapped to land-mines.
When you’ve read a lot of code and designed and team-written a bunch of systems you get good at reading code and transferring it into a picture. Bits of code have strong characteristics. A system and the code behind it becomes like a landscape.
You get to know a certain coder’s style, even if they’re following the coding standard. Some people are lazy and test for nothing, some irritate you with unnecessary casts and amateur faux-pas like if (foo == true).
I like old-timer code. It’s terse, leaves the program to be the program without over-managing the problem and properly delegates errors upwards and onwards. It’s got the right amount of error handling and logging. It attacks problems in logical bite-size bits and explains arbitrary crap you forget the moment knock-off time swings round.
So after a while the code is like a picture or a shape or something. If it’s good it’s sleek and fast tipping the hat towards some hacky shit that might be flourish. But it doesn’t crash and it does what it needs to. It’s not the Ferrari of code - it’s more a Mini Minor red-lining to good music and sliding through the corners.
Oh yeah, and it better be able to turn into a plane.
[Originally published on some old blog somewhere around 2008]