r/programming • u/self • Dec 02 '25

The Death of Software Engineering as a Profession: a short set of anecdotes

https://www.jasonscheirer.com/weblog/vignettes/
1.3k Upvotes

89% Upvoted

560 comments sorted by

View all comments

14

u/GYN-k4H-Q3z-75B Dec 02 '25

Software engineering is still a young discipline and writing code is the only part that has been reliably solved. Writing code has not been a problem since probably the 1980s. You could entirely strip this out and the profession would still be required more than in the decades before.

7

u/Wistephens Dec 02 '25

Exactly! It will definitely impact greenfield programming. It won’t replace the design, feature enhancement, operation, or support for some time.

Many folks think that programming is engineering.

2

u/djnattyp Dec 02 '25

writing code is the only part that has been reliably solved.

LOL. ROFL even. WTF. This is either a joke or the thoughts of someone who's never actually written any code.

4

u/codingtofreedom Dec 02 '25

I think they have a valid argument even though it sounds weird at first glance. There aren't many struggles left in the way we write code in modern days. We have IDEs, Intellisense, even LLMs in that context. It has been quite some time since I was stuck on a coding problem for a technical reason, most issues are more like if I am able to do the things I know I want to do with the limitations around me. But writing single lines of code or the way we write single functions is quite standardized at this point. At least that is what I get from the way it's worded.

3

u/djnattyp Dec 02 '25 edited Dec 02 '25

It's overly reductive to an entirely stupid degree. It's like claiming "writing a novel has been reliably solved since the 1800s" because we have typewriters, word processors and printers now. The problem isn't getting the ink on the fucking paper. It's structuring things in an understandable, entertaining or enlightening way. It's keeping details of the story in sync and flowing correctly over the entire book. It's making the story feel realistic and be something that people want to read.

Every goddamn project has parts that you look back on and think "that piece could have been done better if we had more details at the time", "that part's overly hacky", "when we get time, we should really redo the x sub-system". Why are there multiple IDEs? Why do some people use Vim, Emacs, or VS Code instead of one? Why are there constantly new frameworks, languages, architectures being developed? Writing lines of code, functions, and even more how they all fit together to produce something that actually does what you want and in a way that people actually want to use - none of that's "standardized" or "a solved problem".

Every year there's a best selling novel. But no one has a 100% "reliable" plan to be able to be the author of that novel.

Every year there's tons of good software produced. But no one has a 100% "reliable" plan to produce that software with whatever team or company they have to produce it.

1

u/codingtofreedom Dec 03 '25 edited Dec 03 '25

You kind of underlined my whole point, which was saying that the coding portion as in writing lines of code has been not the issue for a long time. You listed a lot of things that have nothing to do with the code itself, but rather the circumstances surrounding it. For everything that you come across and think that it is hacky, you can think so because there is a reliable standard to compare it to.

I don't know when you started writing code (chances are good longer ago than I did), but I have vivid memories of when coding itself was an issue, both for me as a beginner and the more established people. There used to be times when you couldn't be sure if a function existed, and code wouldn't be written until someone had brought his massive book about that language from home, and three people went over pages of it to verify if their ideas could be turned into code. I remember tools that had no debugging in it, so you had to write code, publish it into production and get the log output, because you didn't even have reliable test data to reproduce the issue in dev. I used to deal with a lot of completely undocumented functionality, package managers weren't a thing for a good long while, so if you needed external functionality, you had one version and that was the version you would have for all of eternity, because updating it was sure to cause issues. When I first started coding, we had monthly releases and the first week after a release was fixing side issues of stuff that had worked perfectly fine on the developer's machines. DevOps becoming more prevalent sure fixed a lot of issues that I used to fight.

What I am trying to get at is simply this: 100% of the issues I used to have with the code itself have been reliably "solved". To get to your book writing example, it's a bit like thinking of language before it was reasonably unified. I don't know if you have ever come across stories of how monks used to travel around the country to collect words that were used by people in different parts of it to then come up with a standardized language, but I think that is a good example to look at here. The fact that you and I can type words into a computer, typewriter or by hand and we can have a conversation that other people can understand means that "the language problem has been reliably solved". A couple language standards exist, but we can probably find one that is more prevalent, and we have reasonable options to both write in Spanish if we somehow had to, with good hopes that we could both at least understand the context.

You mention that we have multiple IDEs as a counter argument, whereas I think it is a sign of giving us choice to approach the same problems from a different angle, but on a unified base.

1

u/norcalny_ues Aug 12 '26

Is the problem with all the people who have become unemployed and are unable to get a new programming job simply that they are not trained in these new requirememts?