Re:Notes from an Interviewer
by dehrmann on Saturday February 24, 2024 @03:02PM
(#39494691)
My first job was on working on drivers for a proprietary OS. Every time a new board came out, the protocol was to copy the code for the most similar board and start making modifications. It works, but there's a whole lot of repeated logic for common init sequences and logical mapping of memory addresses to what they control. The "simulator" that was widely praised for cutting down on spin-up time for a new board was nothing more than stub code. It all worked and was maintainable, but everything was harder than it needed to be.
[ Parent
| on HN ]
Re:Notes from an Interviewer
by ryukoposting on Saturday February 24, 2024 @03:57PM
(#39495091)
This is almost a word-for-word description of the dev workflow for a proprietary embedded OS I worked on as an intern. Even the "simulator" was what you describe - some #ifdefs that turn the program into a cli program using Win32.
This worked for us because our approach was to "make it right the first time, update only when necessary."
> Every time a new board came out, the protocol was to copy the code for the most similar board and start making modifications
I only saw that happen at one place. It was a bit of a shitshow.
Big corps don't do that, they have a clear internal division between various levels of hardware-independent and hardware-specific components, down to workarounds for specific bugs in specific releases.