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.
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.
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.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programming@programming.dev
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person’s post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
Follow the programming.dev instance rules
Keep content related to programming in some way
If you’re posting long videos try to add in some form of tldr for those who don’t want to watch videos
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 :)