Published by Emil Björklund on 18 August, 2013, at 17:03 PM
I’m a web developer. At least that’s what it says on my business card. If I have to be specific, I’m a front-end web developer. In practice, I do a lot of things that are not developer-y, and sometimes drift more towards a role that’s probably normally labelled "designer" of some sort. When people ask, I mostly try to say "I build websites". But behind that, what kind of developer am I really?
I’ve got issues calling myself a programmer. I’ve wondered for a long time why that is: what is the magical boundary that separates me from the (imagined) pointy-hat wizards that hold the ancient secrets of creating working software from incantations hidden in vim/emacs keystrokes? The weird thing is, that’s what I do too, a lot of the time: I write software. I program computers. Not just declaratively by writing HTML/CSS, but with Python, PHP, Javascript etc. Between when I started writing this and publishing it, John Allsopp came out with this great article that refutes the notion that the core web technologies is somehow "not real programming". So what is it that pulls me into that same trap? Is it that I am lucky enough to only work in high-level languages, without the need for strict memory management and type checking? Is it that I’m not skilled enough to understand every clever bit-hack? Is it that the type of software I work on rarely (if ever) requires me to sketch out and pick the most efficient algorithm according to Big-O notation?
Maybe that’s part of it. But at its core, me and my imagined wizards still do the same thing: try to create good, working software from the principles of clarity, readability, testability, modularity, encapsulation, performance etc. We try to identify suitable patterns and think forward in our architecture, connect the code we write to the humans and machines that are to use it, and the other developers that might maintain it. So I am a programmer, probably.
Maybe it’s just impostor syndrome talking. I tend to suffer from that, now and again, up and down. But still. There are some people who pretty much regularly publish innovative CSS solutions, amazing tools and code libraries on GitHub, for example. I’m not one of those people. Why not? Am I not creative? I think I am. But I just don’t work that way. So what kind of a developer am I?
Metaphors about software development only tend to take you so far. The sheer scale of creating software, ranging from manipulating single electrons to moving about gigabytes, terabytes of recorded culture, creates a gap between it and other endeavours. We build, but it’s not like building houses. We grow, but it’s not really sequential. We architect, but the scale doesn’t really allow us to decide up front. We write, but it’s not like writing books.
If I had to use a metaphor for what kind of developer I am, I’d say I might be a librarian. Since I actually produce running code in my daily job, I guess I’m also a writer in this metaphor, but bear with me here.
In trying to be the best web developer I can, I feel a need to understand the web. That involves a lot of what some of my friends who are not in the web business think my job is about, i.e. "clicking on funny links all day". I read copiously about new and old technologies. I bookmark them, I try to classify them, see them in the light of history as well as projected future. Follow up on them. Try them out. Even if they’re not specifically about what I do for a living, the nature of them might have a bearing on my understanding of how other people use the web. So maybe I’m a librarian.
Or maybe I’m a journalist. Trying to get to the bottom of things. Following the leads, collecting material to create a story that holds up to scrutiny. Getting a hold of as many people as possible, and talking to them about their take on the story.
I think my metaphorical job title changes a lot. Sometimes, I might be just a programmer, sometimes a writer, a curator, a cover band or just a lazy bastard. The more roles I try out, the more I can feel comfortable in the "why"s of the solutions that pop into my head once it’s time to get down to the business of writing code.
