Working in Intellectually Hostile Environments
I’ve mentioned before that programming is hard, even more interesting is that fact that a lot of the fact that it’s hard comes from the fact modern computing is layers of abstraction built up to hide the fact that every single thing the system does it ultimately ones, zeros, and math.
Lots of it, happening at speeds that are hard to comprehend.
This is further complicated by the fact that systems were often built in less than ideal ways to deal with a lack of computational speed, a lack of memory, or a lack of foresight.
Then more systems were built on top of those. Then maybe some of the systems were replaced, or parallel paths were built, and interesting optimizations were added. Then the cycle started again.
This means being a good developer requires knowing which paths are safe, why obtuse limitations exist and how to (possibly) work around them. This means that the job requires a solid foundation of what came before, a good sense of craft, and a knowledge of a broad spectrum of tools to build any non-trivial working program, and that trying to understand someone else’s code can range from trivial to mind bending.