I'm a good engineer but I suck at building stuff

08 May 2016

A few hours ago, !!con wrapped up. It was fantastic. Often I leave conferences having learned something, but tired and ready for the weekend. Writing this from the plane, I feel filled with excitement and energy.

In her keynote, Catt Small asked us to stop focusing on the tools we use to construct our programs, and instead to focus on the artifacts we create – the experiences, the sites, the games, the things we build. Programming culture, she said, is too often distracted by the means of programming rather than considering its ends. We argue endlessly about frameworks and languages and libraries and somehow never really talk about what we’re creating. What’s worse, when teaching people to program, we teach them only how things work; we never teach them how to build. It’s no wonder our students are often woefully unprepared for their careers. We’re obsessed with our means and not at all concerned with our ends.

It was an inspirational talk, and it was the perfect way to start a two day conference on the things that excite us in programming. (!!con, by the way, was one of the best conferences I’ve been to. I highly, highly recommend it.) But it left me with a problem: I think of myself as a good engineer. But I don’t think I’m particularly good at building things.

When I try to build something new, I find myself instantly criticizing my technique, to the point of paralysis. This function is hard to test; this object’s dependencies need to be injected rather than initialized internally; that module needs an integration test; and so on and so forth. Even when writing spike or proof of concept code, I find myself revisiting the same lines over and over again, looking for the best, most natural expression of the ideas it contains – obsessing, like Catt said, over my own construct, rather than on the thing my code does.

This isn’t always a bad thing. Deliberate practice is the best way to improve technique, and I don’t believe in saying “I’ll only write good code when it matters”. But if !!con convinced me of anything, it’s that the next frontier for me as a progammer is learning to relax and focus on what I’m building.

Maybe this is the right way to have gone about learning to program: first learning how to be disciplined, then learning when and how to relax that discipline. But I’m not sure. Had I focused only on the artifacts I was creating this entire time, I would have developed good technique naturally just by tracking what worked and what didn’t? Who knows. But I, for one, am excited to stop worrying so much about code and to spend more time thinking about what to do with it.

(If you’re interested in learning more about !!con, I took a lot of notes while there.)

Update

This post has gathered a lot of attention on Hacker News. Also, the slides to Catt’s talk are now available.

comments powered by Disqus