The Curse of Systems Thinkers
<i>”My emails produced only well-worded refutations. They explained quite factually why the setup is the way it is, and implicitly therefore why it could not change”</i><p>This landed so truly for me,
it felt like a punch in the stomach.<p>I wouldn’t dare count the number of times I’ve been told the technical details of why something is the way it is, without anyone ever saying the reason why we actually wanted it to be this way.  My thesis was usually:
<i>we don’t</i>.<p>In my career I feel like I have seen hundreds of examples of me saying the systems equivalent of “lets put the dining table indoors?” to be told that the dining table is outside because the original budget meant the front door could only be yay wide so we had to leave the table in the yard and put a tent over it.  And I’m just left standing there agape at how we eat in a cold wet tent every night instead of fixing it.<p>Except it’s usually more like: why do we have to spend $9k on a commercial dishwasher repair contract? Because we have a commercial dishwasher … to get the rust off the silverware … because we eat outdoors every night … because the front door was too small to get the dining table in the house.<p>Somehow, when the real examples of this stuff are clever engineering around build / docker / polyrepo / release / feature flags / third party bugs, the cleverness makes people think the existence of the workaround should be tolerated.  It’s infuriating to join a new team held hostage by years and years of band aids because they never suffer the bigger picture consequences.<p>The whole article was fantastic.  I hope the author has the engineering leadership role they deserve.  We need more people like this.