3 ms·
So, in this case, the author is referring to "low-level" as being assembler written for bare metal. I actually agree with his position, but my reference for wor
by BirAdam 4y ago
So, in this case, the author is referring to "low-level" as being assembler written for bare metal. I actually agree with his position, but my reference for work of this nature is restricted to the Zilog Z80 and the Intel 8088, and it's also recreational. The ease for me is in two different parts. The tooling is minimal. I don't need to learn much. I can sit down with an editor, an assembler, and a debugger and do whatever I want. The code base isn't large. My version control can be handled in any manner I wish. It's pleasant.
The second I work on something higher level, I am normally talking about work. With work, I am forced into whatever tooling the rest of the team uses. As there are serious deadlines, frameworks come into play to leverage someone else's code as much as possible and reduce how much needs to be done. Higher level stuff also means at least 3 APIs are normally involved (our own, a database/storage API, an OS), but this number can grow if we end up using a service of some sort. There are also multiple arenas. Client, server, and usually also service. There is also the interaction of the team involved, which adds complexity. Debugging takes significantly longer, and it isn't just the OS, the frameworks, and all of that jazz. More code does mean more bugs, but the biggest time sink in debugging is that it isn't all my own code. I don't know it quite as well as I do my hobby stuff. I think this is all rather natural honestly.