Had this kind of problems before in my last assignment. The code was full of antipatterns (imperative paradigm in a reactive architecture), lot of global state and an adhoc messaging system using persistent storage. The was was the misuse of the typechecker with type erasure to silence the compiler and linters were never enabled.

The good part is that I owned the project and never has been forced to lower a bar I raised back up. Bad code is just stress for no good reason.

Bill Gates was 13 in 1968, one year before Unix. I'm not even sure what it meant to be a hobbyist programmer in 1968. Writing Fortran on paper and taking it to a local university to run?

In any case the parent's point absolutely stands - I came up in the 90s too and learning to program or make computers do things back then was largely a matter of reading books and talking to people. You had to really want it, because you had to track down and sift through the information.

> LLM can also be helpful in saying where something needs to be done

Usually, If you don’t know that, you shouldn’t modify the system either. Just because you know how to unscrew a bold, you shouldn’t go about removing the head cover of an engine. Locating the area of interest takes a lot less time than actually understanding how it integrate, the guarantees provided by other systems and the guarantees that it offers.

Modularity in software architecture. By reducing the links between parts of the code, it’s easier for someone else to navigate the system and answer these questions. But it does require careful design and caring about the code. This and other things is what the engineering is about.

Everyone's got to start somewhere. Ideally you'd want to start from documentation and a mentor explaining everything, but sometimes you don't get that. The previous dev is long gone, the docs are clearly insufficient, or it's a dead open source project you're resurrecting. Got to make do and fumble around until you get stuff working.

In my own projects I'm also quite capable of forgetting stuff. Double checking with a LLM whether I forgot about one of the more obscure corners doesn't hurt.

Yes, an entire client/server codebase written prior to AI existing has been made far better. More features that players report work (and I play it myself). Far more performance in a measurable way that is obvious to me and players. It can support larger maps, while running well in excess of 120fps when prior it couldn't get past 20fps. This was multiple performance issues that needed resolving. Not once did I look at the solutions that improved performance. I had Claude do byte and object level comparisons between versions to catch regression. I then played it myself to much joy.

When I release features, players report minor bugs, which I can fix in minutes by simply dumping their complaint into claude.

I worked on this codebase prior to LLMs and made slow progress, with many bugs. I did not know how to approach the performance problems, nor was I able to refactor the project to effectively have test and production environments reproducible. Claude did just fine.

It is 350k LoC, with over 138k as an Elixir app, 60k in tests/scripts, 65k Vue components, 45k JS, and more.

Coding is solved. Many people can't manage software engineering effectively. I don't know how much larger or how much more comparison is needed before this is accepted. Maybe it is "circular" reasoning like the dead comment says.

But it literally just works for me.

I believe the core drive of the automobile was to have a machine-powered carriage. No one wanted faster horses, and it would require taking care of the horses.

The quote is a great example of imagining user needs instead of just asking them.

Do people expect an eternal junior engineer in their teams? Even with a recent hire, there’s a deadline to the onboarding and hand holding process. Generally after three months, you were expected to deliver with no oversight other than peer reviews. It was a good deal for the team. Spend three months teaching, and get a productive team member for two years or more.

Now it’s permanent baby sitting.

It’s not the digital world where you just duplicate an object in memory. You need to find the power somewhere (new contract, generator installation), route it, add management tools (and maybe technicians), and then plug the new gpus. It’s all physical work, which also does cost money, take time, and maybe constrained.

ah this is the category error of the whole bubble.

We are so use to the digital world and the efficiency of electronic markets that it is hard to think of physical constraints in the real world.

> Take a list of files for example. you can run ls -l in a terminal and it will attempt a crude text based formatting of the output. or you can run a full gui filemanager.

ls's output (and a few other programs') are human facing. They're not meant to be machine readable.

> what if there was a command that would produce ls output as a table data structure, run in a sort of terminal that knows how to format a table nicely without the ls command having to include any formatting instructions? this terminal would have support for all sorts of data types and structures to display all of them nicely.

Because that's just complexity for its own sake. What's simpler is to just create a shell alias for a particular view you want. The shell is for interactive usage, with some capabilities for automation. If something better is needed, you write a real program for it.

ls's output (and a few other programs') are human facing. They're not meant to be machine readable.

many shell scripts are using ls as input. maybe a better example is ps. that's even more common i would guess.

the goal that i am proposing is to separate output and presentation. that is way more powerful. make commands with machine readable output, and add a presentation layer that converts that to something human readable.

for backwards compatibility you could call that command "show" so you would have

    ps | grep | sort | show

where every step except the output at the end deals with machine readable data.

future terminals could skip the "show" step and read and format the machine output directly with all the power that this gets you such as the ability to reorder or resize columns, change the sorting order, etc, for the ls case like a gui filemanager, but commandline driven and able to handle any output of any command.

create a shell alias for a particular view you want

which shell alias lets me easily reorder or remove columns from ls or ps output? or change the sorting order with a single key press (like top does for example)

top/htop is a good example btw: it's an interactive interface for the output of ps.

imagine you could do the same thing by just running ps or ps | show? generic enough that it works for most commands producing structured data?

> To use a custom terminal which, not unlike Kitty images, allows generic apps to pass escape codes to control the UI components.

> I'm surprised i've not seen more of this in the past to be honest.

This is what emacs is. It's a text buffer, but text can have properties like how to render, and custom values. then a bunch of commands to manipulate the buffer and it's contents.

Funny you say that, i had always wondered what Emacs was - i should have followed that curiosity at some point. It always looked like a standard TUI, but i thought it required its own executable.

I'll look into that, thanks!

I like REPL, but you can be quite fast with a Edit-Compile-Run cycle. But that require settings a test harness and have the run phase be a test run. It's not as fast and experimental as an REPL, but can be quite nice if you know the test cases for your code.

The parent and this thread are talking about game dev.

> if you know the test cases for your code

IME, most gameplay code is not tested, it’s done by feeling. Quick iteration cycles on feeling, is super important, and most of these sorts of projects have 30+ second boot times (way longer in the days of hard drives instead of SSDs)