One thing I think that is largely ommited is that it's also a relationship with people you have not and may never meet.<p>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.
Parts 1 and 2 are also great reads, as they go into the relationship between the changer and the waiters.<p>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!