<center> All Systems are Human Systems === *Written by Max McCrea. Originally published 2021-05-12 on the [Monadical blog](https://monadical.com/blog.html).* </center> My first ever job in software was at as startup full of brilliant minds and big egos. I was junior, and my desire to learn from these amazing people meshed well with my non-threatening "intern" title as I found myself bouncing between teams asking a lot of questions. I spent a lot of my time presenting what I understood to be the opposing ideas of one team to another on technical issues, with an "explain to me why they're wrong" approach. In retrospect, it was a pretty dysfunctional environment full of people more interested in being right than finding workable solutions to problems, but it was perfect for me at that moment, and I went home each day feeling completely exhausted from learning more than I ever knew I could learn in such a short time. Surprisingly, I think that one of the most eye-opening moments (of many) I experienced there was entirely non-technical. It came from a new hire, an old hand who was brought in as head-of-something, someone who seemed to be as technically accomplished as he was charismatic. Seeing how much time I'd been spending playing devil's advocate, he asked “Do you see how all these technical problems are really just people problems?” This was a bit of an "aha" moment for me at the time, but the lesson I walked away with has since grown in scope, beyond what he likely meant at the time. The more I looked, the more I saw technical problems as people problems. There were no purely technical decisions anywhere. In fact, all systems in the field of software engineering are human systems.  Humans decide what to build, humans write the code, and humans are the ultimate beneficiaries. The software runs on infrastructure that is designed and maintained by humans, and software that is not tended to by humans drifts into disuse. And so, no matter how great your ideas may be on a technical topic, it won’t matter if nobody else can see why they’re great. That means you’ll need to express ideas in a way other people can understand. Sometimes an insight, eloquently explained, is enough. This is especially true in cases where there’s a clear-cut best way to solve a problem. But even in this case, the message really matters! Despite coming to equivalent conclusions at approximately the same time, the approaches that Alonzo Church and Alan Turing took to explain their theories are not the same. Few can explain Lambda Calculus, but most people with a computer science degree can explain a Turing Machine. But often, in the realm of engineering, solutions are not so black and white. Often, solutions have tradeoffs: some benefits, and some drawbacks, which must be weighed against one another. And, in the messy, wet world of human beings, those benefits and drawbacks may not look the same from one perspective to the next. Perhaps an engineer with a background in mathematics finds a pure-functional approach to a problem intuitive and elegant. And perhaps their neighbor with a background in logistics prefers to reason about state transitions. Code that looks clean to one may look confusing to the other, and vice versa. Similarly, a brilliant solution to a problem is worthless if poorly understood. Codebases are rarely single-person affairs, and a codebase full of esoteric design patterns, even if they are elegant and clever (especially, maybe), can hold a project back as other developers struggle to contribute to it. This means that, sometimes, explaining a solution to a teammate, or pair-programming can be more efficient than simply implementing that solution oneself, in a “teach a man to fish” kind of way. The more one understands that others don’t, the more valuable ones’ communication abilities become! Teaching, understanding, and convincing are core skills inherent to the field of engineering, because no technical problem can be siloed away from the politics of the human world. The best engineers not only understand their problem space, but also have a model of their team’s understanding of said problem space. They can identify the mismatched assumptions that might otherwise drag out disagreements, and know how to express ideas in a way that is useful to the team. The best engineers know how to ask the right questions, and when to listen. And the best engineers are convincing. <center> <img src="https://docs.monadical.com/uploads/upload_eda1c07d2c02c13df92bf91c0c1693ab.png" style="height: 40px; width: 40px; margin: 20px"/> <img src="https://docs.monadical.com/uploads/upload_eda1c07d2c02c13df92bf91c0c1693ab.png" style="height: 40px; width: 40px; margin: 20px"/> <img src="https://docs.monadical.com/uploads/upload_eda1c07d2c02c13df92bf91c0c1693ab.png" style="height: 40px; width: 40px; margin: 20px"/> </center> To cloudy things further, remember that all systems are human systems. And so the benefits and drawbacks of solutions are often, ultimately, benefits and drawbacks for individuals, or groups of humans. This means that many decisions that look purely technical on their face are in fact political decisions. How a codebase is written will affect who is best suited to use it, and who it best suits. An extreme example of this are social media algorithms, which dictate the content to which large populations are exposed. Here, small changes in mathematical models bury some voices, and amplify others. But more often, the inherently political nature of technical decisions are much more subtle. Image software that tracks parking rules on city blocks to make parking easier. To benefit from such software, one must own a car. Perhaps the development resources could have gone into software that benefited people who did not own cars. And perhaps the reduction of income from parking tickets, combined with the increased appeal of driving a car downtown, results in decreased investment in public transportation. Sometimes technical decisions affect people in intended ways, but they nearly always affect people in ways that were unintended by, or even invisible to, those who made them. If they’re lucky enough to have the right engineer’s ear, maybe that effect will be taken into account in the next iteration. Or, if the engineers in question are paying enough attention, they might notice it themselves. Because we can only solve problems we understand, those with the resources to solve problems tend to solve the relatively narrow band of problems they are already familiar with. In order to broaden the scope of problems we are capable of addressing, we must pay attention to the world around us. There’s no escaping the messy, political system that binds us. Whether it’s the scope of our own team or the broader scope of the world we exist in, the better we understand those human systems, the better we become as engineers. --- <center> <img src="https://monadical.com/static/logo-black.png" style="height: 80px"/><br/> Monadical.com | Full-Stack Consultancy *We build software that outlasts us* </center>