46
Software Engineer vs Software Developer
(programming.dev)
submitted
10 months ago* (last edited 10 months ago)
by
fogetaboutit@programming.dev
to
c/programming@programming.dev
In your opinion what's the difference between the two? In my opinion both terms are frequently used interchangeably in the workplace.
But I'd like to consider myself as an engineer, because although I don't consider myself to be good at it, I think I cares about the software that I worked on, its interaction with other services, the big picture, and different kinds of small optimizations.
I mean, what is even engineering?
It’s a huge faff, you will get a different answer from every person you ask. They’re used interchangeably, and it just doesn’t matter.
To entertain your prompt. Real world engineers (structural, etc.) aren’t entrusted the title because they “care” about what they build, it’s because they have to be correct, and as such, they follow extremely rigid process and take the time to never be wrong. Obviously I do not have real world structural engineering experience, but I think we can all agree on this from an outside point of view.
That’s not how software works most of the time, and it’s even heavily discouraged in a lot of the industry. We learn from failure, and the consequences of software failing are nil compared to the consequences of a bridge failing. This is a huge superpower of software, not a weakness, or some sign of deficiency. It is the key reason software evolves so quickly. Software engineers (or developers, alchemists, whatever) are allowed to fail, learn from mistakes, and improve. They can test completely new, never been done ideas, nearly for free, and nearly instantly.
Again, I don’t really care though what the industry wants to call it, developer or engineer. It doesn’t matter and it’s all made up anyway.
I quite like the term Software Alchemist.
To me, the words "engineer" and "developer" both imply that a well thought out and structured plan is in place for them to do their job. Not so with "alchemist", which implies a fair amount of experimentation and uncertainty, both of which are very common in the software industry.
It’s always been one of my favorite ways of describing the job :)