If LLMs (since AI is not a thing that actually exists) were banned tomorrow, I’d be pretty grumpy that I had to go back to using the garbage fire that is modern search engines. And I’d be grumpy that I had to go back to writing boilerplate code myself. And then I’d get over it and move on with my life.

😆😂🤣 Are you kidding? Have you tried using nouveau? It works, sure, but you can’t play games that are even vaguely modern and if something uses up a bit too much RAM the entire display system starts jittering/lagging or becomes unresponsive. Source: I ran nouveau with a GTX 2080 for years. I was only able to fully ditch Windows once I fully ditched Nvidia (by switching to an AMD GPU and scrubbing every last vestige of Nvidia’s bullshit off my PC).

Virtually every company I’ve worked at used Office primarily. And by the looks of the other comments your experience seems to be atypical.

I liked it ~5 years ago when it was mostly Git + project management + excellent CI. I agree that it’s gotten really messy since then. Way too many features IDGAF about.

Oh fuck off. I’m not talking about the GitLab instance. Those aren’t hard. The trauma is from other stuff, but it adds a spicy flavor of stress and anxiety to all infrastructure work.

Ok…? That doesn’t change the fact that Microsoft was enshitifying the software they bought before “AI” was a thing. They didn’t suddenly start doing it when LLMs happened.

If your project is easy to maintain (aka low tech debt) that means it should be easy to understand the overall structure and it should be easy to understand any given component. So a new dev should be able to quickly figure out what part they need to change and how to change that part.

Some large, complex systems (like an OS) are unavoidably complex. Maybe it’s not fair to call that tech debt, but it’s still functionally the same thing - stuff that slows down development velocity due to difficulty of understanding. It’s just (probably) unavoidable given the domain.

But the majority of software projects aren’t that complex. The majority of software is apps and libraries that aren’t terribly complex. Monsters like operating systems and million to billion user scale products are outliers.

It’s really more of a bell curve shape. If you’re not important enough you won’t get a big screen. The receptionist may only have a phone.

Why? In my experience using a real debugger is always the superior choice. The only time I don’t is when I can’t.

Huh? Main file? Do you mean main package? A module can contain an arbitrary number of main packages but I don’t see how that has anything to do with this post. Also are you saying modules are equivalent to classes? That may be the strangest take I’ve ever heard about Go.

As far as I'm concerned the advantage is I can have three windows (or three editor views) tiled horizontally and each one is the perfect width. A half width (half of 1080p/16:9) is too narrow and a full width window wastes space, but a 2/3 (of 1080p) width window is about perfect. If I tried to do that with two regular monitors, the middle window would be split across the bezel.

*When I say 1080p, I really mean the aspect ratio. My monitor is effectively a double width 1440p monitor, but with the display scaling I use the space is effectively 1080p.

I wonder how relevant this is to Go (which is what I work in these days), at least for simple data retrieval services. I can see how transforming code to a functional style could improve clarity, but Go pretty much completely eliminates the need to worry about threads. I can write IO bound code and be confident that Go will shuffle my routines between existing threads and create new OS threads as the existing ones are blocked by syscalls. Though I suppose to achieve high performance I may need to start thinking about that more carefully.

On the other hand, the other major component of the system I'm working on is responsible for executing business logic. It's probably too late to adopt a reactive programming approach, but it does seem like a more interesting problem than reactive programming for a data retrieval service.