One thing I think that is largely ommited is that it's also a relationship with people you have not and may never meet.
Join a new company and pick legacy code from a developer that has departed, personally I cannot help but form opinions of them. "This guy was brilliant", "this guy is a moron", "this guy way over engineered this, and it should be like 2/3 the size. Also why 1000 character line statements?", "why do we have 3 separate caches in the server for the same data along with why does that server have to broadcast a multicast update over the network to update the other caches?". I could go on, but this a sample.
When I look at code that makes me think "why would anyone do it this way?" I remind myself: the programmer who touched this before me very likely had plenty of thoughts about fixing this code, but they probably had good reasons for not getting around to it.
That's certainly true of some less than stellar code I've left behind. It's not for lack of desire to improve it. It's from (1) having written code against a different set of requirements than what they eventually became, and (2) it ain't broke and I have plenty of stuff that is broken.
One of the things I’ve personally learned and been touting it ever since, is that it’s ok not to make perfect code in a hurry or when the real target is somewhere else, if the crude method solves the problem for long enough and is capsulated well enough and the intent of the crude solution is documented and it has tests. Documenting the intent is useful for the next programmer to understand, why the solution has been enough for the needs then and to quiet the DailyWtFs for the next guy poking the code.
By crude solution I mean half-hardcoded or not well generalized methods as the other cases are coming in a year or so. This is also a way to limit the scope and to achieve deadlines. What this means though, is that when new needs arise we need to go ba k and make them better later. Kind of managed techincal debt.
As with all debt, it's not necessarily bad to incur technical debt. You just need to know how to leverage the borrowed funds to turn an even greater profit so that you can pay your debt back later and still come out ahead.
Beginners let their mess metastasize throughout the system. Experts keep it contained to a subsystem. There may be a lot of mess, but each subsystem is messy in its own way, and can be dealt with individually.
While I agree this can be true in general, this is not often the case.
We do mandatory code reviews in our company, and at least a couple of times, I have received a comment which made me go "whoah, this is much better than my idea!", followed by a new version which is 10x shorter and way more reliable.
Being the author of the code in question, I can tell you with full authority that sometimes:
(1) no, I had no thoughts of fixing the code, I did not know it was non-optimal.
(2) no, I had no good reason for not getting around to fixing it. I had no special requirements that would justify my decision.
(3) yes, I just did not think about it. It is like searching for something for a long time and then suddenly finding it in the obvious location -- except this time, I did not find the obvious solution, so I almost ended up committing this huge code monstrosity.
I've had the opportunity to develop behind a "pioneer" at one company - one who developed software as it was needed in an emerging field. I'm grateful to follow behind and have the time to write new code using the old code as a guideline - most of the hard work was already done!
(4) nobody wants to pay for it (i.e. prioritize fixing existing code vs building new features). It only gets fixed when the system is in such a state that new features are nigh on impossible to implement. Until that level is reached, developers just absorb the cost of working with the legacy code base as an externality.
No matter how bad the code is I always remind myself that this ancient code made the company a lot of money which they are now paying me to improve on.
I personally would like to build more digital stuff for things/people/relationships already existing in the 3D world. I see digital technology as a way to make it more useful and convenient way for human beings to communicate, not a replacement for the full human experience.
Sadly, the current neoliberal reality that most people are living in is too cruel and mundane, to the point that the majority have run off to the virtual world to replace the real. The rise of the purely "fantasy" genre in all forms of entertainment, whether it be books, movies, or video games, connected with magical, medieval, and mystical themes that have no relation to the current capitalist world, can be explained by this. Connections such as family members and coworkers, which were previously regarded as "real", is now just a formality, as capitalism dismantles it piece by piece. Interactions with family members becomes a luxury when your job is unstable and continuously worrying about sustaining your household; nowadays this even happens for people in the middle-class. Actually, creating families seem so burdensome, that some even started not thinking about it (hence lower birth rates). And when your coworkers become competitors instead of cooperators set by the fears of job security, the idea of being "close" with your coworkers become a formalism solely existing to maintain your job status. In this depressing setting, some ran out to the new land of virtuality which is the Internet, and tried to create new relationships and interactions there. Hey, they even made their own social structures, cultural habits, and even art, which couldn't have been made in the previous fabric of reality before! (Think of the online forums of the past, gaming communities, web comics, fan art, fanfics, etc...) Are the worlds they live in "fake" and the world they were trying to escape from "real"? For them, the real is as fake as the paradoxes modern society entails, and the virtual world more close to them than the real. I've heard the Japanese is experiencing the rest of the world 10 years faster than then rest of us, and seeing the social phenomenons in the country (rise of subcultures and the hikikomori), our realities are probably fated for a similar path.
The real has become virtual, and the virtual has become real. The "full human experience" that you are urging people to seek, which was previously modernism in the Western civilization, is currently undertaking cracks and erosions. The central modern narrative, which was at first managed by the media and the state, are now being dismantled, decentralized, and replaced by other realities, resulting in a more turbulent cultural climate. (One could view this as a reason why the political climate of the US is so strange nowadays)
Engage in communities in the real world and figure out how to scale participation in them. That is my way of remaining connected in a naturally alienating field like software.
Parts 1 and 2 are also great reads, as they go into the relationship between the changer and the waiters.
It's especially challenging to communicate effectively when the waiter is not a developer. The language of structure vs. behavior is an excellent way to describe the challenges of building a system to a waiter, especially when frustration with a slow perceived pace of behavior change is coupled with a lack of understanding of needed structure. This vocabulary is universal and clearly conveys what is happening- thanks Kent!
Thanks for mentioning this. Read those and indeed fantastic reads. Interleaving structural and behavior changes is brilliant. I already do that, but these write ups give great advice on how to communicate the practice more clearly.
You are so right regarding the communication challenge. But rising to that challenge can be immensely rewarding, both on a personal level and for growing a vision for the emerging software. Big ups indeed to Kent for writing about stuff like this, but also to all you folk who thought it was worthy reading and commenting on.
Join a new company and pick legacy code from a developer that has departed, personally I cannot help but form opinions of them. "This guy was brilliant", "this guy is a moron", "this guy way over engineered this, and it should be like 2/3 the size. Also why 1000 character line statements?", "why do we have 3 separate caches in the server for the same data along with why does that server have to broadcast a multicast update over the network to update the other caches?". I could go on, but this a sample.