90% of my job is spent redesigning and optimizing code that “just transforms XML into JSON and back again.” The problem is when you don’t have a good mental mod

90% of my job is spent redesigning and optimizing code that “just transforms XML into JSON and back again.” The problem is when you don’t have a good mental model for how the code works and how it will evolve over time you make bad design decisions. An algorithm that’s fast for 99% of inputs can be accidentally quadratic for 1% of inputs and lead to major tail latency (group membership in AuthZ systems is a great example) which leads to months of wasted human effort over years because of the bad design decision (and now nobody is at the company who knows how it works anymore). Does this sound familiar to anyone else? The point of learning Dijkstra’s algorithm isn’t to be able to reproduce it, the point is that you know what’s available to you to solve a problem and what areas of the algorithm you can tweak for your use case. If you don’t have a good mental model of how the code works and how you write a maintainable solution then you’re not able to analyze the tradeoffs of the high level competing requirements like AppSec vs UX vs Maintenance vs Engineering Effort that is at the heart of what a software engineer does. And this doesn’t change with AI either, the code that comes out of LLMs is often poorly designed but you can’t tell that unless you have worked on different types of systems to know why we might use immutable data here but shared memory in this situation.