Coder, Programmer, Developer, or Engineer?

November 11, 2026by DavidJFelix10m read
careersoftware-engineeringaioutlookpersonal

Note: This is a weird post about semantics, don’t take it too seriously.

People often use the terms “coder”, “programmer”, “developer”, and “software engineer” interchangeably, but each one means something different to me. Semantics like this aren’t that deep, but as I reflect on my own career, I keep returning to the words we use to describe the job. I don’t believe my classification of these words is a universal truth, but rather a subjective observation about the career I’ve found myself in. Ongoing improvements to AI workflows have made me question that career. What is my role? How do I describe myself? What is my goal in this career? Does AI impact that goal?

Carving the path

I’m sure many tech-adjacent people can relate to the way relatives talk about their job or present them with computers broken in other-worldly ways. I fondly recall early in my career insisting that my mother stop saying that I “work in IT”; that was just the start of me drawing a semantic line in the sand. My bachelor’s degree says “Computer Engineering” and I call myself a “software engineer”; aside from places where it’s illegal to do so1, I suggest that anyone in a job like mine do the same, regardless of degree or accreditation.

I’m a huge proponent of self-taught developers. I love it when people choose software, find a calling in it, and want to learn more. It’s a path with few true barriers to entry and hundreds of inroads. There are chat communities, message boards, tutorials, learning paths, video series, free curricula, code bootcamps, and paths through associate’s degrees up to PhDs. Often, the most enthusiastic software engineers I’ve met come from code bootcamps or are self-taught. There’s something really inspiring and beautiful about a skill that you can learn by reading and practicing on a few hundred dollars’ worth of personal electronics, yet that has the depth to study for years. I find it to be a tragedy when software wears others down and good programmers burn out or leave the career due to disillusionment.

Codifying identity

I am not a coder. Programmers will often say “I love to code” or “I love coding”, as slang for programming. I think the term is fine in this context because it serves to clarify what you mean by “programming”2. To me, “coder” is different. Depending on context, “coder” is nearly a pejorative for software developers. When spoken by somebody who does not program, the word conveys the notion that the role is transcription and that the only barrier is knowledge of the language. Even “translation” says more; it conveys that the work goes beyond converting words; it’s adapting to differences in grammar, culture, and colloquialism, and interpreting the meaning of one language to convey it in another. As a champion for software’s low barrier to entry, I insist that the language and the “[en]coding” are not the barrier. If anything, the work is decoding ideas into process and data, not encoding that process into a programming language.

I am often a programmer, but not professionally. I genuinely like solving problems and finding clever solutions or learning about data structures. I’ve learned many programming languages to understand designs, organization, structures, and theory better. I read about frameworks and follow thought leaders in the industry. Programming is something you do, but professionally, I rarely think you should call yourself a “programmer”. Some genuinely do show up to work and write a ton of code for well-specified business needs and almost exclusively program. Earlier in my career as an individual contributor, I might have said that this is an ideal state. I now feel this is an idealistic state that can only exist because realists create it for programmers. I rarely find that programming is the bulk of the work that needs to be done when creating software; I know many developers and engineers who program infrequently and are successful and talented at their jobs. Many intelligent engineers, including past versions of myself, aim to find roles which are purely programming. However, I believe now more than ever these are the spaces where burnout and disillusionment with one’s career fester as product skills, interpersonal skills, business involvement, and EQ3 languish. Programming to spec makes you into a tool for the business to use. When the machine is well oiled, everything feels good, but when a problem arises, tools are expendable.

Developing a focus

I like developers. Software development is a noble craft and good developers are often hard to find and also critical to the success of business goals in software. I am fiercely defensive of good software developers and do not stand for non-technical people calling them “coders”. Only other developers and some project managers or product owners can call them “devs”4. I often call myself a “software developer” and am happy with this name in countries or at companies where “engineer” is considered professionally guarded. I love learning from great software developers. Thought leaders who write about team dynamics, legacy code, software maintenance, and domain-driven design are, by my definition, “software developers”.

Software developers are a business reality in the face of engineering purity. They involve themselves in the business; they discover work and translate business goals into software solutions. Good developers understand how to build incrementally and start with value first. Sometimes technical merits lose to efficiency and good developers can juggle the cost of fast wins. Something I’ve come to respect immensely among my peers is that great developers understand product and start with problems before offering solutions. Software development does not require professional accreditation and often benefits from a balance of technical and interpersonal skills.

By my archetypal definition, programmers don’t concern themselves with how the business operates, just what is asked of them. Likewise, the business does not normally ask programmers for their opinion on value or feasibility; it’s a purely operational exchange where the business needs this and the programmer builds it. On the other side, engineers are thoughtful builders who aim for technical merit and longevity. In the middle, developers balance these by learning what the business wants, building something that works, proving it can stand, and only then making sure it can last. This isn’t a slight against developers, but a recognition that many systems made quickly last longer than expected; they accomplish business goals adequately and provide immense return on investment at significantly lower cost than something “well engineered” or “built to last”.

I tend to think of software creation like construction. Suppose the business belief is that people want housing in an area; one could plan a well-engineered high-rise, do a land survey, drill massive foundations, run wind calculations to ensure the building will stand for a century, order steel and concrete, and schedule workers and phases. But if the business belief is untested, this could be a huge waste of money. Builders often get lost in building. Instead of a high-rise, why not build a house? If demand is large, you can always build another house or a high-rise elsewhere, or even tear down the house and build something larger and more suitable. Not everything needs to be overbuilt and a good developer is pragmatic.

Fueling the engine

I call myself an “engineer”. Even though I feel compelled by the software developer’s pragmatism and I think overbuilding is an all-too-common mistake, I encourage those who otherwise consider themselves “software developers” to also call themselves “software engineers”. One of the major reasons I push for this moniker is pride. I take pride in the craft and pride in my hard-earned knowledge. I believe others should too. I’m proud of my degree in computer engineering, even if I acknowledge that it doesn’t prove me better or smarter than those without it. I’m proud of the role I take in understanding what software needs to be built and then building something that can achieve that. As I alluded to earlier, I strongly believe that what I call this role and what I allow others to call it convey respect for the work. If you don’t think highly of yourself and respect yourself, why should others? In my experience, this differential in respect shows up in posted salaries; the US “software engineering”5 postings I’ve seen tend to list $10k-$15k more per year than “software developer” postings. A lot of this comes down to the expectations and responsibilities of the role, but I contend that those stem from respect for the work being done.

Despite self-esteem and pride for the job, I think it’s important to remain humble; anyone can become a software engineer, after all. Humility helps prevent the engineer’s folly of ignoring what the moment needs, instead focusing on the achievement or monument that one can build for themselves. Over-engineering stems from pride. Maybe it comes from thinking one is above the concerns of the business, ignoring the non-technical problems in front of them. Perhaps it comes from feeling that those problems aren’t their concern, or that their importance is gauged by how many terabytes they can process or how many servers they manage. An engineer’s job is to fix the problem, but I’d contend it’s also to build something that can last. An engineer who focuses only on the technical aspects of endurance is myopic. Building to last means building something that is comprehensible and maintainable, not something that resists deletion or destruction. The value of software is in the problems it solves, not the cost to replace it.

This whole discussion about what to call people who write code for a living can feel like wasted energy. In a world where AI capabilities are growing and technologists are constantly foretelling the end of SaaS or layoffs coming to software development, I believe it is more important than ever to define one’s purpose and role. What do you do for work? What value do you provide for the company? Do you care about this industry or is it just a job? I don’t particularly believe in “AI doomerism”6, but rather in a gradual change or displacement (not replacement) of roles. Part of the beauty of software has been that anyone can become a good software developer; with AI, that’s becoming more true than ever. The developers who will find homes are those with an affinity for the product and business. Those who may be displaced are engineers who love building, programmers who build to the spec, and developers who care about implementation more than the product and business.

I don’t know what to think about the future for programmers, because I’m not a professional programmer. For engineers, though, I see purpose and a future in SaaS that allows customers to outsource expertise and maintenance. An LLM can help a developer quickly duplicate a SaaS product, but without continual prompting and focus, it won’t maintain or support that system. I strongly believe that software engineers have plenty of room to provide valuable SaaS products in an era where technical challenges are very quickly solved, but gone are the days of rent-seeking on clever ideas. Now it’s about building systems that last and allowing customers to outsource the one thing that AI is constantly aiming to improve, human trust.

Footnotes

  1. A few European countries and Canada have restrictions against calling yourself an “engineer” without professional accreditation. In the US, this pretty much only applies to civil engineers or people calling themselves “Professional Engineers”. There was a PE exam for software, but NCEES discontinued it in 2019 due to low enrollment. Some adjacent exams still exist, but I’d suggest not taking them for software unless a job you want explicitly asks for one. ↩

  2. As opposed to, say, a scheduler like radio programming or broadcast programming. ↩

  3. Short for “emotional quotient”, a measure of emotional intelligence, which is the ability to recognize, understand, and manage your own emotions and the emotions of others. ↩

  4. This is a soft line. I think “dev” is familiar and removes the actual process that is performed by the job from the name. It doesn’t acknowledge that they are developers and that this is a process. The people I’m okay with saying it are those familiar with the effort that goes into software development. The further from the role the speaker is, the more dismissive of the work it feels. I don’t correct speakers, but if I hear somebody say “dev” that I don’t think respects that process, I’ll make a point of saying “software developers” (or “engineers”) back. ↩

  5. Or “back-end engineer”, “front-end engineer”, “full stack engineer”, “platform engineer”, etc. ↩

  6. The idea that software developers will be out of work within a few years. Tech leaders have predicted the end of the profession for a while, and Anthropic’s CEO said in early 2026 that AI could do most of an engineer’s job within a year. Investors bought into a version of it too, when software stocks crashed in the “SaaSpocalypse”. ↩