kimikimi

The Apple II was the defacto 8-bit machine of choice for most of the North American developers, when looking at the collected anecdotes(Origin, Interplay, SSI and many independents like Jordan Mechner and the team that would form id software were all using them). Becky Heineman had a video where she explained why it was so much better than the C64 and most other options - the I/O and expansion potential was just a lot better on the Apple II architecture, and if you stepped up to the IIGS when that came around you also got some backwards compatibility with more CPU horsepower. Besides displays, the support for multi-disk systems was pretty good, and you could kit out the system to work with a generous amount of RAM and storage for the time. The competing Atari 8-bits also had good expansion capability through the SIO bus and dual cartridge slots which showed some very progressive design, but their potential went mostly neglected by Atari corporate at the time.

The C64 was a budget games machine at heart and didn't have the same kind of hardware support, but its reference manuals are famous for being a great introduction to computing. For many of the beginning bedroom coders this may have made all the difference.

It was way more common to simply not attempt to organize projects in this way "BITD" - it complicates your build system because now it has to manage paths, which entangles it with the OS file system. Not every file system even has subdirectories and not every tool acknowledges or agrees upon how to use them, so depending on how antiquated their dev environment was, it may have been totally impractical.

It's a good question and infects all of our software "sacred cows."

The underlying thing is that we keep driving ourselves to "forward progress" in the sense of a collaborative hegemony, and only in those terms. Either a business wants to own the platform, or the developer wants to build that platform. To do that they have to achieve buy-in from existing stakeholders, but simultaneously reinvent incompatible things. Thus through repeated application of this approach the world of professional software development has aggregated itself into conformance to standards that barely make sense, are poorly specified, and have limited proof of concept, but tick whatever buzzword boxes are relevant to the immediate climate.

If you want to take a real stand, invest yourself in "dead" technologies. Then you can choose whatever you want, and if other people want to follow you on it it's implicit that they are working on a similar problem, and not trying to play the platforms game(else they would be looking for an angle to "modernize")

Visit Japan sometime. The packaged food is good and not heavily weighted towards the "sugar-cream" U.S. norms. Salty and umami flavors are preferred instead and you can pick up a decent example of it from any konbini, everywhere you go.

As the article says about aging, it's a collective problem. We are systematically encouraging ourselves at a large scale to consume take-out pizza and Coke.

FWIW there's a scope threshold that many projects don't always have to cross that justifies using a "real" build tool - and it has to do with those "hairy" parts of file detection and automatically finding dependencies in the shared environment.

If the project allows it, though, your dependencies can be shrunk down until there's no issue. This is far more the case with target languages that already understand modules (e.g. Rust or Python versus C or JS), or "one big framework" projects where you are relying on linking in the one framework and having it do all the heavy lifting on the build side of things.

Actually customizing a build substantially beyond that, tends to be the case more often when you have something like a compiler within your own pipeline, like automatically transforming and clipping source art assets into optimized, UI-ready form. With those systems there is a lot to be said for a simple script that you can debug.

I would be coding now except that I'm travelling in Japan and have not figured out how to replicate my usual "visit Starbucks" pattern yet - they have cafes but not with power outlets, generally, so I have gathered that coming to one tends to mean phone or paper work only.

What I have noticed about my coding habits is that I need a cyclical approach. For a lot of features the task is in fact smaller than I think and just needs an initial direct attack. When it isn't, even if I know what has to be done additionally, I can usually add a stub in the right places and fill it in iteratively. Stubbing often breaks me out of experiencing friction.

This works up until the relevant code stops fitting in my head. Then productivity slows to a crawl and I'm far more likely to wander off. I don't have a direct solution for that. Rewriting the module in question sometimes works, but it seems to work best after I let the existing code "mature". The rewrite tries to preserve the inner parts while changing the context to unlock some more potential.

And there is a hard limit on what I can do before my brain shuts down. There is an aspect of training to it, and energy conservation too. Familiar problems are easy to spam out high quality solutions for - pages of code that just work on the first try. New ones need an R&D phase where the first few attempts reflect a shaky, uncertain approach. At a higher level of evolution - more edge cases, synchronization logic, and state to track - the code tends to require more activation energy, which compounds slowing productivity.

So I currently think explicit iteration might be key: when activation energy feels high, do maintenance work, and if you can't find low-hanging fruit then it might be the right time to do an architectural change(not rewriting the whole program, but changing up the menu of modules and dependencies to reflect current needs). This is especially true if the overall design goals changed along the way because it's hard to change course after you built the features. New designs = new modules.

All of this is a bit different from the work-ethic mode of the article, to which I would point to physical training as the model: You don't go all-out on your training every single day, unless you're a pro with trainers and a good drug regimen that can optimize the recovery time/progression ratio. A more reasonable goal is once or twice a week to push yourself on something you can track easily - lift numbers, time/energy, etc. The rest of the time all goes to recovery or a basic level of maintenance. Distractions during the day mostly reflect wanting to have recovery time, but not having it instituted in a fashion that would do so efficiently - nobody teaches brain work as a thing that needs any kind of rest and recovery period, but the fact of the matter is that making many precise decisions is tiring, high energy stuff. Lowering the precision to "only add stub code right now" is both lower latency and helps conserve energy. Likewise the tendency of code to progress from visual mockup(feature reports itself as working and maybe surfaces an interface but doesn't use the "real" data structures) towards an optimized algorithm reflects an approach of energy conservation.

Most of the interesting optimizations specific to the problem domain of games (e.g. JPS, Theta*) appeared after 2000.

Anyway, the path finding feature is not finished once you have a graph traversal solution. Routing large armies with formations, varying unit sizes, dynamic terrain and collision detection remains fairly challenging in practice.

A corollary to this is that the more a game looks and feels like a fallible piece of software, the more players will react to it like a piece of software, ushering you onto the "infinite demands" feature treadmill in an attempt to make the game feel more complete.

If it all feels adequately justified by the scenario and core premises, then there's an actual resolution. They shut up and play.