For Jason R., it was an exciting time. His company was trying to break into the telecom market with a new product that they'd get to build almost entirely from scratch. The only part that he wasn't excited about was that the major customers had very specific requirements that his team would have to meticulously follow. In this case, some bigtime POTS operators demanded that all servers must come from Sun, and any databases must be built on Oracle 8i.
One of the applications they were building had to interface with the clients' call data records (or CDRs). The most important use of CDRs is for phone bill calculation, so naturally they were stored in properly designed and indexed tables. The CDRs were stored alongside all billing records, and were frequently accessed by mission-critical internal applications, and they weren't prepared to expose all of that to a third party. So instead, Jason's company would have to construct CDRs on their own from the signaling message flow. Because the CDRs would be processed right away, they wouldn't even need to store them. The tentative architecture called for an Oracle database for CDR pipelining from the front end to the application backend.
When the analysis was being conducted, the team grew concerned with the costs — both in terms of budget and disk I/O. Oracle licenses are incredibly expensive, and there would be a huge volume of CDR data written to and read from the database. Finally, it dawned on someone that the database was completely superfluous since records were processed as they came in. In fact, a single, low-end Sun server with a few hundred megs of RAM could easily handle the CDR generation and application backend.
Excited about their good news, they called up a meeting with the product managers. "We've discovered that we can deliver the product at a fraction of what our original estimates were." The managers left the room, some looking happy, others just looking incredulous.
Later that day, Jason got a call from the VP of Engineering. "Jason, while I understand what you're proposing is technically valid, you have upset the marketing team."
"I'm sorry... did I say something?"
"It's just that they've promised the customer that our product would use Oracle 8i, and now they're going to be made liars. Can you just humor me and add Oracle 8i to the design somewhere?"
"Uh..."
"I have enough trouble politically as it is. I really appreciate this favor!" click
After delivering the news to his team, they argued a bit on what to use Oracle for. Ultimately they delivered the final product with an Oracle database that had a single table which was used to store a handful of configuration parameters.
It was the most expensive individual table Jason had ever created in his entire career.
Well of course. If I trawl the world's collected texts, "Are you sure?" correlates very strongly with the following words being an indication that previous statements were erroneous.
If I used that body of text to make a statistical model and used that model to predict what comes after "Are you sure?" it would very often be an indication that previous statements were erroneous.
"Everyone says that they value directness, and from what I can tell the vast majority of people actually don't."
Well sure, of course we do. We (or at least, a lot of the readers of this who live in a US and similar economic and social system) have learned that it is virtuous and correct to say we value directness. But that's where it stops; it's just a thing that is right to say. Part of the current social interaction protocol. It's then widely understood that many interactions should not be hyper-direct.
What you have observed - people saying they value directness and then not exhibiting it - is the expected behaviour. This isn't a bug.
Like it or not, in many places amongst many peoples, beginning a conversation with zero social niceties or couching carries a negative message that makes people simply avoid interacting with that self-styled hyper-efficient colleague.
"the skills that the new engineering landscape actually requires: system design, architectural thinking, product reasoning, security awareness, and the ability to critically evaluate code they did not write."
These, surely, are the skills they always needed? Anyone who didn't have these skills was little more than a human chatgpt already, receiving prompts and simply presenting the results to someone for evaluation.
That’s a great point, but yes: a lot of devs were nothing more than a glorified LLM and during reviews were just an expensive linter. Reality is catching up to those.
Apropos, I once had a boss who said he was running a headcount reduction pilot and anyone who had the time and availability to help him should email him saying how much time they had to spare. I cannot deny this had a satisfying elegance.
"They exist because the company gets more benefit out of the job existing than it costs to employ those people."
Sure, but there's no such thing as "the company." That's shorthand - a convenient metaphor for a particular bunch of people doing some things. So those jobs can exist if some people - even one person - gets more benefit out of the job existing than it costs that person to employ them. For example, a senior manager padding his department with non-jobs to increase headcount, because it gives him increased prestige and power, and the cost to him of employing that person is zero. Will those jobs get cut "eventually"? Maybe, but I've seen them go on for decades.
Continuing the theme, a new starter at my place (with about a decade of various experience, including an international financial services information player whose name is well known) had never used git or indeed any distributed, modern source control system.
HN is a tiny bubble. The majority of the world's software engineers are barely using source control, don't do code reviews, don't have continuous build systems, don't have configuration controlled release versions, don't do almost anything that most of HN's visitors think are the basic table stakes just to conduct software engineering.
They can not. They can make some average code. On Friday one suggested an NSI installer script that would never bundle some needed files in the actual installer. I can only imagine that a lot of people have made the same mistake (used CopyFiles instead of File) and posted that mistake on the internet. The true disaster of that being that then testing out that installer on the developer's PC, where that CopyFiles may well work fine since the needed files happen to be sitting on that PC, would then lead on to think it was some weird bug that only failed on the end user's PC. I bet a lot of people posted it with comments like "this worked fine when I tried it," and here we are a decade later feeding that to an LLM.
These tools can write average code. That's what they've mostly been fed; that's what they're aiming for when they do their number crunching. The more specifically one prompts, I expect, then the more acceptable that average code will be. In some cases, average appears to be shockingly bad (actually, based on a couple of decades' experience in the game, average is generally pretty bad - I surely must have been churning out some average, bad code twenty years ago). If I want better than average, I'm going to have to do it myself.
And it will run rings around me in all the languages I don't know; every case in which my standard would be shockingly bad (I speak no APL whatsoever, for example) it would do better (in some cases, though, it would confidently produce an outcome that was actually worse than my null outcome).
You left out the key line “and you don’t believe me, wait six months”. These models are getting better all the time. The term “vibe coding” was only coined a year ago, around the same time as the release of Claude Code.
It doesn’t matter if you don’t think it’s good yet, because it’s brand new tech and it keeps improving.
If you don’t think the quality has improved then you haven’t actually been trying it. Any programmer who knows what they’re doing can immediately tell models like Opus 4.6 and Codex 5.3 are much better than models from a year ago. All the objective metrics (benchmarks etc) agree as well.
https://thedailywtf.com/articles/A-Software-Problem%2C-A-Mar...
For Jason R., it was an exciting time. His company was trying to break into the telecom market with a new product that they'd get to build almost entirely from scratch. The only part that he wasn't excited about was that the major customers had very specific requirements that his team would have to meticulously follow. In this case, some bigtime POTS operators demanded that all servers must come from Sun, and any databases must be built on Oracle 8i.
One of the applications they were building had to interface with the clients' call data records (or CDRs). The most important use of CDRs is for phone bill calculation, so naturally they were stored in properly designed and indexed tables. The CDRs were stored alongside all billing records, and were frequently accessed by mission-critical internal applications, and they weren't prepared to expose all of that to a third party. So instead, Jason's company would have to construct CDRs on their own from the signaling message flow. Because the CDRs would be processed right away, they wouldn't even need to store them. The tentative architecture called for an Oracle database for CDR pipelining from the front end to the application backend.
When the analysis was being conducted, the team grew concerned with the costs — both in terms of budget and disk I/O. Oracle licenses are incredibly expensive, and there would be a huge volume of CDR data written to and read from the database. Finally, it dawned on someone that the database was completely superfluous since records were processed as they came in. In fact, a single, low-end Sun server with a few hundred megs of RAM could easily handle the CDR generation and application backend.
Excited about their good news, they called up a meeting with the product managers. "We've discovered that we can deliver the product at a fraction of what our original estimates were." The managers left the room, some looking happy, others just looking incredulous.
Later that day, Jason got a call from the VP of Engineering. "Jason, while I understand what you're proposing is technically valid, you have upset the marketing team."
"I'm sorry... did I say something?"
"It's just that they've promised the customer that our product would use Oracle 8i, and now they're going to be made liars. Can you just humor me and add Oracle 8i to the design somewhere?"
"Uh..."
"I have enough trouble politically as it is. I really appreciate this favor!" click
After delivering the news to his team, they argued a bit on what to use Oracle for. Ultimately they delivered the final product with an Oracle database that had a single table which was used to store a handful of configuration parameters.
It was the most expensive individual table Jason had ever created in his entire career.
reply