Saying “front end is not proper software engineering” is bullshit but at the same time if you hire someone to write code and then ask them to write CSS I can understand being frustrated.

Literally the only time I’ve ever run into that is when I was trying to manipulate the path it extracted to. In 99% of cases I’m doing tf, xf, or cf plus flags for the compression type, etc, and those differences are irrelevant.

I’ve had success with Claude, but there’s always a layer of separation. I ask it to do something, read what it produced, and decide if it’s garbage or not. And rewrite or discard as necessary. Though counting by LOC mainly I’ve used it for writing tests.

If you are submitting work, you should understand how the code you're submitting works. Sure, you don't have to know exactly how the code it calls works, but if you're submitting code and there's a block of code and you have no clue how that block works, that's a problem.

nasm is an assembler though, not a ‘languages’

That's like saying "clang is a compiler though, not a language". It's correct but completely beside the point. Unless you're writing a compiler, "cross platform assembler" is kind of an insane thing to ask for. If want to learn low level programming, pick a platform. If you are trying to write a cross-platform program in assembly, WHY!? Unless you're writing a compiler. But even then, in this day and age using a cross-platform assembler is still kind of an insane way to approach that problem; take a lesson from decades of progress and do what LLVM did: use an intermediate representation.

If your job is to make websites and you make sites that don’t work on a browser that has over 100 million users you’re not doing your job.

I thought there was security code to stop that kind of thing. Granted, it's been over 10 years since I've done anything with Java more than tinkering with Minecraft mods.

Go is just as easy. Install the compiler, write a file, compile it, get an exe. And a lot less foot-guns.

Be my guest 😊

Do you recall what the presentation was called? I built a pipelined packet processing system (for debugging packets sent over an RF channel) which sounds like a fairly representative example of what you're talking about, but it's not obvious to me how to naturally extend that to other types of projects.

What does Go’s simplicity have to do with dependency injection?

In my experience, following Go's philosophy of simple solutions eliminates the need for complex solutions such as dependency injection.

How do you unit test your extremely complex projects if your business logic carries the additional responsibility of creating objects?

I write modular code that accepts interfaces so I can test the components I want to test. The vast majority of object creation happens at initialization time, not in the business logic. For the projects I've worked on, that would be true with or without DI - I don't see how that's relevant.

perhaps your “extremely complex projects” wouldn’t be so extremely complex if you practiced dependency injection?

When the CTO says, "Make it distributed and sharded," I do what I'm told, but that is an intrinsically complex problem. The complexity is in the overall behavior of the system. If you zoom in to the individual execution units, the business logic is relatively simple. But the behavior of the system as a whole is rather complex, and DI isn't going to change that.

Maybe three times in my career (10 years so far)