You Have a Voice. Please Use It.
Probably the most pro-Democracy work of fiction I’ve read this year in a story that is not ostensibly about Democracy is A Drop of Corruption. It is the second in a series set within an “Attack on Titan” inspired fantasy world about mold and fungus giving people special powers so… natch.
... Minor Spoilers Ahead for the Book, So Go Read It First?
And in it the narrator is this young detective assistant who dreams of running off to join the army to do the important work of defending the empire. But the book itself is an exploration of all the ways that power structures seep into our daily lives and how they shape our decisions.
I cannot tell you how deeply I feel this as a Principal Engineer. The joke that a good friend likes to make is pulling up Conway's Law whenever people ask about why easy things are so hard to do. And… yeah. Implicit power structures shape everything. Even the code we write. I’m sorry the whole “I’m here to ship code not be in meetings” doesn’t fly. Thems the breaks. We’re all in this together. Understanding and representing power structures is part of being a good software engineer. And that requires communication.
But often, we ourselves are like Din. We believe the way to use our voices has to be big. It has to be making the big speech, pushing for a big change. Shutting down injustice. On a professional level, I often imagined this looked like being the executive who got to go up on stage and "set the direction" or make the big speech. I thought those were the big important moments of communication.
And while they are important, there are other forms of more subtle types of conversation that play an equivalent, and maybe even more important role. Because, as software engineers we are responsible for so much of the experience of human life now, many of our small decisions will impact many people.
What the book shows is that the way to unravel these injustices isn’t big declarations. Mysteries aren't solved by flashy moments. They're solved by doing the hard work of picking at misunderstandings, diving into disagreements, and pulling out observations and questions in front of the right people to answer them and to take action. It’s understanding the chain of events that led to a particular decision. And then pausing. And then it’s communicating those beliefs clearly and honestly even when it might be hard. And what I mean by that is, you have a need and a purpose to continually share your opinion and your perspective with the people around you. To stick up for your thoughts, the good ones and the bad ones.
Good Software Engineering is Democratic and Democracies require Open And Honest Communication.
The tenets of the First Amendment are woven into much of the practice of software engineering as it exists today. The belief that continuous delivery is built on top of Peer Review, Open Source, and Blameless Post-Mortems are all fundamentally bound by the belief that we are all better when we share our honest perspective (even knowing our perspective is wrong and limited!) and try to learn from each other with curiosity and trust.
Look I’m sure you got into software engineering because you liked code. Maybe you liked vibe coding. I honestly barely care about the difference. Fundamentally software engineering is about understanding how technical systems impact social systems. Every line of code in some small (or big!) way is a political writ. The sum total of which operate as a set of bounds that will guide how people act with the world and their experience of it. It will determine whether or not a large and complex systems is knowable or inscrutable, and whether or not their day gets a little easier or a little harder. Your job is to not simply replicate a belief that someone else declares to you, it is to imbue the systems you create with parts of your beliefs as well.
And we do that by communicating openly and honestly. Even when it is challenging. Even when we might be wrong. Even when we might lose an argument.
But the book is a hopeful one. The bad guy does get caught in the end, even if our detectives are left to deal with the ambiguity of the outcome. There is no such thing as a perfect win, no matter how much we might try. The striving does matter. The right people striving for the right things is why I am still optimistic about the possibility of technology, in the hands of the right people.
Maybe the main challenge that Din faces in the story is that success in any single case feels so small against the immensity of the challenges facing his world. (Both physical and social) And too, in software engineering the benefit of getting one line (or even one PR!) of code right can feel so small against the immensity of the world or even the immensity of the business requirements we're trying to move ever more quickly. It is not just that occasionally our voices feel small, it's that the outcome of using them feels insignificant. But this is also missing the forest for the trees.
Not only do the small actions have direct impact, the small actions are what shed light on (raveling and unraveling) the bigger underlying structure. The number of times I've been in meetings where a single question revealed to someone that the way they'd been considering the problem would have to change and therefor open up whole new sets of opportunities is, to be honest, somewhat immeasurable. Anyone can ask these questions. And if you are in the room, you have some obligation to do so.
Admittedly none of this is always particularly flashy or eye-catching. But it is real and tangible. Code is a small nudge of the universe towards a specific set of outcomes that you, the writer of the code, deems more valuable to the world around you. And those lines of code are written in collaboration with other people, to make the code, in your collective eyes better. It is an incredible thing to have an opinion about the world and to be honest and open about it to work with others to shape the world around you.
You Have A Voice. Use It.