Ask HN: Software Developer vs. Software Engineer

Development is more than programming, as it includes other aspects of creating software. I'm not sure we should use the words engineer or architect, as both have strong meanings in other professions, which might not completely fit.

Another reason I like the word "developer", is it implies that there is an ongoing process of "development" - a process which changes direction as it progresses and develops continuously. That fits perfectly with the agile practise I use.

Developer is someone who develops, who makes/transforms things. Software developer is someone who makes/transforms software.

Engineer is someone who studied engineering, a career. Software engineer is someone who studied the software engineering career.

So, at least in Spanish, a software engineer is someone who has a degree in software engineering, no matter what his job is. And a software developer is someone who writes code, no matter what his studies are.

Usually those terms intersect, but not necessarily. I think it's a similar different of a particular teacher vs a professional professor.

Programming is the act of writing programs, and is a skill like any other. Some folks are good at it; some people struggle with it; most people can do some of it if they learn and try hard enough. Programming is what creates value for 95% of the jobs in the tech industry, and if you get good at programming (and programming on a whiteboard) you'll do exceedingly well.

Computer science is the theory of computing; it is a branch of mathematics. Djikstra is famously (wrongly) attributed with saying "Computer Science is no more about computers than astronomy is about telescopes." Many (but not all) amazing computer scientists that I've worked with are terrible programmers and software engineers, but their value has been outsized. Any good programmer can integrate a Raft library into your code for consensus. The computer scientists are the ones that not only apply the correct CDRT theory to your custom-built database, but can prove that it converges consistently.

Software engineering is the practice of delivering the right software on time and on budget; good software architects think in terms of software engineering. In the 1980s, when computers were going in to _everything_, military projects were at the forefront because Reagan ensured that we were spending mad cash there. It was like the dot com boom of the 2000s; you just couldn't go wrong bidding computerized systems. Because they were new, the contracts were cost-plus, and the military-industrial complex screwed the federal government blue with cost overruns. Anything with software on it typically had budget overruns in the 500%+ range. Not wanting to be screwed blue, the Feds reached out to CMU and said "How do we stop this?" So together they built the Software Engineering Institute to put some science and best practices around delivering software. And the SEI screwed them blue, coming up with CMM and a bunch of other bad ideas, but also some good ones along the way.

When thinking about the skill sets of the teams I'm putting together, those are some primary aspects I look at, and the ontology by which I think about them. Of course, there are lots of specialties in each of them, and many people have experience and skills in several of them.

It depends who you're talking to, of course. The goal of language is to create shared understanding, so you need to have shared definitions, whatever they are. Nobody else shares my definitions, so I mostly keep them to myself if I'm not pontificating.

If you're speaking to a recruiter, you are whichever one of them pays the highest. If you're speaking to an academic, you're a computer scientist (perhaps a mediocre one). If you're telling your mom what you do, you're a software engineer because it makes her feel good.

But in all seriousness, yes our job titles are BS to a large degree and we have the tendency to look down on other programmers for various reasons like job title, programming language, operating system and editor/IDE of choice.

What I said about the progression of skill still holds true and if I would include Architect in that list I would define him as:

* is able to set up an architecture for a system

* is able to consider all layers of the system (frontend, backend, services, deployment…)

* is able to change/update an architecture of a system if the requirements change and is capable to predict possible requirement changes in the original architecture

Honestly you can’t be an “architect” if you haven’t been an “engineer” and to become one you will have to have been a “developer”. You just can’t start at the top. What is more interesting is that not every “engineer” wants to become an “architect”. There is theoretical prestige in that title but it also takes you away from the code and I know people who have quit their jobs when their role started to become to detached from actual day to day coding.

I think there is a small distinction in the act of engineering vs. developing, but we all cross that line without noticing. Software engineering is the process of finding the most efficient solution within your constraints by leaning on algorithm/datastruct fundamentals. For example, you don't look at a tool's marketing page, you look at what it's built upon, how it operates, and based on these fundamentals you understand how performance, reliability, and cost will scale. If the fundamentals are too complex, you might have to do some measuring. If you evaluate or build new tools on this basis, you engage in some software engineering. I don't think this has to be some sort of superior gate-kept thing. It's just a kind of work.

We could make a stretch and claim that there's also "fundamental analysis of maintainability", but I firmly believe[1] that maintainability is subjective. We don't call writers "story engineers", and I wouldn't call any immeasurable and subjective work "engineering".

Edit with additional thought: I think there is a perception downside to both: developer and engineer. The "developer" downside is that you're more likely to be perceived as someone who doesn't care about fundamental analysis, and you focus on getting things to work only in the conditions you're familiar with (i.e. on my machine). The "engineer" downside is that you're more likely to be perceived as someone so fixated on the measurable, that you completely ignore the taste and maintainability aspect (falling into the McNamara fallacy). If you can't measure it, it's not worthy of your time.

There are just perceptions, not reality. Naming is hard.

[1]: https://max.engineer/maintainable-code