I try to avoid personal pieces, but hey, maybe you can get something out of this too. An article about taming perfectionism over at defmacro.org got me thinking. On the perfect vs. good-enough scale of making stuff, I'm clearly in the good-enough camp. However, ugly code and bad design, even in small doses make me want to vomit.

So what kind of coder am I?

I'm a nerd. I've been one for a long time. That much I know. But what kind is a tricky question.

The puzzle and the problem

In my university years, I was always dogged by a more specific question: software engineering or computer science? My initial choice of SE was arbitrary: I had lots of fun writing code, and I just wanted some way to learn more about it. SE emphasised "good enough" but project management was puke-worthy, while CS showed me "perfect" but maths did not appeal to me. I was stuck in no-man's-land, an empty flat land with camps firm on either side.

I knew a girl at that university. She was a programmer, much like myself, and one thing she really liked was puzzles. One of the first times we'd hung out, she was working on a puzzle and asked if I wanted to help. I turned her down, for the same reason I refuse all puzzles: they don't solve an actual problem. Puzzles are contrived. It's the same reason I don't answer hypotheticals.

A problem, as opposed to a puzzle, begs for a solution in my eyes. NetworkManager screwing up my connection settings? Write a daemon script, problem solved, and I get a buzz out of that. Somebody's Stylish CSS style not working to rotate a banner? Knock up a Greasemonkey script, offer it on userscripts, problem solved. Solving problems not only helps me learn stuff, it also lets me give to others and makes me happy. A puzzle robs me of those: I don't learn anything that would be useful elsewhere, and it doesn't help anyone, making it useless fluff.

Garden of coloured lines

Maybe I saw things differently in primary school (elementary school for you Americans), because I spent a lot of time drawing mazes. Yeah, those things with the multiple paths where you go from start to finish, that kind of maze. On paper, cardboard, books, anything I could draw on. I'd draw and draw and draw, small ones, big ones, circular ones, ones with different sections.

I didn't solve mazes though. I mean, the small ones I could just finish by dragging my finger though them, but big and huge mazes I'd never even attempt. I'd just look at them. I didn't solve my own mazes either, but that was because I knew the way through already. These mazes just struck me with awe. The hundreds of little symmetric lines and paths came together to create a large, powerful whole. The lines were needed for me to see the power of the whole maze, though the lines themselves were so simple and plain on their own. The simple little things made a beautiful whole.

I eventually let go of the mazes, but I picked up computer programming. Only now have I found a link between the two. When it comes to code, lots of times I appear to just be skimming over the details. The conditions, loops, decisions, recursions, functions, variables give way to the "gist" of the code I'm going over.

But I'm not skimming.

The truth is, I aim obsessively for the true essence of the code in front of me. If I'm reading it, it's how I read the code. If I'm writing it, I always try to make the essence shine through. The lines are simple, but together, they express a beautiful whole. A well-written source file of today hits me with the same awe that an intricately-crafted maze hit the me of yesteryear.

It's not about the lines. It's not about the ifs or whiles or functions or variables or design patterns or prototypes or objects or techniques. Those things are tools, or rather, instruments, like a writer's pen, or a painter's brush. Programming is a form of expression, at once both a science and an art, and yet neither. We need a new field: a "scart", perhaps?

The answer to the question

So what kind of coder am I?

• I started programming at 12, which would have been about a decade ago, and still going strong.
• I work on problems, not puzzles.
• I favour finding the essence of a piece of code over its details, but I don't throw them away, any more than a reader throws away words in a piece of prose.
• I used to dabble in game dev, moving to regular programming for kicks, and then for coursework and kicks.
• Without an aim, I'm undisciplined and slow, but give me an objective, task or problem, and I'll stay up all night making it happen if I need to.
• Perfect code is what I want, but I'm happy to settle for good enough.
• I spend more time giving coding help online than writing actual code, but I'd make an awful tutor/teacher, due to my lacking people skills. I make a point to teach when helping, because that person will carry that knowledge for as long as they'll remember, and that makes me feel good, that I really helped someone. As such, hit-and-run-style queries frustrate me, because they're like puzzles, not problems.

It's a smallish list, but that list is me from end to end. So, what kind of coder are you?

That's a damn good question.