It's painful indeed. Today, I watched the price go negative as wind and solar reduced the gas contribution to about 3% of the mix. As that gas mix rose to 5%, the price turned around and became painfully expensive again.

That said, from the review: "open source maintainership as cosmic horror." Genuine laugh.

Do I recall incumbent providers lobbying to ensure that competition be forbidden, so that they can continue to charge a lot for bad service? I think at least a couple of years ago, 16 US states had banned community internet at the behest of Comcast and chums.

I suppose that municipal broadband being banned at the behest of incumbent monopolies and duopolies isn't quite outright banning competition; just making it a lot harder to do.

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.

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.

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.

There was no such time. Even if everyone means "every software engineer" or any variation thereof, and we substitute any other such tool for GC.

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.

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.

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.

The only software I ever worked on that delivered on time, under budget, and with users reporting zero bugs over multiple deliveries, was done with heavy waterfall. The key was knowing in advance what we were meant to be making, before we made it. This did demand high-quality customers; most customers are just not good enough.

The key was this: "the requirements are polished and any questions answered by stakeholders"

We simply knew precisely what we were meant to be creating before we started creating it. I wonder to what degree the magic of "spec driven development" as you call it is just that, and using Claude code or some other similar is actually just the expression of being forced to understand and express clearly just what you actually want to create (compared to the much more prevalent model of just making things in the general direction and seeing how it goes).

Flashback to last job. Wrote their own containers. Opaque.

You ask for an item from it, you get back a void pointer. It's a pointer to the item. You ask for the previous, or the next, and you give back that void pointer (because it then goes through the data to find that one again, to know from where you want the next or previous) and get a different void pointer. No random access. You had to start with the special function which would give you the first item and go from there.

They screwed up the end, or the beginning, depending on what you were doing, so you wouldn't get back a null pointer if there was no next or previous. You had to separately check for that.

It was called an iterator, but it wasn't an iterator; an iterator is something for iterating over containers, but it didn't have actual iterators either.

When I opened it up, inside there was an actual container. Templated, so you could choose the real inside container. The default was a QList (as in Qt 4.7.4). The million line codebase contained no other uses; it was always just the default. They took a QList, and wrapped it inside a machine that only dealt in void pointers and stripped away almost all functionality, safety and ability to use std::algorithm

I suspect but cannot prove that the person who did this was a heavy C programmer in the 1980s. I do not know but suspect that this person first encountered variable data type containers that did this sort of thing (a search for "generic linked list in C" gives some ideas, for example) and when they had to move on to C++, learned just enough C++ to recreate what they were used to. And then made it the fundamental container class in millions of lines of code.

Good for him. Big savings right there. Buying/selling/moving house can cost a fortune.