“Software Developer” vs. “Programmer”

I am mostly writing this because this was the exact question I had as a college student, and the answers I was finding were pretty vague.

I had a general idea that “programmer means you just code all day” and “developer means you do some code, but you also design stuff”. That wasn’t too far off, but I still wasn’t satisfied…

If I become a “programmer”, does that mean I don’t get to decide what I make?

If become a “developer”, does that mean I’ll be dragging-and-dropping widgets instead of coding them?

What initially drew me to IT was being able to BUILD things. As I have progressed in my career, I have only found that to be more and more true.

In all honesty, I have to force myself to learn new things. I am not naturally excited about the newest library or framework just because it’s new — I literally have to FORCE myself to sit down and learn the basics. As soon as I can see how it can enhance my creations (or my productivity in the process of creating), I immediately fall in love at that point.

However, if I suffer through several tutorials, build a small demo, and find an excuse to use it in an existing app - and I still don’t see benefits? I actually dislike it even MORE.

I am definitely different from most of my peers in that regard, and sometimes I wish I could change that about myself — but I can’t. I really just don’t like “technology for the sake of technology”.

I want technology to do things BETTER, not just DIFFERENTLY.

Anyway, back to my original point: being a “developer” sounded far more appealing than being a “programmer”. I wanted to code, but I also knew I would care about the design, the process, even the marketing and customer feedback after the product is released.

In other words, I am super proud to own the title of “developer” and it really does mean something different to me than “programmer”.

As computers and technology continue to expand, we are starting to create new categories for things…and even subcategories within those categories.

For example, in the 80’s you might have been a “Computer Operator” and your job was, well, to operate a computer. Your “specialization” was that you knew how to operate a machine that many others did not.

In the 90’s, computers started becoming both a household and office necessity. At that point, you may have been called either a “Technician” (fixing computers) or a “Programmer” (writing code). While you might be specifically focused on coding, you were still advised “learn a little of everything….C, C++, BASIC, maybe some HTML, etc.”

In the 2000’s, the Internet started taking over everything. So you weren’t just a “programmer”, you were a “web programmer”…and within that category, maybe you specialized in “frontend” (HTML, CSS, JavaScript) or “backend” (PHP, SQL) technologies.

Nowadays, even just in the frontend realm, we are starting to see the need to differentiate between “frontend engineer” (JavaScript, React) and “designer” (HTML, CSS, and UI in general).

My point is that it is no longer enough to just call people “IT guys” — there are worlds of difference between the different specializations. And I think it really matters that we don’t assume that a “programmer” and a “developer” are the same job anymore.

Some of us truly want to just hide in our office, have someone tell us what to do, and just bang out code all day. These types of people are “programmers” — their specialty is the DEPTH of the technical world: being allowed to spend hours digging through technical documentation, writing code without disruption, and not spend time in tons of meetings.

Some of us thrive on wearing multiple hats…they appreciate the well-rounded BREADTH of some code, some meetings, some UX design, etc. These people, the “developers”, should be encouraged to interact frequently with end users and be the “face” of programming to the users — the guy that can translate between technical and userland.

Overall, we all come into the industry for different reasons. We all have different likes/dislikes, preferences, and ways of contributing. I really do believe we can be more productive if we can start recognizing this….stop forcing your programmers into user meetings, and stop forcing your developers into the appendix/back pages of a 600-page printer documentation.

Hire developers to be well-rounded, hire programmers to be technical. Make it clear so you don’t hire someone into the wrong job.