Often times when reading code written by other people, or even written by myself a sufficient amount of time ago, I fall prey to a sort of choke, a...
For further actions, you may consider blocking this person and/or reporting abuse
Great line.
Was going to say the same thing.
"I figure it has been written the way it has for a reason, with a plan, by someone more well-versed in the problem. Far too often, in my experience, that feeling is wrong."
OMG THIS TOOK ME SO LONG TO GET OVER
what a great quote.
Same here, it took me seeing other people doing the same thing to realize it's kind of an absurd mental backflip.
I like to think of one aspect of this as the invisible path of implementation. It's when you get those
if (!myvar) {...}statements - languages may vary, but there's usually several possible values that result in this being falsy. One of those cases is probably important and should have been explicit, but hey, it looks neater if we don't clog the code up with explicit checks!But, I don't hold with the idea that the original implementer did not know what they were doing and that this code should be refactored. Often, other unobvious constraints like performance, accessibility, the language itself, and the complexity inherent in the problem domain itself can dictate a certain approach that isn't immediately obvious, and creates the illegible code (maybe to the inexperienced eye) and there's no way around it without a serious technology change and/or complete rewrite. And that tends to be the way it's done, creating the cyclical lifetime of software.
And hence, I would suggest the issue is that we lack a programming language that can convey the assertions that make intention, and is still clean enough to ensure they are implemented properly. We haven't reached that evolution yet.
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!
I'm struggling with this because to me, both communicating and understanding the intent of code are necessities. That's why we give classes, methods, and variables descriptive names. Describing intent is also a purpose of unit tests.
Naturally we must at times be able to distinguish between the intended and actual behavior of code. Finding that difference and the reason for it is how we fix bugs. Without knowing intent, how would we even know if code works as expected? How could we do a code review if the coder and the reviewer couldn't communicate about the intent of the code? How could we judge whether it was well-written without knowing its intent?
OP can correct me, but this discusses code once written While in CR, the code is still flexible.
That said, I do think you're onto a point. Literature is art; code is not. This is an art to coding (i.e. "The Art of Computer Programming"), but only in the verb form of programming itself. It's not "The Art of Computer Programs".
Unlike written literature, the code we write, read, and maintain are mutable and mean to be modified for a given purpose. There are certainly critiques that can be be used across both fields, but they'll eventually be limited by the fundamental differences in the two fields.
What I got was that there are two types of optimization.
1) rewriting the implementation of a function to be faster or more efficient
2) making it so that function never has to be called in the first place.
What I think OP is trying to say is that we should be trying to do method 2 a lot often when we refactor, but it can be hard to determine why the function was written in the first place simply from the function's existence.
When I was a junior developer, I was coding for the computer. With more experience, I learned to code for other developers.
Here's a really dumbed-down illustration of how I understand intentional fallacy. After the TV show Lost ended, the creators explained in interviews details like why the characters had to repeatedly enter a series of numbers into a computer terminal. But neither that reason nor the significance of the numbers was ever explained in the show. The reason (intent) is not available within the show and cannot be determined from the work of art. Even if you knew exactly what the writers were thinking, it doesn't count.
My biggest fear with this post was that there was a connection to be drawn, but that whatever point I made would be inarticulate. I think the nuance you and Valentin touched on above is really important to get across, and in trying to tie everything all together I think the post missed that (here I am, trying to explain my intent though :D). If I had another chance, I would put it this way: the intent of the code at a top level (the contract, the API, etc.) should be easily divinable and is definitely important. Down from there, code should still be as clear as possible, but the intentions of the implementation are less important than the intentions of the contract. The costs there are lower: maybe a refactor makes it less efficient or has some smaller effect, but it has less chance of breaking a downstream piece of code if you change some implementation detail. As the choices get more granular, the more likely it is that the intent behind the choice isn't relevant (or maybe doesn't exist). Yes, for sure, at a certain level intent is clear and matters, but at the level at which I have seen friends struggle to make changes, at the implementation choices level, I think it starts to matter less (unless we're talking about a major architectural choice). That being said, I was mostly just trying to draw the connection and start a conversation, and I totally see where you're coming from.