[COFF] Re: [TUHS] Interview question

I like the way Carl Sagan put it: "If you wish to make an apple pie from scratch, you must first invent the universe" I've contended with this a lot in my experiences learning computing, programming, etc. Luckily my earliest interest was in embedded platforms (video game consoles specifically) so from an early point in my study I was already much familiar with the idea of a computer being a mindless piece of inorganic matter we overlay structure on in the form of programs. What that's lead to though is a neverending desire to avoid cruft and outside resources in general, which I've thus far found impossible. Yeah I might replace a driver for a device, but that driver talks through a kernel someone else wrote. Yeah I might replace a kernel subsystem, but it still interacts with everything else. Heck, I might write a kernel, but I'm certainly not writing myself a new browser to run it, I'd be bound to at least providing the same interfaces as others to do anything effective. Even still, that kernel, running on a modern CPU, is probably sitting up on top of at the very least microcode and perhaps even a BIOS or other firmware, neither of which I control. Going even further, say I write a game for the Sega Mega Drive. That console maps the ROM cartridge into low-core, so from the moment the CPU hits the RESET vector, it's my code, and this still​ wouldn't be entirely my own. The algorithms internally applied by various ICs on the board based on what I put in the registers aren't mine. It's not like I'm manually bit blasting the analog CVBS signal being pooped out the back of the thing, someone at Ti and/or Sega decided how that works and packaged it in a nice little video display chip for me. I could write every lick of 68000 code that the CPU touches from poweron to poweroff and still wouldn't be solely responsible for the end result. I'm not responsible for determining efficient blitting routines, scrollplane population, FM synthesis calculations, analog signal generation, nor most of the synchronization. That belongs to engineers at Sega, Ti, and whoever else was involved. This speaks to the necessity of good documentation, because any given part of a system becomes relevant when trying to understand it holistically and truly work "from scratch" on things, because any decision you don't make is still a decision you have to be aware of. There's no aspect of a design that won't be relevant to a consumer of that design at some point, that's why it's there after all. Even with side effects, it's better to understand them than not, as it's almost guaranteed if there is a corner that can be cut somewhere, not only is someone going to figure out how to cut it, they're going to make a mission critical decision based on it and blame the creator when it doesn't work. - Matt G. ------- Original Message ------- On Tuesday, January 3rd, 2023 at 7:57 AM, Warner Losh <imp(a)bsdimp.com> wrote: