Good engineers will produce more good code, because they ask the right questions, know what good looks like and check the output.
Bad engineers will produce reams more bad code. The mistakes they make will be amplified. They will give wrong and incomplete instructions, won’t see what the problems are with the result and will ship it anyway.
This amplification also means people will spend a larger proportion of time reviewing than coding, which I think is less interesting.
All of this is stuff that can, to some extent, be addressed with policy. You help and instruct juniors, encourage people to better understand and own their code, or at worst reprimand them if they don’t.
You can adjust expectations of product managers and explain to them that more is not better, as it always has been. Faster development can often come with bugs and tech debt and this is more of the same.
All I’ve said above is puts aside the ethical arguments of using or not using AI of course. That’s a separate can of worms entirely.
No matter what framework or language you are using, AI can make the development process faster. It can help you debug a problem, write tests and refactor code. In some situations, it will be faster than writing code yourself, in others not.
That’s true, but spaghetti code was always faster to write than good code before as well. I will agree that the speed gap probably has grown though. That’s why tools like AI need discipline.
If managers and engineers don’t understand that their code will turn into garbage and the business will get reputational harm and lose customers / get sued / have more tech debt to fix and they’ll eventually learn their lesson. In the meantime it’s going to be a painful process where upper management see extra speed, expand their scope or downsize their staff, then learn that they have crumbling foundations and need to adjust. This has publically happened a few times already. Things will stabilize in time.
Complication is, broadly speaking, much of the decision making only thinks to when their current bonus stock vests. So long term thinking is not well rewarded. If you think long term, then your short term thinking competitor screws you up long enough anyway.
I strongly suspect the next step is for a dramatic reduction in the compensation for software development. If it’s not really significantly any more profitable than another trade, then you won’t see as many people who seem to actively hate it trying to do it anyway.
Reminds me of a conversation I overhead, a guy trying to impress a girl with how much money he was going to get back in college. He was going into software development to make big money. Girl asks “but I thought you were majoring in communications, why do that if you want to do software?”. “Oh, well, I tried but I couldn’t understand the course work, so dropped it, figured I’d just get some degree, and then just get some certification and do software development for the money without the dumb coursework”. Basically since the late 90s we’ve had a flood of those types, and this phenomenon just exacerbates the problem.
Good engineers will produce more good code, because they ask the right questions, know what good looks like and check the output.
Best code is the code that is never written in the first place. But that concept is difficult to explain and measure for management purposes. Just because “AI” can automate well-structured, tested boilerplate for “good” developers does not mean all that boilerplate should be there.
Amen. And LLMs have a bias for producing text. And the more questions I ask it, for example to solve more edge cases, it quickly escalates on the existing suggestion rather than find a new approach.
Bad & meh engineers get praised because they “waste” less time directing ai and reviewing output - barely working is good enough in the race to market.
I’ve seen things as serious as a privileged user for one customer having admin access to all customers being discovered during the last minute pentest literally days before the planned product launch. That product is supposed(and likely will) to move 250M USD for customers in the second half of this year. Under the current policy at my day job, coming all the way from the top, reviewing ai generated code at all should be an exception reserved for 0.1% most critical code. Yes, in finance.
I was working in a university town, happened to get hired in at decent market rates by a biomed startup that didn’t mind paying for me. When they left town, I stayed, and a precious few other companies would pay “my rate” - so I ended up cold calling on quite a few places just to see what they were about. I stumbled into the software development manager’s office of a company that did ATM and POS software - they used the same tech stack I was using for biomed. After a few minutes the manager stopped the conversation and said “sure, fine, I want you, but: can I afford you? What’s your current salary?” I told him, he laughed and said: “Well, I’m the highest paid software guy in the building and I don’t make half that. Mostly we hire kids from the Uni who think they want the experience, they turn over every few months on average. I’ve told management how bad that is for the quality of our software, they don’t care.”
No it’s not because it causes brain damage. If you look at slop all day you no longer produces good code even you’re good engineer, you’re producing slop code because your standards keep getting lower and lower until you become bad engineer but you even haven’t figured it out. If good engineers would produce good code with AI we would have working software. Look how quality of software lowered after AI. We used to say that developers from coding bootcamps were bad now we’re lowering standards even more to praise investors.
If you put in the same time and effort creating software using AI that you would have put in coding by hand, in my experience you get better software, much more thorough documentation and automated testing, and fewer “oops” moments down the line. Not perfection, but better.
If you just give a loosely specified prompt and take the first functional looking thing that comes out, you can get code 10x faster than ever before, and it’s going to be a 100x bigger mess to maintain.
A rule of thumb (aka useless constant applied to imaginary metrics) that my colleagues and I have found is: 80%. Work on an assumption that what you get back from each AI pass is about 80% good or right. Work to identify the 20% that needs more refinement, do another pass, now you’re up to 96% good - and honestly probably already better than most first pass ready for a pull request code we used to submit 2 years back. Do a third pass on that and you’ve probably got something that’s not going to give any trouble in all but some really rare cases, and you got it in about half the time you would have spent on lower quality output.
I have been trying, with limited success, to get our junior engineers to use AI to review their own code before submitting pull requests. Some do a single pass and their PRs are pretty good, one says he “doesn’t believe in AI” and his code typically needs 3-4 review passes before it’s even acceptable, even though he’s clearly using AI to write the documentation. AI review is how they’re finding all these zero day exploits in widely used products, it works, it finds maybe 80% of things you’re looking for (if you keep the scope focused inside its context window capacity.) We are having slightly more success with all the junior engineers by having them submit 5-10 small pull requests per 2 week sprint instead of one big one. This not only helps human reviewers understand the bite sized chunks, it also means the AI reviews are more thorough. It also means the architectural definition steps are much more critical because review of tiny chunks misses more of the architectural level picture.
The biggest ethical question I have about using AI centers on management of management expectations. If management really thinks the human contribution value in software creation has disappeared overnight - I’d look for different management, because that ship just steered straight into an iceberg field. Some of them may pull off the Kessel run in less than 12 parsecs, but most won’t.
I was just planning to do some sort of write up on this topic, although it will be internal only.
Of the three projects I’m currently on
existing code base where AI sometimes has good ideas but almost never able to implement them successfully. This is legacy code, all human generated, and is probably too tightly coupled. Test framework is tightly coupled to the environment so ai cannot run it
new tool implementation to give cheaper and faster context across all repos (Spotify Backstage)
new code base almost entirely ai generated. Much more loosely coupled. There is no test /mock framework available, so it’s all scripts, which the ai is able to run at will to refine its guesses
There’s definitely distinct conditions where ai can be the right tool and can succeed vs when it can’t. In managements blind rush to vibe code everything, they need to better understand where it works and where it doesn’t
In particular, functionality I’m working on this week
existing code base ”modify function x to cover scenario y” at best gives a useful strategy
new code base “implement function x similar to existing code base, but that also covers scenario y” seems to work
It can be like that, and other times it can spit out perfectly good work that similar jobs have taken me a week in the past in under an hour. Depends on the task, depends a bit on how you ask, and depends on the model. Claude Sonnet/Opus 4.5 and higher have gotten pretty good about actually saving time and producing useful results.
Except when trying to draw 3D cats in Blender, I can say with authority now: Opus 4.8 on High/Max thinking still can’t pin the tail on a cat correctly without a half dozen very specific annotated views showing it where it goes. It claims it’s having trouble because the cat is lying down… our cat lays down 22 hours a day, suck it up and learn what they look like already.
This is the first comment section i’ve seen on lemmy with a reasonable discussion about AI use that wasnt instantly downvoted into oblivion for being pro-AI
Usually this place is full of the “EVERYTHING IS SLOP” crowd without any nuance as to how it is being actually used to do small tasks well under the supervision of a qualified person.
This comment thread reads 100% like AI astroturfing. AI is not an amplifier, there’s literally no evidence from any study that’s been done that backs that. That’s just AI company marketing.
The AI company marketing (and development) I see still seems to focus mostly on the “we can give a really non-specific prompt and get a functioning app out of thet” - which is missing the point for my uses of it.
My company is very interested in leveraging the new tools where we can, but not laying anybody off (yet) - I think the target is hoping that our exploration time is being roughly balanced with increases in efficiency, which is more or less how we’re managing it for the past few months.
“AI sucks at X, but sometimes useful at Y… use with caution.” = astroturfing
“AI SUCKS AT LITERALLY EVERY TASK!!! ITS ALL SLOP!!! SLOP SLOP SLOPPITTY SLOP!!!” = only organic discussion and reasonable take…
Look, there are 100s of valid reasons why AI sucks and is unethical… in fact, it’s pretty much 100% built on unethical methods, no doubt…
But “AI sucks at everything and literally has zero good use cases” is not a real argument, but it seems to be the most popular opinion around here.
I disagree with 90% of the pro-AI stuff out there, i’m just pointing out that its rare to hear a reasonable discussin on the topic here that isnt just 100% hate
If AI actually adds value, it should be trivial to demonstrate that value-add in a way that passes scientific rigor.
The underlying problem is that we don’t have a good way to measure code value. Software quality is most closely coporable to a weird combination of scientific paper, mechanical diagnostic, and toy instructuon. And we don’t have good ways to measure those, either.
Note that the headline is misleading – stanford apparently trainded an AI model to “rate code” in a way that agreed with some of their staff and then ran that on a bunch of projects. The “good at simple and new, bad at complex and old” matches my intuition, but isn’t really a stronger test than counting minutes spent in a project or dollars spent on programming with or without AI.
And all AI output is slop. It’s just that for some things slop is good enough.
~Which really should be an argument more for discarding those things than boiling oceans to generate more of them, but capitalism loves doing wasteful things~
Nah, good engineers are retiring, bad engineers are running rampant. You give yourself away calling us engineers, we were never, except for some yearly title increase instead of money. Just programmers, and that is fine. Engineer is a whole other thing from the steam age, my BSc was in Math, worked fine to get me in.
Engineer is a whole other thing from the steam age, my BSc was in Math, worked fine to get me in.
As a mechanical engineer, I would beg to differ. When you strip away all the fancy math, engineering is ultimately about critical thought and solving problems/achieving functionality with limited resources. As one of my professors liked to say, “Anyone can build a bridge to support a load, but only an engineer can design a bridge that just barely holds that load.”
Engineering is an ancient domain that goes back to the very beginnings of civilization and continues to grow with our needs as we progress. Where once it was just mechanical, we now have domains like electrical, materials, and biomedical engineering. If we’ve hit a point where we need engineers who specialize in software, why shouldn’t we welcome in a new domain?
While it does feel weird calling software developers ‘engineers’, that is arguably what they do. It’s no less reductionist to suggest they are just programmers than it is to suggest that mechanical engineers are simply CAD and Excel jockeys. There’s a layer of comprehension about the systems in play and how they can be manipulated that gets lost in the reduction.
My only real sticking point about software engineers where I tend to push back is that Professional Engineer is a legally protected title and indicates licensure, at least in the US. It requires the right degree(s) and several years of work supervised by a PE to qualify for that licensure. The importance of the PE license is that you are recognized as an authority in your field- for good or ill. You can make big decisions, but you will also be held accountable if something goes wrong.
In my experience, many software engineers brush aside the importance of those types of qualifications because their field wasn’t quite as rigorous to enter. As we continue to develop a society where software mistakes can absolutely kill people (e.g. self-driving vehicles, robots, automated decision tools in medicine and insurance, etc) or cause massive economic damage, it’s critical that we decide how software engineers play a role in preventing those things and how we hold them accountable when they don’t.
As a software developer who also has a background in civil engineering and an EIT, I rue the fact that NCEES got rid of the software engineering PE exam before I had a chance to take it.
Does the same argument apply to calling janitors custodians “sanitation engineers”? I’ve seen that some places.
Like, if the word “custodian” is too offensive, then maybe it’s just because the job sucks and comes with stigma, and anything you call it is going to sound derogatory after a few years…
I get that it’s a critical job, and the people in those roles should be treated with dignity and respect like everyone else. The social stigma is wrong, for sure. But simply changing the title doesn’t solve anything…
What? That’s a very different situation than what I was talking about with software development. I thought I pretty clearly outlined the core of what it means to be an engineer- Custodians aren’t doing engineering work. As you said, that doesn’t make the role less important or less deserving of dignity.
Just calling someone an engineer because it sounds better is silly and demeans both the actual role and the work that engineers do.
Yeah the explanation was fine but the “What? That’s a very different situation” seemed unnecessarily hostile. But maybe it just have my panties in a bunch today, it could be me
I wasn’t intentionally trying to be rude, it genuinely took me aback. I’m sorry to have come across that way.
From my perspective, tt felt like you hadn’t actually read my argument and were responding in bad faith, since this comparison is the sort of thing that people say to dismiss software engineering as a sort of thought-terminating cliche.
In my experience, AI is an amplifier.
Good engineers will produce more good code, because they ask the right questions, know what good looks like and check the output.
Bad engineers will produce reams more bad code. The mistakes they make will be amplified. They will give wrong and incomplete instructions, won’t see what the problems are with the result and will ship it anyway.
This amplification also means people will spend a larger proportion of time reviewing than coding, which I think is less interesting.
All of this is stuff that can, to some extent, be addressed with policy. You help and instruct juniors, encourage people to better understand and own their code, or at worst reprimand them if they don’t.
You can adjust expectations of product managers and explain to them that more is not better, as it always has been. Faster development can often come with bugs and tech debt and this is more of the same.
All I’ve said above is puts aside the ethical arguments of using or not using AI of course. That’s a separate can of worms entirely.
So what’s the point then ?
There have been coding frameworks like game engines for decades, if system coding is beyond your ability.
If AI can’t write usable code from the start its worthless.
Maybe you’ve misunderstood something.
No matter what framework or language you are using, AI can make the development process faster. It can help you debug a problem, write tests and refactor code. In some situations, it will be faster than writing code yourself, in others not.
Provlem being is that it is not an equal amplifier.
Good engineer spends a morning going back and forth and maybe gets something done that wild have taken them all day.
Bad engineer puts first draft slop in production in a couple of minutes.
Bad engineer gets to put out something every few minutes, good engineer works too make it actually right instead of merely looking specifically right.
That’s true, but spaghetti code was always faster to write than good code before as well. I will agree that the speed gap probably has grown though. That’s why tools like AI need discipline.
If managers and engineers don’t understand that their code will turn into garbage and the business will get reputational harm and lose customers / get sued / have more tech debt to fix and they’ll eventually learn their lesson. In the meantime it’s going to be a painful process where upper management see extra speed, expand their scope or downsize their staff, then learn that they have crumbling foundations and need to adjust. This has publically happened a few times already. Things will stabilize in time.
Complication is, broadly speaking, much of the decision making only thinks to when their current bonus stock vests. So long term thinking is not well rewarded. If you think long term, then your short term thinking competitor screws you up long enough anyway.
I strongly suspect the next step is for a dramatic reduction in the compensation for software development. If it’s not really significantly any more profitable than another trade, then you won’t see as many people who seem to actively hate it trying to do it anyway.
Reminds me of a conversation I overhead, a guy trying to impress a girl with how much money he was going to get back in college. He was going into software development to make big money. Girl asks “but I thought you were majoring in communications, why do that if you want to do software?”. “Oh, well, I tried but I couldn’t understand the course work, so dropped it, figured I’d just get some degree, and then just get some certification and do software development for the money without the dumb coursework”. Basically since the late 90s we’ve had a flood of those types, and this phenomenon just exacerbates the problem.
Best code is the code that is never written in the first place. But that concept is difficult to explain and measure for management purposes. Just because “AI” can automate well-structured, tested boilerplate for “good” developers does not mean all that boilerplate should be there.
Right. When management counted lines as progress, the software was sluggish because of bloat.
Amen. And LLMs have a bias for producing text. And the more questions I ask it, for example to solve more edge cases, it quickly escalates on the existing suggestion rather than find a new approach.
I’ve read that because they have less and less experience actually writing code junior developers are having trouble analyzing the code produced.
Bad & meh engineers get praised because they “waste” less time directing ai and reviewing output - barely working is good enough in the race to market.
I’ve seen things as serious as a privileged user for one customer having admin access to all customers being discovered during the last minute pentest literally days before the planned product launch. That product is supposed(and likely will) to move 250M USD for customers in the second half of this year. Under the current policy at my day job, coming all the way from the top, reviewing ai generated code at all should be an exception reserved for 0.1% most critical code. Yes, in finance.
Finance software is astoundlingly sloppy.
I was working in a university town, happened to get hired in at decent market rates by a biomed startup that didn’t mind paying for me. When they left town, I stayed, and a precious few other companies would pay “my rate” - so I ended up cold calling on quite a few places just to see what they were about. I stumbled into the software development manager’s office of a company that did ATM and POS software - they used the same tech stack I was using for biomed. After a few minutes the manager stopped the conversation and said “sure, fine, I want you, but: can I afford you? What’s your current salary?” I told him, he laughed and said: “Well, I’m the highest paid software guy in the building and I don’t make half that. Mostly we hire kids from the Uni who think they want the experience, they turn over every few months on average. I’ve told management how bad that is for the quality of our software, they don’t care.”
No it’s not because it causes brain damage. If you look at slop all day you no longer produces good code even you’re good engineer, you’re producing slop code because your standards keep getting lower and lower until you become bad engineer but you even haven’t figured it out. If good engineers would produce good code with AI we would have working software. Look how quality of software lowered after AI. We used to say that developers from coding bootcamps were bad now we’re lowering standards even more to praise investors.
So very much this ^^^.
If you put in the same time and effort creating software using AI that you would have put in coding by hand, in my experience you get better software, much more thorough documentation and automated testing, and fewer “oops” moments down the line. Not perfection, but better.
If you just give a loosely specified prompt and take the first functional looking thing that comes out, you can get code 10x faster than ever before, and it’s going to be a 100x bigger mess to maintain.
A rule of thumb (aka useless constant applied to imaginary metrics) that my colleagues and I have found is: 80%. Work on an assumption that what you get back from each AI pass is about 80% good or right. Work to identify the 20% that needs more refinement, do another pass, now you’re up to 96% good - and honestly probably already better than most first pass ready for a pull request code we used to submit 2 years back. Do a third pass on that and you’ve probably got something that’s not going to give any trouble in all but some really rare cases, and you got it in about half the time you would have spent on lower quality output.
I have been trying, with limited success, to get our junior engineers to use AI to review their own code before submitting pull requests. Some do a single pass and their PRs are pretty good, one says he “doesn’t believe in AI” and his code typically needs 3-4 review passes before it’s even acceptable, even though he’s clearly using AI to write the documentation. AI review is how they’re finding all these zero day exploits in widely used products, it works, it finds maybe 80% of things you’re looking for (if you keep the scope focused inside its context window capacity.) We are having slightly more success with all the junior engineers by having them submit 5-10 small pull requests per 2 week sprint instead of one big one. This not only helps human reviewers understand the bite sized chunks, it also means the AI reviews are more thorough. It also means the architectural definition steps are much more critical because review of tiny chunks misses more of the architectural level picture.
The biggest ethical question I have about using AI centers on management of management expectations. If management really thinks the human contribution value in software creation has disappeared overnight - I’d look for different management, because that ship just steered straight into an iceberg field. Some of them may pull off the Kessel run in less than 12 parsecs, but most won’t.
In my experience the time spent getting AI to do what I want can just be used to write good code in the first place.
I was just planning to do some sort of write up on this topic, although it will be internal only.
Of the three projects I’m currently on
There’s definitely distinct conditions where ai can be the right tool and can succeed vs when it can’t. In managements blind rush to vibe code everything, they need to better understand where it works and where it doesn’t
In particular, functionality I’m working on this week
It can be like that, and other times it can spit out perfectly good work that similar jobs have taken me a week in the past in under an hour. Depends on the task, depends a bit on how you ask, and depends on the model. Claude Sonnet/Opus 4.5 and higher have gotten pretty good about actually saving time and producing useful results.
Except when trying to draw 3D cats in Blender, I can say with authority now: Opus 4.8 on High/Max thinking still can’t pin the tail on a cat correctly without a half dozen very specific annotated views showing it where it goes. It claims it’s having trouble because the cat is lying down… our cat lays down 22 hours a day, suck it up and learn what they look like already.
This is the first comment section i’ve seen on lemmy with a reasonable discussion about AI use that wasnt instantly downvoted into oblivion for being pro-AI
Usually this place is full of the “EVERYTHING IS SLOP” crowd without any nuance as to how it is being actually used to do small tasks well under the supervision of a qualified person.
This comment thread reads 100% like AI astroturfing. AI is not an amplifier, there’s literally no evidence from any study that’s been done that backs that. That’s just AI company marketing.
The AI company marketing (and development) I see still seems to focus mostly on the “we can give a really non-specific prompt and get a functioning app out of thet” - which is missing the point for my uses of it.
My company is very interested in leveraging the new tools where we can, but not laying anybody off (yet) - I think the target is hoping that our exploration time is being roughly balanced with increases in efficiency, which is more or less how we’re managing it for the past few months.
“AI IS AMAZING AND INEVITABLE!!!” = astroturfing
“AI sucks at X, but sometimes useful at Y… use with caution.” = astroturfing
“AI SUCKS AT LITERALLY EVERY TASK!!! ITS ALL SLOP!!! SLOP SLOP SLOPPITTY SLOP!!!” = only organic discussion and reasonable take…
Look, there are 100s of valid reasons why AI sucks and is unethical… in fact, it’s pretty much 100% built on unethical methods, no doubt…
But “AI sucks at everything and literally has zero good use cases” is not a real argument, but it seems to be the most popular opinion around here.
I disagree with 90% of the pro-AI stuff out there, i’m just pointing out that its rare to hear a reasonable discussin on the topic here that isnt just 100% hate
If AI actually adds value, it should be trivial to demonstrate that value-add in a way that passes scientific rigor.
The underlying problem is that we don’t have a good way to measure code value. Software quality is most closely coporable to a weird combination of scientific paper, mechanical diagnostic, and toy instructuon. And we don’t have good ways to measure those, either.
There was apparently one study from Stanford:
https://medium.com/@manusf08/does-ai-really-boost-developer-productivity-a-stanford-study-of-100-000-devs-has-answers-4f64c64ebe97
Note that the headline is misleading – stanford apparently trainded an AI model to “rate code” in a way that agreed with some of their staff and then ran that on a bunch of projects. The “good at simple and new, bad at complex and old” matches my intuition, but isn’t really a stronger test than counting minutes spent in a project or dollars spent on programming with or without AI.
And all AI output is slop. It’s just that for some things slop is good enough.
~Which really should be an argument more for discarding those things than boiling oceans to generate more of them, but capitalism loves doing wasteful things~
And… there it is.
Nah, good engineers are retiring, bad engineers are running rampant. You give yourself away calling us engineers, we were never, except for some yearly title increase instead of money. Just programmers, and that is fine. Engineer is a whole other thing from the steam age, my BSc was in Math, worked fine to get me in.
As a mechanical engineer, I would beg to differ. When you strip away all the fancy math, engineering is ultimately about critical thought and solving problems/achieving functionality with limited resources. As one of my professors liked to say, “Anyone can build a bridge to support a load, but only an engineer can design a bridge that just barely holds that load.”
Engineering is an ancient domain that goes back to the very beginnings of civilization and continues to grow with our needs as we progress. Where once it was just mechanical, we now have domains like electrical, materials, and biomedical engineering. If we’ve hit a point where we need engineers who specialize in software, why shouldn’t we welcome in a new domain?
While it does feel weird calling software developers ‘engineers’, that is arguably what they do. It’s no less reductionist to suggest they are just programmers than it is to suggest that mechanical engineers are simply CAD and Excel jockeys. There’s a layer of comprehension about the systems in play and how they can be manipulated that gets lost in the reduction.
My only real sticking point about software engineers where I tend to push back is that Professional Engineer is a legally protected title and indicates licensure, at least in the US. It requires the right degree(s) and several years of work supervised by a PE to qualify for that licensure. The importance of the PE license is that you are recognized as an authority in your field- for good or ill. You can make big decisions, but you will also be held accountable if something goes wrong.
In my experience, many software engineers brush aside the importance of those types of qualifications because their field wasn’t quite as rigorous to enter. As we continue to develop a society where software mistakes can absolutely kill people (e.g. self-driving vehicles, robots, automated decision tools in medicine and insurance, etc) or cause massive economic damage, it’s critical that we decide how software engineers play a role in preventing those things and how we hold them accountable when they don’t.
As a software developer who also has a background in civil engineering and an EIT, I rue the fact that NCEES got rid of the software engineering PE exam before I had a chance to take it.
I didn’t know NCEES even entertained doing a software engineering license, interesting. When was that?
2013-2019
Source: https://ncees.org/ncees-discontinuing-pe-software-engineering-exam/
Huh, TIL. thanks!
Does the same argument apply to calling
janitorscustodians “sanitation engineers”? I’ve seen that some places.Like, if the word “custodian” is too offensive, then maybe it’s just because the job sucks and comes with stigma, and anything you call it is going to sound derogatory after a few years…
I get that it’s a critical job, and the people in those roles should be treated with dignity and respect like everyone else. The social stigma is wrong, for sure. But simply changing the title doesn’t solve anything…
What? That’s a very different situation than what I was talking about with software development. I thought I pretty clearly outlined the core of what it means to be an engineer- Custodians aren’t doing engineering work. As you said, that doesn’t make the role less important or less deserving of dignity.
Just calling someone an engineer because it sounds better is silly and demeans both the actual role and the work that engineers do.
Okay, so the argument does not apply to that situation. A simple “no” would have sufficed…
It is more useful to explain why something is wrong
Yeah the explanation was fine but the “What? That’s a very different situation” seemed unnecessarily hostile. But maybe it just have my panties in a bunch today, it could be me
I wasn’t intentionally trying to be rude, it genuinely took me aback. I’m sorry to have come across that way.
From my perspective, tt felt like you hadn’t actually read my argument and were responding in bad faith, since this comparison is the sort of thing that people say to dismiss software engineering as a sort of thought-terminating cliche.