The UI on the left isn't labeled, so it's hard to tell what any joke could be if you don't know what it is

I like the sentiment of the article; however this quote really rubs me the wrong way:

I’m not suggesting we abandon AI tools—that ship has sailed.

Why would that ship have sailed? No one is forcing you to use an LLM. If, as the article supposes, using an LLM is detrimental, and it's possible to start having days where you don't use an LLM, then what's stopping you from increasing the frequency of those days until you're not using an LLM at all?

I personally don't interact with any LLMs, neither at work or at home, and I don't have any issue getting work done. Yeah there was a decently long ramp-up period — maybe about 6 months — when I started on ny current project at work where it was more learning than doing; but now I feel like I know the codebase well enough to approach any problem I come up against. I've even debugged USB driver stuff, and, while it took a lot of research and reading USB specs, I was able to figure it out without any input from an LLM.

Maybe it's just because I've never bought into the hype; I just don't see how people have such a high respect for LLMs. I'm of the opinion that using an LLM has potential only as a truly last resort — and even then will likely not be useful.

When I managed a pool, I remember the Virginia Graeme Baker act being something I was told about pretty early on; it was a prevalent enough of a thing that sometimes trying to start up my spa's motor wouldn't provide a clear enough suction, and the motor would shut off for safety. A properly managed pool should never have had this risk.

Last year in February I uninstalled the app on a perfect, 2000-day streak when I got the first whiff of AI; I'm probably never going back

The company I contract with has been pushing hard on getting people to use LLMs (Copilot specifically) in their day-to-day; so much so that they put out a survey to everyone who hasn't used it yet, asking why they haven't used it. One of the questions was selecting checkboxes of reasons you haven't used it; for the "Other", free-form answer field I put:

I'm not about to sacrifice the integrity of my work just so that some venture capitalists can feel justified in roleplaying as useful members of society.

I feel like I'm the only one who prefers the original, gamecube controls. Playing through the switch remake, I played with the new controls for, like, 10 minutes before switching to the original control scheme and playing the rest of the game with it.

From later in the article (emphasis author's)

Earlier in this article I intimated that many of us are already dependent on our fancy development environments—syntax highlighting, auto-completion, code analysis, automatic refactoring. You might be wondering how AI differs from those. The answer is pretty easy: The former are tools with the ultimate goal of helping you to be more efficient and write better code; the latter is a tool with the ultimate goal of completely replacing you.

One of my favorites is from Hollow Knight; at the start of the game, Quirrel makes a comment about your weapon not being very good, saying you should pick one off a corpse as "the dead shouldn't be burdened by such things." Later in the game after you kill the teacher and talk to Quirrel for the last time, when you come back, all that's left is his weapon.

Google en passant

I just hope that when "Kakariko" is inevitably said in the movie, it gets pronounced right

A lot of the complexity came from around various scenarios you could be in; my goto whenever people would ask me "Why can't someone just make printer firmware simple?" is that you could, if you only wanted to copy in one size with one paper type, no margin changes, and never do anything else.

There's just so many different control paths that need to act differently; many of the bugs I worked on involved scaling and margins. Trying to make sure the image ended up in a proper form before it made it to hardware (which as more complexity, ran on a different processor and OS than the backend so that it could run realtime) when dealing with different input types (flatbed scanner vs a document feeder, which could be a everyday size, or like 3 feet long) different paper sizes, scaling, and output paper. I mainly worked on the copy pipeline, but that also was very complex, involving up to, something like, 7 different pieces in the pipe to transform the image.

Each piece in the pipeline was decently complex, with a few having their own team dedicated to them. In theory, any piece that wasn't an image provider or consumer could go in any order — although in practice that didn't happen — so it had to be designed around different types of image containers that could come in.

All of that was also working alongside the job framework, which communicated with the hardware, and made sure what state jobs were in, when different pieces of the pipeline could be available to different jobs, locking out jobs when someone is using the UI in certain states so that they don't think what's printing is their job, and handling jobs through any of other interface (like network or web.)

That's the big stuff that I touched; but there was also localization; the UI and web interfaces as a whole; the more OS side of the printer like logging in, networking, or configuration; and internal pages — any page that the printer generates itself, like a report or test page. I'm sure there's a lot more than that, and this is just what I'm aware of.

I used to work on printer firmware; we were implementing a feature for a text box for if you scanned a certain number of pages on a collated, multi-page copy job. The text box told you it would print the pages it had stored to free up memory for more pages; after those pages had printed, another text box would come up asking if you wanted to keep scanning pages, or just finish the job.
The consensus was that it would be a relatively simple change; 3 months and 80 files changed — with somewhere in the ballpark of 10000-20000 lines changed, — proved that wrong.

I would recommend going and watching the pannenkoek video because it is so good.
The quick version is that it has been known to be possible to clip through the wall to get to the door, but Mario has to be in the walking state to open it. Since the floor directly under the door hitbox is all covered by wall, and the part that isn't covered by wall doesn't have a floor directly below it, it seems like there's no way to actually be in the walking state to open it.
However, by abusing an exploit where Mario finishes his turn around animation the same frame he leaves the ground, the transition to the freefall state is overwritten by the transition to the walking state; this lasts one frame until a check is run next frame — which properly puts him in freefall. Timing the turn around right lets you be past the wall and walking, so you can open the door.

I'm sure there were other consoles that did it, but the one I remember is the NES; it had a physical switch on it for channel 3 or 4, and you had to have your TV tuned to the respective channel to get the game to show up. As to why that was necessary on a technical level, I'm not sure. But it was a thing you had to do.

Just what was in the main repo (at least one other repo was used for the more secure parts of the code) was a little over 4 million lines. But yeah there's a lot of complexity behind printers that I didn't think about until I had worked on them. Of course that doesn't mean they have to be terrible, it's just easier to fall into without a good plan (spoiler alert: the specific firmware I was working in didn't have a good plan)

https://youtube.com/shorts/7haqnQvrYfI

It’s the kind of thing that makes you glad you stopped and smelled the pine trees along the way, you know?

The past is past, now, but that’s… you know, that’s okay! It’s never really gone completely. The future is always built on the past, even if we won’t get to see it.

pushd and popd are also pretty neat in that they allow you to change directories using a stack; particularly useful as part of that is that using pushd without any arguments will pop the directory on top of the stack and move you there, while putting your previous directory on top of the stack. When you're working across directories where you need to move around within each directory, it can be really handy.

As someone who's worked on printer firmware before, it makes me really sad that a company can get away with making a consumer decide between getting access to any of the actually useful changes that engineers — who have no say over ink cartridge policy — put effort towards making the best product they could, or not having said ink cartridge policies forced on them.

The fact that you used the namespace for cout but not for endl inordinately bothers me