We spend much "downtime" learning, reading and writing (pseudo) code. Remember, coding was new, access to existing "examples" close to zero, so we had to figure a lot of stuff out.
Paper (no whiteboards either) was an excellent way to tinker, show off and bounce off ideas.
I still find myself writing / drawing a lot before I actually touch a keyboard.
What was considered cheap in those days was printer paper. No problem at all to print out your entire program for going through and editing - with a pencil! - on the long school bus ride. Sounds awful now, but it wasn't, it was just different. Besides, at 40x25 character screen resolution, you couldn't keep that much code "in view" anyway.
Relatedly, you can’t easily comment code willy nilly even with 120 char lines, so paper still has a lot of freedom anyway
Yet they managed to crank out code much faster, and with far fewer bugs, than today's programmers can seem to manage, and higher performing too for anything that didn't require heavy computation (these days, there's noticeable lag, sometimes up to 1s, between typing characters and seeing them on the screen; this never happened in the 80s).
Way way way less lines of code, and they were coding something to run on a single type of machine. They also made heavy use of manual testing before release, because once it was released it was incredibly difficult (and costly) to patch.
If you've ever peaked underneath the hood of games like Final Fantasy 4, it's a lot of spaghetti code held together by duct tape.
The nature of the development process then was necessarily centered on hardware development: the amount of computing logic to run Pong was a small multiple of the amount needed to run a contemporaneous electromechanical pinball, and the amount needed to run Donkey Kong was a few multiples of that for Pong: but the basic premise of "video games" remained close to the pinballs, still built on using timers, state flags and simple lookup tables to do almost everything, which is why the jump arc computation is notable for going into the realm of a real simulation and allowing the software aspect to "flex" a little more. They could have gone with a binary jump using a timer - there were games well after Donkey Kong that did that.
The problems we face now are primarily ones of technical dependency in that configuring a system that does well at typing tests or any other specific metric is weighed against being able to access the standards that require a slower path - we generalized everything to USB and Unicode and JSON and other "not all that fast" standards, and we don't want to give them up, but they also lead to software that is complicated and hard to build.
The reality is that today's programmers, especially in the big corporations, spend a lot of time not doing programming. It isn't too uncommon that something that takes a half decent programmer a couple of days to bang out is preceded by several weeks of running around trying to get approvals and clarifications on different levels.
I guess earlier more trust (and responsibility) was given to the individual developers to decide what to do and how to do it, kind of like in smaller companies nowadays, and with the correct developers that enables a much more productive environment with little to no overhead.
That seems like a pretty wild claim, no?
There was simply a lot less of it. An Atari cartridge had 2kB of ROM. ZX Spectrum had 48kB of RAM for programs. Elite was targeted at the 32kB BBC. The normalized bugs/line and lines/day probably don't look as different as you think.
The real question is: how much of modern code is really new features, how much is dealing with more complicated and less efficient platforms, and how much is busywork from one faction or another within the company?
Yoyozo[1] is a recently released PlayDate game. The first toot about working on it on Mastodon[2] is from Sept. 5 and it got into the PlayDate store on Nov. 21. Elsewhere the creator said he put about a month into it. So a lone dev working on a legacy-like platform can launch a game in a month. I think Yoyozo doesn't have quite as much depth as Donkey Kong (not as many screens, no enemies), but it was made by a lone dev, so it probably all balances out. I think people are basically still capable of the same level of output, maybe a little higher, if they're willing to work on a limited platform.
[1]: https://blog.gingerbeardman.com/2023/11/21/yoyozo-how-i-made...
[2]: https://mastodon.gamedev.place/@gingerbeardman/1110136615210...
Donkey Kong arcade had multiple bugs, one of which was bad enough they had to rush out a fix: https://twitter.com/MarioBrothBlog/status/115587981172793344... (see also https://tcrf.net/Donkey_Kong_(Arcade)#25m_Jump_Bug, and the "kill screen" was never fixed)