[enagrimm]

I've been curious about this for a long time as to how did the people during the old days finish writing software that went on to reshape the world. I mean, nowadays we have an lsp that is there to correct us and give us syntax cause who wants to go through the pain of remembering keywords right? If you're from the webdev world then you have frameworks with hot module replacement or reloading so that we don't have to go through the process of compiling things or the minor inconvenience of saving our files and restarting our dev servers, something that the new generation of devs seem to have no gratitude for at all. This speed with which we can produce software seems to make us too lazy I guess, we don't seem to be that concerned with getting it right the first time and we adopt that attitude of, "I'll eventually fix it.", which often leads to horrendous software experiences. Then there is AI, which kind of takes away the need to really and I mean really learn what we are doing. Just the understanding of how the boilerplate works is something that can only be achieved if we try to write it down and reason about it. But that is gone, ai can just generate that and the people with no experience are expected to write the parts in the middle that connects everything and the problem is that they don't even have the fundamentals down to be able to do that. Basically, developer experience nowadays is getting automated to a level where we'll probably stop having good new programmers.

And that really makes me appreciate the generation that was stuck on a few kilobytes of ram with just a plain text editor making things for the future. I don't even get why we are so ungrateful and unwilling to learn the fundamentals. Where is the humility? Do you really think that the code that an ai wrote that you just copied over proves thay you have any sort of intelligence? Be humble and keep learning.

[wmf]

Dan Luu wrote about this: https://danluu.com/essential-complexity/ "If you look at the complexity of moderately large scale modern software projects, they're well beyond any software project that had been seen in the 80s. If you really think about what it would mean to approach these projects using old school correctness practices, I think the speedup from those sorts of practices to modern practices is infinite for a typical team since most teams using those practices would fail to produce a working product at all if presented with a problem that many big companies have independently solved, e.g., produce a distributed database with some stated SLO.

A version control system that multi-file commits, branches, automatic merging that generally works as long as devs don't touch the same lines, etc., is a fairly modern invention. ...there was still easily an order of magnitude speedup available from better version control tooling, test tooling and practices, machine speedups allowing faster testing, etc. ... For large projects, just having CI/CD alone and maintaining a clean build over building weekly should easily be a 2x productivity improvement"

[PaulHoule]

My CS teacher in high school used to talk about writing FORTRAN code on punched cards in the 1960s where you could “edit” the deck by reordering the cards, type new cards on a punch machine, etc. Remember that 80 columns was the standard width for terminals for a long time because a punch card had 80 columns.

Minicomputers and mainframes had advanced interactive facilities in the early 1970s, you could use BASIC on a PDP-11 and it was about the same as using BASIC on an Apple ][ (no graphics though unless you had a GIGI terminal), edit Assembly, FORTRAN and COBOL programs with the TECO text editor and compile just like you would with C or Go on a Linux machine today. By the 1980s most mainframe development was done with VM/CMS which was a lot like using virtual machines today, to do development you would spin up a VM that ran a single user OS that was a lot like MS-DOS (or maybe it was the other way around.)