You are right to a certain extent.
However, I see several layers we might want to peel off before getting to a sufficiently atomic piece of an implementation to which you can apply your criticism and/or assumptions of intentionality.
The outer layers I am referring to will be related to architectural design and development guidelines, such as the adherence to specific best practices.
Whatever the project you're working on, there will already be artefacts in place that embody the architectural concepts and guidelines in use (APIs, interfaces, classes, frameworks, events, etc.), plus there will be technical requirements related to the specific technologies you are using (hardware, compilers, etc.)
When you peel off all those layers, you're left with that idiosyncratic piece of code you are talking about. But this is usually a very small chunk of code, and its peculiarities will mostly be arbitrary, or optimizations (speed/storage optimizations, compiler specific hacks, etc.), or simply stupid!
Exactly, what I am referring to is usually an incredibly small detail in the grand scheme of things.The small scope and trivial nature becomes hard to see when you're tasked with refactoring something that is considered to be a ball of mud, particularly if its a mission-critical ball of mud. I would never suggest we shouldn't consider contract-level intent, or design, just that there is a parallel for whether these sorts of details actually matter.
You are right to a certain extent.
However, I see several layers we might want to peel off before getting to a sufficiently atomic piece of an implementation to which you can apply your criticism and/or assumptions of intentionality.
The outer layers I am referring to will be related to architectural design and development guidelines, such as the adherence to specific best practices.
Whatever the project you're working on, there will already be artefacts in place that embody the architectural concepts and guidelines in use (APIs, interfaces, classes, frameworks, events, etc.), plus there will be technical requirements related to the specific technologies you are using (hardware, compilers, etc.)
When you peel off all those layers, you're left with that idiosyncratic piece of code you are talking about. But this is usually a very small chunk of code, and its peculiarities will mostly be arbitrary, or optimizations (speed/storage optimizations, compiler specific hacks, etc.), or simply stupid!
Exactly, what I am referring to is usually an incredibly small detail in the grand scheme of things.The small scope and trivial nature becomes hard to see when you're tasked with refactoring something that is considered to be a ball of mud, particularly if its a mission-critical ball of mud. I would never suggest we shouldn't consider contract-level intent, or design, just that there is a parallel for whether these sorts of details actually matter.
Right on. I think the concern (with intent) at the detailed level carries over from the concern at the higher level.
Right, figuring out what level matters or is intentional is definitely a skill!