Dave Powers

I create things with words and/or code.

On Being a Software Developer

I am a “software developer.” Or, at least, that’s what my official job title says. I suppose I could be considered a web developer just as equally (possibly more accurately). Others who do similar work may self-identify as a programmer, coder, hacker, problem-solver, or a number of other terms.

Some preface their title with their technology of choice (or necessity, depending on their job): I’m a “Rails developer” or a “Python coder.” This may, again, be more accurate, but does your toolset define your work? As you learn a new technology or language, when does it become appropriate to append that on to your title or list of skills?

Many companies also distinguish between “junior” and “senior” level programmers, sometimes with “middle” in between. I don’t think this gives an accurate portrayal of an individual’s skill level, and the category in which a person falls can vary widely from organization to organization. To me they come across more so as H.R. buzzwords. I’m sure there are many senior developers who coast by, while coworkers lower in the company totem pole work much harder in order to prove themselves.

There’s also the notion of being a “real” developer. This tends to manifest itself in developers scoffing at those using what they consider to be “beginner” languages. Today it is easier for anyone to start programming, which should be seen as a good thing. A larger talent pool to draw from benefits all, and allows you more people to work and learn with. Most likely, someone without the talent or desire to succeed will be weeded out.

Titles are really just what you make of them. You could be a “rockstar programmer” or a “Chief Imagination Officer”, but all it does is obfuscate what your work actually entails.

When it comes down to it, all of these people are building things. This could mean complicated things, or it could mean simple things, but building nonetheless. I think people sometimes get caught up in how to cram in as many flashy words as possible when describing what they do, rather than providing a succinct answer straightforward enough for someone who doesn’t identity as a programmer to understand. Marco Arment’s short blog post “Explaining your job” accurately sums up my thoughts on the matter.

Part of my reasoning for writing about this subject stems from my own struggle on how to best describe my abilities. A couple months ago, I started my first development position. On paper, one day I wasn’t a software developer, and the next day I was. But really, I’d been developing software for months prior as I began my transition to a career doing just that; this was simply the next step of the process.

I’d had my own preconceived notions of what a software developer was. How they worked. How capable they were. It forced me to question whether I fit into my own description. I primarily program in Ruby, but I’d wonder “how well do I actually know Ruby?” Some of this self-questioning has shades of impostor syndrome.1

Today, I still don’t quite feel like I deserve to call myself a software developer. Though, in a way, I think this is a good thing; it keeps me motivated to improve, and always be bettering myself. I need to remind myself to reflect on my achievements and how far I’ve come, but I don’t want to ever be content with my current skill set or knowledge. After all, what motivation does the “senior” engineer have to enhance their skills, if someone has already deemed them to be at the highest level?

Going forward, I plan to continue to record my growth during my career. Seeing measurable progress helps to remind me how far I’ve come. Writing down what I did for the day along with any difficulties helps to reinforce what I’ve actually learned. As long as I’m not stagnant, I’m happy.

And for now, I’m developing software everyday. I guess that makes me a software developer, whether I have the title to show for it or not.


  1. When reading this article, I realized that in blogging about the subject, I was practicing one of the modes of therapy.

Comments