Low level is easy (2008)

I've found this very true, as I've moved over the years from very "high-level" programming (client/server apps, database-driven web sites) to "mid-level" programming (working on the Firefox browser) and then toward systems programming (working on Rust and Servo). The desire to stop dealing with masses of fragile dependencies keeps driving me lower in the stack. I really need to practice more assembly coding so I can continue in this direction... You get some similar benefits if you are working on…

There was once a programmer who was attached to the court of the warlord of Wu. The warlord asked the programmer: "Which is easier to design: an accounting package or an operating system?" "An operating system," replied the programmer. The warlord uttered an exclamation of disbelief. "Surely an accounting package is trivial next to the complexity of an operating system," he said. "Not so," said the programmer, "When designing an accounting package, the programmer operates as a mediator between people…

Low level code is also easier because it's rarely user-facing. There isn't as much pressure in tech to deliver low level results quickly. Probably also because management doesn't understand low level as much, so engineers have more freedom. You get the time you need to do things right. The most arduous task for me as an engineer is the endless hotfixing of high level code many tech companies engage in, never taking the time to rewrite and solidify the code…

Low level development is often fun and somewhat easy on mature hardware where someone else has already discovered the issues. But on new hardware, you're dealing with gremlins. Physical factors can affect hardware, and sometimes you just can't be sure if it's your code, Cthulhu or position of the moon. For example higher temperature can both decrease or increase crystal frequency. Firmware/software can affect hardware through power consumption and other routes. It can be really hard to know if it's…