Hey, everyone. Welcome to Developer Team.
My name is Jonathan Patrell. My goal on the show is to help driven developers like you find clarity, perspective, and purpose in their careers.
Today's episode... is going to be very short.
And it's going to be about a very large topic.
Actually, it's about all large topics in a way.
Today, we're going to talk about the concept from philosophy called hyperobjects.
What is a hyperobject? A hyperobject is a concept that is so large that it kind of extends beyond space and time.
There's not really any one point that you could point to.
The concept, for example, the concept of global warming is a good example of a hyper object.
This framework comes from a guy named Timothy Morton.
And generally speaking, this isn't very specific to engineering, but the concept is useful when thinking about Different problems that we might encounter, especially problems that are organization wide at a company, for example, right?
Now, you'd be hard-pressed to compare any problem that you're facing at your company with global warming.
That's not the idea that's being presented here.
Instead... The idea is to think about the shape of the problem that you're trying to solve And it may be as far as the problem is concerned with your particular scenario.
You can kind of treat it as if it is a hyper-object, even though the philosophical definition of this from a humanities perspective perspective is much larger.
So what does that mean? Well, let's imagine kind of the opposite, right?
The opposite of a hyperobject would be a very clear... point-in-time Concrete object right and so you can think about this kind of like as a as a spectrum from a very clear point in time concrete object to all the way to something that doesn't really have clear boundaries.
The boundaries are not really obvious. There's a couple other properties that this philosophy identifies about hyperobjects.
One of them is that it's very viscous. It's kind of an interesting word to describe a problem that you might be trying to solve.
It's viscous. What this means is that it kind of shows up everywhere, right?
It's what Morton would say is sticky. The problem is showing up on all of the surfaces that it touches.
So what are some problems that you might see in an engineering team that you could sort of treat as hyperobjects?
A couple of simple examples might be something like tech debt.
And the reason for this is because tech debt is more or less as a concept.
And it's a very large concept that a lot of people treat very differently.
It doesn't have... super clear boundaries on exactly what is or isn't tech debt.
Companies very often, every company I've ever worked at, has tried to put some kind of boundaries on what work it would consider technical debt.
What work does it consider kind of like optional technical improvement versus product work?
This is a very common separation. But as you move forward in time, some of those things that previously were considered tech debt either go away entirely because they were taken out, you know, by some new design, right?
They might evolve into much more important work because of some kind of scaling or a situation change.
So you can see how the boundaries of what tech debt is in a given situation are not incredibly clear.
And so if you're looking at a hyperobject problem, or a problem that kind of looks like this amorphous shape, There's a couple of things that would be considered kind of anti-patterns.
Bad Bad approaches to trying to solve hyperobject problems.
One of them might be trying to fix the problem.
That sounds attractive. It sounds nice that we might pay down our tech debt backlog.
But because of the nature of the problem, it is essentially an unsolvable problem.
Instead of solving this with a specific effort, your efforts need to match the shape of the hyperobject in its characteristics.
So what does that mean? It means that whatever efforts you're using to solve this particular type of problem where the edges are fuzzy, the efforts will also be Fuzzy.
If tech debt doesn't go away, then the solution to tech debt doesn't go away either.
You don't run a one-time tech debt program. and then call it done.
This is not something that lives at a point in time.
There's something that instead stretches out.
It is a conceptual model. uh that that can't really be contained it can't really be you know in in the in a very formal sense it can't be solved So, Some other examples of this might be things like user experience or developer experience, right?
Even things like performance management.
These are concepts that we try to put frameworks in place.
Now, I want to kind of draw a distinction between framework programs, right?
In other words, you're going to practice performance management as an engineering manager.
You may have performance management conversations.
You may have calibrations. You may have promotion conversations.
You have all of these kind of individual atomic events that happen, but there's not a solution to performance management.
There's many different responses to the existence of this problem. to the existence of the hyper-object that is performance management.
So we need to think about this in terms that are less concrete because the problem is not concrete.
When we try to create a framework for solving these problems, which can be effective for getting things that we care about, what we're essentially doing is we're trying to determine a part of this problem, or we're trying to maybe take a snapshot in time, that's essentially what we do. when we have a performance management conversation, when we set up some kind of expectations for engineers using a, you know,
A competency matrix, right? This is a snapshot in time.
Could we say that we've solved performance management... with a competency matrix?
I don't think so. In fact, I know that that's not going to happen because our jobs continue evolving.
And this is exactly what a hyperobject does.
The hyperobject travels along with time.
It doesn't become a solved entity it doesn't leave you don't leave it behind right You're not gonna leave tech debt behind.
You're not gonna leave user experience behind.
You're not gonna leave performance management behind.
These are all kind of practices, right? but they're practices that show up in the generic shape of a problem.
And so because the edges are fuzzy, because it's hard to say, what is the definition of done?
When you're trying to operate on a hyper object like performance management, there isn't one.
Instead, what we do is we kind of take snapshots.
We snapshot in time, we snapshot a particular effect So instead of saying we're solving performance management, we might say that we're trying to scale the company in order to meet a particular demand.
We're not solving performance management.
We're operating inside of that problem. We're essentially interacting with the hyperobject.
In the same way, this is kind of a freeing idea.
You will never be rid of tech debt. You may have less of it for a certain point in time, but because technical debt is... something that interacts with market forces, because it's something that is a larger problem that exists even beyond your company.
It exists in other companies. And so you may be responding to other people's technical debt by taking on some of your own.
There are an enormous number of considerations that you would have to make that are never gonna be able to be made in total, right?
So you may be able to respond to however the hyperobject is acting in If we want to kind of personify technical debt, technical debt is going to continue on its journey.
It's going to continue growing or shrinking.
It's going to continue responding to other forces, market forces, hiring, you know, even technical forces.
So there may be some kind of technical change in the environment. that implies that you have less or more or different kinds of technical debt that you need to adopt into your working environment.
So what we should do Instead of viewing these hyper-objects as something to try to be contained, We should instead focus on what are the outcomes that we care about inside of this problem.
We're never going to get to the outside of it.
We're never going to contain it. We're never going to finish designing, right?
Design is another, it's kind of similar to user experience, right?
Design is an always happening thing. It's an emergent property. of the work that we do.
So we're never going to be quite done with that.
And it's not, I also want to draw another distinction here that it's not because we are overly perfectionistic.
That's not the same thing as what I'm talking about here.
Instead, The concept of being done with design implies that there is some terminal state.
There's some terminal landing point where...
No more problems emerge that are under the umbrella of design.
If you were to land at that point, then this hyperobject kind of goes away, right?
Another example of a hyperobject might be hunger.
This is something that will always be responding to different forces, a very dynamic system.
And when I talk about hunger, I mean kind of a worldwide phenomenon.
Does it change over time? Absolutely, right?
We have hunger, you know, worldwide hunger. especially as a phenomenon that people experience individually, has gone down drastically.
But it doesn't mean that the concept is gone.
We can't suddenly stop hunger. Hunger is something that happens as a part of life.
You know, the experience of being human, it changes over time.
The kinds of food that we have access to change over time.
You could imagine that hunger is actually a larger concept that goes beyond just desire for food.
It may actually be a relationship to food, right?
So there's all of these ways that these kinds of problems are intractable.
You can't really put a container on them.
You can't really find them in space and time.
No one person can really fit it all in their head usually, right?
Multiple people have different angles on the same hyperobject type problem.
And so if we can let go of this, you know, kind of core driving thing idea that we might have a solution to this one day.
Instead, we accept that we never will. right if we accept that instead we should look at different problems or at least uh look at a snapshot of that problem um then we can more justifiably spend our time on certain initiatives, right, on certain projects that might take out an important chunk. of what we would call technical debt.
Or we do away with the term entirely and we opt out of interacting with the hyperobject and we instead kind of characterize that. you know, as some different category.
There's a lot of kind of semantic meaning, right?
This language meaning, right? when we start talking about these philosophical concepts, but it's a useful framework because the language is how we talk about this together and how we conceptualize the work that we should or shouldn't be doing.
Language and semantics are really how we develop things like goals and definition of done.
It's how we define derive some kind of requirements for products that we're building.
So it is important to be able to conceptualize these ideas this framework or way of thinking about big problems that are intractable.
My hope is that if you're listening to this, and you've encountered this kind of initiative where you really wanna kinda take on the world, you wanna take on the entire tech debt backlog, pay it all down,
And then try to keep it all down. Hopefully this will help you kind of reset your thinking around these larger problems that are never quite solved.
Done. Thank you so much for listening to today's episode of Developer Tea.
I hope you enjoyed this episode. We are continuing to record these. both audio and video now.
This is after 10 years of doing this podcast.
We finally started doing. video. We're going to be rolling out these videos over the next month, two months, three months.
It takes some time to change our processes so that we have a video editing aspect to what we're doing with production.
So thank you for your patience. Thank you so much for listening.
If you enjoyed this episode, please do a couple things you can do.
One, you can leave a review in iTunes. You can...
Like, subscribe on YouTube if you find this on YouTube.
You can join the Developer Tea Discord community and come and talk about these episodes.
That's at developertea.com slash discord.
It's totally free. Always will be for people who listen. to this show.
Thank you so much for listening. Until next time, enjoy your tea.
