Becoming (a) software developer

Listen: if you’re a software developer picking up a book on postmodern philosophy, you might be wondering: “Why? What does this have to do with writing clean code, optimizing algorithms, or scaling servers?” And it’s a fair question. Philosophy, particularly postmodern philosophy, probably doesn’t come up during your daily stand-ups or sprint retrospectives. After all, the majority of your time is spent solving concrete problems—debugging code, building features, or deploying updates—where practical solutions are the goal. But here’s the thing: beneath the technical tasks that fill our days as developers, there’s a layer of thinking that shapes how we approach every problem, every piece of software we build, and ultimately, the world we influence through technology.

And that liminal space is where philosophy unavoidably seeps in.

Thinking about technology

So here's something I hope we can all agree on without immediately going straight to the default fundamentalist-mode jihad that developers are so prone to: software isn’t just lines of code. It’s an expression of ideas. Whether we’re writing a function, designing an interface, or architecting a platform, what we’re really doing is encoding a particular way of thinking into something that can be run on a machine. The code represents logic, patterns, assumptions, and even values that reflect not only the programmer’s intent but also the culture and context in which it’s developed.

And this is where it gets interesting: the philosophical roots of how we think about technology—and how we build it—are very, VERY deep. You might not know it, but every time you sit down to code, there are centuries of intellectual debate quietly humming in the background. Modernism, with its faith in reason, progress, and universal truths, gave birth to the scientific approaches that underpin programming. It helped us believe that we could control complex systems, organize the world with logic, and make things better, faster, more efficient.

But, we’re not in the age of modernism anymore, Toto.

So welcome to postmodernism, where all the things we thought were solid—truth, structure, progress—start to look a little less certain. In the postmodern view, grand narratives and big theories break down, leaving room for more pluralistic, fragmented, and decentralized approaches to thinking. And guess what? This perspective is not just abstract academic fluff. It’s everywhere in the world of software development today.

If you’ve ever worked in an agile team that prized iteration over rigid planning, you’ve already felt the postmodern breeze. If you’ve ever questioned the ethics of data privacy, the power of big tech, or the monopolization of knowledge through proprietary platforms, you’re channeling postmodern thinking. Postmodernism isn’t just philosophy—it’s the intellectual toolkit that helps us grapple with the complexity, ambiguity, and ethical challenges of building software in the modern world.

Moving from Certainty to Ambiguity

One of the core features of postmodernism is its embrace of ambiguity. Modernism loved certainty. In its world, if you applied enough reason and logic, you could figure things out. You could build solid foundations, and everything would click into place. Think of this as the monolithic architecture of the philosophical world.

Postmodernism, on the other hand, is more like microservices—messy, interconnected, and sometimes unpredictable. It loves ambiguity and uncertainty. It’s less concerned with building one all-encompassing truth and more interested in the different perspectives, contexts, and interpretations that exist within any given system. Sounds familiar, right? This mindset is a huge part of how we approach software development today, especially in a world where systems are complex, distributed, and ever-evolving. Try to imagine the waterfall model of software development—those long, slow, sequential phases where everything is planned out in advance, planning phases spanning what seemed like an eternity and documentation taking up several metric fucktons of printer paper. That’s modernism. Now think about agile, with its sprints, iterative cycles, and constant adaptation to change. That’s postmodernism. It’s less about following a single, overarching plan and more about embracing the idea that the world is too chaotic, too unpredictable to plan everything perfectly. So, we build systems that are flexible, that can change and adapt as we learn more. In a way, postmodernism was agile before agile was even a thing.[1]

Of course, this comes with its own challenges. When you embrace ambiguity, you also have to let go of a certain level of control. There’s no neat, tidy ending, no final boss battle where everything makes sense. In software development, that means being okay with the fact that sometimes things break, users behave in unexpected ways, and no matter how much you test, bugs find their way into production. But instead of panicking, the postmodern approach would say: “That’s fine. It’s all part of the process. Just iterate, learn, and keep moving.”

Decentralization and Rhizomes: The Internet of Philosophy

At this point we have to talk about structure—or, more accurately, the lack thereof. One of the favorite metaphors of postmodern thinkers like Gilles Deleuze and Félix Guattari is the rhizome. Think of it as a sprawling, underground root system, where no part is more important than any other. It’s a perfect way to describe decentralized networks, like the internet, blockchain, or even the open-source community.

In modernist thinking, hierarchies are everywhere[2]. Power flows from the top down, and there’s a clear structure to how things are organized. You have control systems in place to keep everything tidy. Software development followed this logic for a long time—think of the command-and-control structures in corporate IT, or the way projects were managed with strict oversight from a single authority figure.

Postmodernism takes a wrecking ball to that tower.[3]

Instead of hierarchies, postmodernism favors networks. Instead of power being concentrated at the top, it’s distributed across many nodes. If you’ve ever contributed to an open-source project, you’ve experienced this firsthand. There’s no single “boss” of Linux. It’s a collective effort, where contributions come from all over, and the system evolves organically. In a way, postmodern thinkers anticipated the kind of networked, decentralized systems we now take for granted in the digital age.

So, when we talk about postmodernism and software development, we’re not just talking about abstract philosophy. We’re talking about the actual structures and processes that underpin the technologies we use and build every day. From the internet itself to the rise of peer-to-peer networks, the postmodern rejection of hierarchical structures is a huge part of how software gets developed and how it gets deployed. And the more distributed the world becomes, the more relevant postmodern ideas are.

Power and Software: A Foucaultian Framework

For now, let's pivot for a moment to Michel Foucault, a philosopher who was deeply interested in how power works. Now, before you say “Power? I just want to code!”, bear with me, because Foucault has a lot to say about the systems we create—and the way those systems shape human behavior.

In Foucault’s view, power isn’t just about governments, kings or pointy haired bosses telling people what to do. Power is embedded in systems—whether those are political, social, or technological. It’s not always overt or obvious. It’s in the norms and rules we create, in the institutions we build, and even in the technologies we use. Software, in this sense, is a form of power.

Think about it: Every piece of software you write or use comes with a set of assumptions about how people should behave. When you design an app, you decide how users can interact with it, what they can and can’t do. When you build a platform, you create the rules that govern the system. And often, these decisions have far-reaching consequences.

Take social media, for example. Platforms like Facebook or Twitter aren’t just neutral tools for communication. They actively shape the way we interact with each other, the way information is distributed, and the way attention is monetized. In Foucault’s terms, these platforms exert power over us—not through force, but through the rules and structures they impose.

This is why Foucault is so relevant to software development. He helps us see that the systems we build have power, whether we realize it or not. And with that power comes responsibility. How do we ensure that the platforms and systems we create are fair? How do we avoid reinforcing existing inequalities or creating new ones? These are the kinds of questions Foucault would push us to ask, and they’re more important than ever in an age where software is at the center of so many aspects of our lives.

The Ethics of Creation

Building software isn’t just about solving technical problems. It’s also about making ethical choices. Postmodernism, with its emphasis on questioning authority and embracing ambiguity, can offer us a framework for thinking about the ethical dimensions of software development in ways that traditional approaches might not.

When we think about ethics in software, we often default to binary thinking: Is this action right or wrong? Should we collect this data or not? When we were children we enjoyed stories with unambiguous ethical structures. The heroes were Good and the villains were Bad but in reality Good and Bad are rarely, if ever, so clear cut. As we get older we realize the truth in sayings like The road to hell is paved with good intentions and the more we learn about the world the more we realize that we are, more often than not, looking at shades of grey. Postmodernism encourages us to sit with that ambiguity. It asks us to consider multiple perspectives and recognize that ethical questions often don’t have neat answers.

That’s not to say we shouldn’t strive to make ethical decisions—we absolutely should. But postmodern philosophy reminds us that those decisions are complex and context-dependent. What’s right in one situation may not be right in another. And instead of looking for a one-size-fits-all solution, postmodernism encourages us to embrace the messiness and think critically about the ethical trade-offs we face as developers.

Imagine for a second that you’re designing an AI system that uses user data to improve recommendations. On the one hand, you want the system to be as accurate and useful as possible. On the other hand, you know that collecting too much data can infringe on users’ privacy. What’s the right choice? Is there even a clear answer? Probably not. And that’s okay. Postmodernism suggests that instead of searching for a universal ethical rule, you might need to weigh the situation, consider the voices of multiple stakeholders, and be open to the possibility that your solution won’t be perfect—but that doesn’t mean you shouldn’t try.

This ethical flexibility is crucial in a world where technology moves fast, often faster than our ability to fully understand its impact. The idea that we need to stay open to change and constantly reevaluate our decisions is at the heart of postmodern philosophy. It’s also deeply relevant to the process of software development, where every decision can have far-reaching consequences, whether it’s in terms of privacy, inclusivity, or accessibility.

Software as Language: Derrida and Deconstruction

Here I have to beg you, dear reader, for some leeway because we are about to delve into Jaques Derrida, a man who is famous (and sometimes infamous) for his concept of deconstruction, which, contrary to popular belief, isn’t about tearing things apart just for fun.[4] Deconstruction is all about looking beneath the surface of a text (or system) and asking what assumptions and contradictions lie hidden within it.

So how does this apply to software? Think of code as a language. It’s structured, it has rules, and it conveys meaning. But, like any language, code isn’t neutral. It’s built on assumptions—about what’s important, what problems are being solved, and how things should be done. Derrida’s deconstruction encourages us to dig into those assumptions, to examine the parts of our code that we take for granted, and to be critical of the things we assume are fixed truths.

Here's something we are all, more or less, well acquainted with - working with a legacy system. The system was designed a decade ago, and it works—mostly. But if you dig into the code, you start to notice things: hardcoded values that made sense for the company ten years ago but are now obsolete, outdated practices that no one questions because “it’s just the way things are done,” or hidden biases in how data is processed. Derrida would say that by deconstructing the system, you can expose those hidden assumptions and open up new possibilities for improving or transforming it.

Deconstruction in software is also about questioning the very tools and frameworks we rely on. Is the framework you’re using helping you solve the problem in the best way possible, or is it shaping your approach in ways you haven’t considered? Are the programming languages we choose limiting our thinking, nudging us toward certain solutions while closing off others? Derrida invites us to keep asking these kinds of questions, to be skeptical of the things we assume to be self-evident, and to be open to rethinking the foundations of our systems.

The Postmodern Developer: Embracing Complexity

So, what does all this mean for you as a software developer? It means that by embracing the core ideas of postmodern philosophy, you can become more than just someone who writes code. You can become a postmodern developer—someone who isn’t just solving technical problems but is also thinking critically about the systems you’re creating, the assumptions you’re working under, and the impact your work has on the world.

The postmodern developer isn’t afraid of complexity or ambiguity. In fact, you thrive on it. You’re comfortable with the idea that the systems you build are never finished, that there’s no such thing as a perfect solution, and that change is a constant. You understand that software is inherently a human endeavor, shaped by the needs, biases, and values of the people who create and use it. And because of that, you’re always looking for ways to make your systems more inclusive, more ethical, and more responsive to the world around you.

One of the most powerful aspects of postmodernism is its rejection of the idea that there’s one “right” way to do things. In software development, this can be incredibly liberating. It means you don’t have to be stuck in a rigid methodology or beholden to a particular way of thinking just because that’s how things have always been done. Instead, you can draw on a wide range of approaches, perspectives, and ideas to tackle problems in new and creative ways.

Being a postmodern developer also means embracing the idea that power and knowledge are intertwined, as Foucault reminds us. The systems we build aren’t neutral—they shape behavior, influence decisions, and affect society in ways both big and small. By recognizing this, you can become more conscious of the power dynamics embedded in your work and make more intentional choices about how your software interacts with the world.

Finally, the postmodern developer is someone who understands the importance of iteration—not just in code, but in thinking. As the world changes, as technology evolves, and as our understanding of ethics, power, and complexity deepens, we need to be willing to revisit and rethink the systems we’ve built. The postmodern developer doesn’t cling to old ideas or resist change; instead, you welcome it as an opportunity to grow, learn, and improve.

Because if there’s one thing that postmodernism teaches us, it’s that the world is always in flux. There are no fixed truths, no permanent structures, no final answers. This can be a bit disorienting at first, especially if you’ve been trained to think that there’s always a right answer, that systems can be perfected, or that progress moves in a straight line. But once you embrace the idea that uncertainty is a feature, not a bug, things start to open up. You start to see complexity as an opportunity rather than a problem. You become more flexible, more adaptable, and more willing to experiment. In a world where software is constantly evolving, where new technologies are emerging every day, and where the pace of change is faster than ever, this postmodern mindset is incredibly valuable.

It’s also why philosophy matters more to software development now than ever before. The problems we face as developers aren’t just technical—they’re social, ethical, and political. They require us to think deeply about the systems we’re creating and the world we’re shaping. Postmodern philosophy gives us the tools to do that. It helps us navigate ambiguity, question assumptions, and think critically about power and responsibility.

So, as you dive into the ideas of thinkers like Lyotard, Foucault, Derrida, Deleuze, and others, keep this in mind: you’re not just learning about philosophy for the sake of it. You’re learning how to become a better developer—one who’s not only capable of writing great code, but also of understanding the deeper implications of the systems you build and how they shape the world around you.

Footnotes

[1] If Lyotard and the gang had ever run a Scrum, the phrase “grand narratives” would have been on the banned words list. Also, probably “waterfall.” Also don't worry if you don't get this, it's just me flexing unnecessarily for the two people who get the joke.

[2] Lobsters. Just saying.

[3] Which is nicer than an airliner and less likely to result in a never ending war in the middle east.

[4] Though some people might argue that when you’re debugging 10-year-old spaghetti code, tearing things apart for fun is a perfectly valid approach. Also flipping the table.