Oddly Influenced

Welcome to Oddly Influenced, a podcast about how people have applied ideas from *outside* software *to* software. Episode 33: Jessica Kerr on /Games: Agency as Art/

Jessica Kerr (known to computers everywhere as @Jessitron) is a software developer, speaker, and symmathecist. (A symmathesy is a learning system composed of learning parts. To Jess, each software team is a symmathesy composed of the people on the team, the running software, and all of their tools. The idea of symmathesy runs through our conversation, though we don’t mention it specifically.)

@Jessitron is another of those people who apply ideas from outside software to software, including in her role as a developer advocate at Honeycomb, a company that aims to make the workings of software visible to its developers. Were she not engaging, personable, and enthusiastic, she'd be scarily like me. This conversation is about C. Thi Nguyen's book /Games: Agency as Art/.

It was an entertaining conversation, though I wish I’d been more focused. I drifted afield from /Agency as Art/ into some of my own obsessions. That’s not such a bad thing because Jess and I have congruent views, and she explains them well. On the other hand, I worry that the core of Nguyen’s book gets lost. So let me recapitulate it here:

Nguyen’s book is about how interesting it is that game designers are mostly designing agency: *what the characters in the game can do*. Because of that, they are crafting the kinds of experiences the gamers will likely have. This all gets especially interesting when you look at multi-player games with different roles for different players.

Jess’s interpretation of the book starts with an observation: a big part of what a manager does is akin to game design. A manager shapes what a team can *do*, and so what they *will* do – and so how they will feel about it, and how what they do now will affect their later experiences. (This isn’t solely a manager thing: everyone on the team is shaping everyone else’s agency.) This shaping gets especially interesting when you look at multi-member teams with different roles for different people.

We didn’t dive into that enough. My fault. I continue to learn my new role as an interviewer. I think that my steering us off-topic did produce interesting responses from Jess. So please keep listening.

≤ music ≥

Brian Marick:
May I call you Jessitron, or do you have a different way that you're usually addressed?

Jessitron:
[laughs] It’s Jess in person, usually: Jessitron if you want to be specific.

Brian Marick:
Okay, Jess, your topic is based on a book called /Games: Agency as Art/. There are lots of words that everybody seems to know what they mean – except I don't – and one of those is “agency.” So would it make sense to start by saying: what are we talking about when we talk about agency?

Jessitron:
So one of my disappointments in this book… which is a philosophy book written by a philosopher, but in super plain, simple language, which is wonderful. But one thing he says pretty early on is, look, I'm not going to try to define agency. However, he does describe agency as having three elements that are important. Agency includes goals: what are you trying to accomplish – goals that you've selected. And then there are rules and abilities associated with that. Abilities are ways you're going to accomplish these goals, and rules are ways you're not: things you won't do.

Brian Marick:
Rules and abilities. Abilities are what you're going to use to accomplish [the goal] and rules are what you're *not* going to use.

Jessitron:
Roughly, yeah. Rules are like boundaries.

Jessitron:
Agency… the word is used in a lot of ways. One way is you can say people are “high agency” if they feel free to take action to change stuff that they don't like. Low agency if they're like, “yeah, well that happened to me and this is the situation I'm in, so it is [what it is].” This book is much more about the different agencies that you might adopt. In /Games: Agency as Art/, the whole point is that when we play a game, we adopt a different agency than the one we naturally, inherently work toward. As a person, I might want to be happy, and I want to have friends and stuff. That's a different layer of agency than: “I'm going to choose to try to get victory points, or get this ball in the goal.” Like in soccer, you adopt an agency of: my goal in life for the duration of this game is to get that soccer ball through that goal and prevent it from going into my goal. And then you have abilities like running and kicking, and you have rules like keep the ball in bounds and time limits and don't smack people in the head. So C.Thi Wynn, the author of /Games: Agency as Art/, points out that we kind of become different people for the purposes of the game. We take on a different agency, where our goals become not our life goals, they become something entirely situational that we've chosen. A big point of the book is that we can choose agencies at all. That as people, we don't just operate according to our personal values at all times, our values don't drive us in every action. Our values don't drive us in every choice of which peanut butter we buy. I mean, sometimes, but also there's which peanut butter is cheaper or which peanut butter is the first one that I saw getting the cart.

Jessitron:
Instead, within each situation, we have our purposes. We do that very explicitly in games, which is the easiest place to see it. What I notice is that we do that at work. At work, we choose to adopt the agency of: what does my team need to accomplish? What does my company need to accomplish? And that isn't the same as our purpose as human beings.

Brian Marick:
Now is there an assumption that we actually have a single purpose as human beings?

Jessitron:
You know, I feel like, like I was raised and grew up thinking that, yeah, our job is to have a single purpose, that we should be consistent at all times in our priorities. When I was growing up, it was God is number one, family is number two. Games [are] a universal human phenomenon; they show up in cultures since very, very long ago. Games show that, no, we don't have a singular purpose. We in fact adopt purposes. In the case of games, we adopt agencies in order to have the experience of having them. Or in order to have the side effects. In the case of work, the side effect of I get paid and I get to work with these people.

Jessitron:
I find a lot of freedom in that, that the purpose I'm working toward today does not have to align directly. It doesn't need to be a straight line from writing this blog article to making people who are able to change systems in the world. It doesn't have to be a straight line from giving this conference talk or attending this meeting to something that I personally deeply value. It can just be: I attend the meeting.

Brian Marick:
And how has that affected the way you attend meetings?

Jessitron:
Oh, good question. Okay. What it says to me is: I'm attending this meeting because I think it will make me and the other people in the meeting better able to work together in the future. But I don't aim directly for working together. Working together is a side effect that's going to come out of building a common vocabulary, seeing that we have alignment, and also making small talk and finding out how their pets or their children are doing. So I can choose to adopt in the meeting a temporary goal for this hour of “develop better lines of communication with these people, particularly around the topic of the meeting.” And when I do that, then I value the small talk at the beginning. And I value being kind to each other. I value letting other people speak, even if I'm bored by it at that particular moment. I value other people coming up with ideas that maybe I already had, but it's more valuable to me if they say it, because then I can say, “yes, let's!” And that brings all of us further into alignment and improves our work together later. So I don't [say] “Let's follow the agenda. We must have an agenda and we must follow it! We must make this meeting efficient!” – because the purpose, the deeper outcome of the meeting, is who we as a team become. And if I look at that deeper outcome, then I look past the nominal outcome. Officially we're supposed to be discussing whatever it is. I look past that objective of the discussion and see: why [did] we take on this objective [in this] discussion? It is for the side effects of becoming people who can work well aligned and smoothly together.

Jessitron:
It's like when I'm playing a board game and then we take on the purpose of getting the most victory points and it helps to actually try to win because that makes the game more fun. But at the same time, I'm actually playing for fun. And so I'm not gonna cheat. That would ruin the fun. And I'm also not going to totally stomp one player, even if it would have a small advantage to me, because that would make it less fun. And so we keep the whole thing kind of more balanced. In a game, we're playing it to have fun together. So we follow the written rules in such a way to feed that side effect. And in a meeting... Yes, we're going to follow the agenda, mostly, but we're going to do it in such a way that we develop better alignment. And if we discover along the way some path toward alignment that's more effective than the agenda, we're going to do that. If in a game, we discover some rule that we all hate and just ruins the fun, we're going to have a house rule and we're going to change it. So there's a freedom in recognizing that we have consciously adopted an agency and the nominal purpose is not the ultimate purpose. Ooh, that's a good phrase. I like that one.

Brian Marick:
In our board gaming, in our family, we tend to only play cooperative games like Pandemic, where the goal is [for] all of the people to beat the problem rather than to beat each other. I don't know if this is at all useful, but when you're working in a company, a team, you are playing a cooperative game. And part of what you're doing when you play a cooperative game like Pandemic is discovering how to play the next game better.

Jessitron:
Yes, totally. One thing that makes games fun is improving your skill level over time. And a well-designed game does that. It gradually improves or it lets you improve your skill level. Because that's a feeling of progress and growth that feels good to us. In software teams, you have adopted an agency of maintaining this product, improving this product, adding this feature, whatever it is, and you want to do that in such a way that you increase your ability to add features in the future. There's always a “becoming” in any process of play (even if you call it work).

≤ short music ≥

Brian Marick:
This is something of a digression, brought to mind by something you said. Once in 2002 we were having a workshop in which we were doing pair programming and so on and so forth. And I was relatively new to pair programming. I traditionally had a fairly over-intellectualized idea of programming where I needed to have some useful, clear conceptual model of the system in my head to feel comfortable.

Brian Marick
And I realized at that moment that I didn't have that feeling of comfort, but that the collective of me, my pair, and especially the tests that we were writing collectively had that mental grasp that I was used to having as an individual. And that was just fine. That was comfortable. It was not as uncomfortable as I was used to feeling when I didn’t have a personal mental grasp of the system.

Brian Marick
Ever since then, I've told people about this, and they look at me like I'm from Mars. It doesn't resonate with people very well, as far as I can tell. But you said something that seemed very similar to that, and I'm wondering, A. Was I just reading into what you said something you didn't mean? And B, if you were indeed talking about something like a collective grasp of how to do things, if you've had any success in selling it to people.

Jessitron:
Yes, I am talking about a collective grasp of how to do things. And what you just said speaks to the evolution of software development over the last 20 years. We used to be able to have that clear conceptual model of how pretty much everything that affected our code was going to work. And now we have to maintain way more code. The amount of running code grows faster than the number of people working on it. And so more and more people need to be able to work on a wider swath of code than they could possibly have a complete model of. Also, I think we were kind of deluding ourselves that we ever had a complete model or else it was really small.

Jessitron:
Oh, and also we were in our twenties, which helped.

Brian Marick:
Right.

Jessitron:
But now the reality is that the understanding of what's happening in our software system cannot be all in a single person's head. We have a whole team, but it's not all in our heads either. It's in the system itself. The tests are part of it. Observability is a big part of it. Get the code to tell you what the heck the code is doing and what matters to it, and what takes so long, and where it's failing.

Jessitron:
And then you asked about selling that.

Brian Marick:
Yes.

Jessitron:
Um. Have I had success selling that? I don't know! I say stuff and people are like, “Thanks. That was good.” I do think people are feeling the cognitive load of how big a system we and our teams need to support now. /Team Topologies/ is a very popular book now. Lots of people are reading /Team Topologies/, which is great because it is about “how do we organize our teams?” Because unlike the beginning of Agile, our teams aren't working on independent products. That's not a thing! The only independent product I know these days is games. Little game apps can be independent of anything else, but with most other programs, it's all about the integrations. We need ways of relating to each other – this speaks to pain that people feel. So I really like your point about noticing that you and your pair and the tests collectively had enough information because we have to do that. We can't try to keep it in one head anymore.

Narrator:
At this point, we lost our connection and therefore the thread of the conversation. We resume with Jess talking about managing a team.

≤ short music ≥

Jessitron:
I really find value in recognizing that (1) my team's purpose is not my value as a person, my values as a person are different. (2) we are not aiming directly for profit, or we would implement things absolutely as cheaply as possible. Our goal is to sustainably work toward more and more valued capabilities in our software, because that has a side effect of profit. Thinking about it this way is useful to me as an individual, even if the rest of the team doesn't. When I work with the engineering teams at Honeycomb, I drop little comments here and there, but I don't ask them to adopt my model of the world. The ones that are useful to me will also be useful to some other people – but you don't need the whole team to align on this kind of philosophical model of how work works. [I manage] a developer relations team at Honeycomb and our goal is to spread our view of observability in the market, especially for observability during development. Okay. I want our whole team to adopt this goal and work on it together, but I don't need you to adopt it as your personal mission. And this leads me to encourage people to do some sort of little project that is related. I mean, like if Martin wants to work on building a proxy that does tail sampling... then okay, he's going to use observability during the development. And so it's, it's going to have the effect I want to have on the world as a side effect, even though he's chosen to adopt some different goal as a direct goal. And that's fine. I want to encourage that because it lets people proceed with what they're particularly passionate about at the moment. Instead of asking them to be passionate about whatever our team does. I don't expect passion about “victory points”. I want you to do your best, but not dedicate your heart to it. I feel like this is a much more healthy attitude about work, both as a manager and as a team member.

Brian Marick:
One of the problems I've noticed about software is we tend to overdo “commitment”. I used to hang out with Ralph Johnson's research group at the University of Illinois. There was this phrase that was bandied about, which was “relentless refactoring”. And at some point
I blurted out in a group meeting that this is so pathetic. “I'm relentlessly typing at the keyboard.” And nowadays, I associate the same sort of attitude that we have to be somehow relentlessly focused on “business value.” And it sounds to me, putting words in your mouth, that that is impossible. It is not possible for people to relentlessly focus on the goals of someone else. So that now that I've told you what you think, what do you actually think?

Jessitron:
Profit is necessary to keep our team able to do our work so that we can get paid. Refactoring is in line with our direct goal because it keeps us able to continue to make changes, but refactoring forever is incompatible with the wider goal that we took on this feature work for: making some sort of profit and continuing as a business. It's not a matter of personal integrity to have 100% test coverage and perfectly rock solid engineering (as if one engineer can actually make a software system solid.) This is not a personal failing if we don't do that, it is in fact a matter of balance and a matter of working within the system that we're in. Because we care both about the values we adopt as a team and the system as a whole. Yeah, it's not relentless focus. Relentless focus is a dude bro thing or a tech bro thing! I don't know. It's not how things really get done. At least not sustainably.

Jessitron:
There's another book that makes a really good point about this. It's a very small book, highly recommended. It's called /Obliquity/. It points out that if you aim for profit directly, you will not get profit. Maybe briefly: you might briefly get profit, but the companies that aim for profit over everything else are Lehman Brothers. Everyone that they hired is after profit. Well, you know, whose profit they're really after? Their own. That kind of company falls apart. That doesn't make for an organization. If instead, as a company, you aim for crafting beautiful user experiences, like Apple, or you aim for making the best airplanes in the world, like Boeing back in the day… And you expect to do that in a way that also generates profit because that lets you continue to make airplanes or craft user experiences. This is sustainable. You can make a profit while working toward a goal that is unique to your business. It's the same with happiness. That's another one. If you aim directly for happiness, you'll go do drugs or something and you won't be happy. But if you aim to make a podcast, for instance, that helps people in the software industry think about things in a new way… Then, even though that's a lot of work, I bet it makes you happier than smoking pot all day.

Brian Marick:
I haven't tried them both.

Jessitron:
Well, you totally could. It's much easier now than it used to be.

Jessitron:
But yeah, I recommend adopting a goal that's unique to you, that happens to result in the conditions that you need, like enough happiness or enough profit to continue working.

≤ short music ≥

Jessitron:
As a software team, we cannot create business value by ourselves. What we can do is maintain and make software that reliably provides capabilities. And then we hope those are capabilities that are valued. But we need other people to do some research for what is valued, we need other people to bring that software to market and to sell that software into organizations and help those organizations integrate it. There's a lot more to business value than the software. Now the software is requisite for that. So we will more effectively be part of a company that is creating business value by focusing on providing those valued capabilities reliably and flexibly in a way that we can continue to add more.

Brian Marick:
I don't know if this is a useful metaphor, but... in child development, toddlers go through a phase of what's called parallel play, where they're not playing [with each other], but they're near each other, and they're not directly interacting, but they're together. And it almost sounds like you're advocating for, say, marketing teams and programming teams to be doing parallel play where they're sort of going in the same direction but they are each attending to their own happiness, their own goals – but they're compatible.

Jessitron:
Yes. Goals are compatible. Yes. Development often gets frustrated with marketing because marketing wants to time releases and build up all of this campaign material and planning and stuff around this feature release. And then suddenly the dates are fixed, and that's in conflict with making the software really solid. That's because marketing has different values. Marketing has values like generating leads and engagement and grabbing mind share in the market. And that is not the same as creating solid software systems that are reliable, but it is compatible. It doesn't sound compatible, but we're each doing this for the side effect of the business continuing, of business value, which involves people actually using the product. So these goals are compatible and it is our job – not as a junior developer, but absolutely as a staff or senior level developer – it is our job to find the overlap and the compatibility between these values so that we can play next to each other in our different ways. And the result will be business value eventually.

Brian Marick:
So, /Obliquity/. I've never even heard of the book, but it sounds to me like it is possibly also suggesting that efficiency, a focus on efficiency, a relentless focus on efficiency – no wasted motions, nothing that can be seen as not directly pointing at business value or profit – is likely not going to work. Is that fair?

Jessitron:
Oh, sure. Sure. It turns out that there are plenty of goals [where] heading directly for them is not a good way to get there. Indirectness is part of how we work in systems. The focus on efficiency is only useful when you know exactly what you need to do and you're doing the same thing over and over.

Jessitron:
I'm a big fan of what a lot of people call waste, which is the “everything else” that didn't happen to be in the direct line of the Gantt chart, but did teach us something. Of that small talk in the meeting that did in fact make it possible for me to be kind to someone who just snipped at me [because] I realized it's because their pet died yesterday. That lets us work together as humans. And in software… it’s like playing around with an API in the REPL and getting a bunch of error messages. That helps you form enough of a conceptual model to work with that API, and also to interpret the error messages you see later in production. So much of my yak shaving, my digging a little deeper and researching stuff and fooling around with it, literally playing, but at work related stuff, has incredible value later: for instance, during incidents, when something is down and that piece of knowledge that I needed is already in my head.

Jessitron:
Yeah, so I'm totally down on efficiency. [laughs]

Brian Marick:
In various of the things I've been reading, I'm halfway thinking that for most of human history, efficiency was not really a thing people thought about. It may have been an outgrowth of the shift to larger scale manufacturing and division of labor. But we've been basically taught that… we have an attitude toward efficiency that I'm not sure is...? Natural isn't the right word, but it's a social construction.

Jessitron:
There was a great podcast the other day, from Sarah Taber. Her “Farm to Taber” podcast has a lot about systems in it. In this one, she's talking about factory farms and you've got these CAFO operations that are: you grow the soybeans, you harvest the soybeans, you put them in a big pile. Later, you mill the soybeans and then that's in a big pile. And then you feed them to the cow and then the cow eats the soybeans and then the cow poops and then you've got to get the poop back to the field. And how so many American beef operations are run that way, but it's actually a lot more efficient to leave the cows in the pasture. Take the cows out to the pasture and let them eat. But what it's not... The pastured cows are not easy to document.

Jessitron:
It's more effective, but it's not as simple, in the sense that you need... if you're gonna pasture your cows, you've got to keep track of what fields have grass right now. Because you've got to be really careful with your grassy field inventory and what grass [you’re planting where]. And now where do you put the cows out and “Oh, it rained, that field is muddy.” Which field can you put them in today? It's a lot harder to manage and it's a lot more situational to manage. It takes real expertise, not just following instructions. Whereas grow the soybeans, mill the soybeans, dump the soybeans in the trough: this they can make a binder about. They can label the instructions, and then they can work on “efficiency” in their batch and queue food movement, by – I don't know – not leaving food on the floor of the granary or something. It's something that they can pinch and squeeze from above without having to make a decision every single day about where's the best field and how are we going to have fields for the next so many months with grass in them. So there's a different kind of efficiency there. Are you going with the flow of cows eat grass, cows poop in the field, more grass grows? Or are you trying to have control and be the one who squeezes the efficiency?

Brian Marick:
There's this saying that all of philosophy consists of footnotes to Plato.

Jessitron:
Western philosophy, of course.

Brian Marick:
I’m getting a feeling all of this podcast is footnotes to /Seeing Like a State/.

Jessitron:
You did start with that book pretty early. True.

Jessitron:
And when we make a virtue of efficiency, we don't recognize the efficiency that's day to day, that's different every time. We don't recognize the efficiency that is [dependent] on this particular little piece of a feature, this particular little task that I'm doing today: “I'm going to refactor and make it a little smoother.” It sounds efficient from a command and control [perspective] to [say], “No, go directly for the feature, focus on business value.” And it isn't, of course. It destroys us as people. It destroys the code base. It destroys our relationship with the code base. So yeah, I agree with you.

Brian Marick:
Well, gosh, that happens so seldom. I don't know what to do.

Jessitron:
[laughs]

≤ short music ≥

Jessitron:
I have an idea of a way to bring this back to the book /Games: Agency as Art/. We've talked a lot about agency and we haven't talked about art.

Brian Marick:
Okay.

Jessitron:
So in /Games: Agency as Art/, C. Thi Wynn talks about games as creating an agency. The game designer crafts an agency. As a manager I do a lot of crafting of agency. What are we trying to accomplish and how are we going to do it? Agency is the medium in which game designers create art. Their art output is the player experience. So when you play a game, your experience is in fact the art form that the game designer is working in. And they do that by crafting an agency.

Jessitron:
And something about art doesn't work with efficiency, right? There's a contrast there, because art is more expressive and art feeds us in a way that efficiency cannot. In software development, refactoring, the best refactoring is not relentless. It is more like art in the sense that within the situation, which is this particular little piece of code and what you're trying to do with it, you choose the refactoring that is appropriate. You choose what fits in the situation. The manager of the cattle farm that does pasture-fed beef has something of an art form [since] every pasture is different. So every collection of pastures that they have access to is different and every herd of cows is different. And they need to match these up and find a way that is compatible and suitable to the situation. And that isn't something you can put in a binder, it's something closer to art.

Jessitron:
So I think when we recognize that no, we don't have a relentless focus on business value as a direct outcome, [that] there's more expressiveness in choosing our agency and in how we achieve it when we refactor [or] when we increase or decrease test coverage. [Or] in when we move toward the latest architecture plan and when we stick with the old library that is working everywhere right now. There is room for individual aesthetic and expression. And I think as we develop that as a team, especially with pairing, we become better developers and our code becomes better and more compatible with us as a team, because we're more in alignment. And all of this is how we get sustained business value.

Brian Marick:
Here's something that might be relevant. You think about various artists of the past – the era of Rembrandt and so on – [when] artists ran studios. They're managing teams and they're producing art. That is perhaps more of a relevant analogy than a lot of the analogies you hear. It's certainly more relevant than the software factory. It's possibly also more relevant than the another fashionable metaphor: gardening. But the thing about gardening is: it’s primarily an individual activity when you think about it. It doesn't have that team component. And so I think it might be missing something because of that.

Jessitron:
Ah. That's true because so much of what we do is interpersonal communication, that common language – and [it’s] shared [with] the code as well. A lot of it is about inter-predictability and other properties of joint cognitive systems. You can look at the code as a garden, but there are multiple gardeners. And if I think this plot is radishes and you think it's peppers, it's not going to be good.

Brian Marick:
I'm thinking of the classic English garden. When I think about those kinds of gardens, the impression I get is they were a single person's vision that was implemented.

[Editor’s note: here I riffed a little bit on Tom Stoppard’s play “Arcadia”, which is itself a riff on chaos theory – as well as gardening, Lord Byron, entropy, the tradition of the “garden hermit” , etc. Highly recommended. I’m not including what I said because, embarrassingly, I couldn’t remember the names of either the play or the author. See the show notes for links.]

Jessitron:
Oh yeah. We talk about that in software, how we need a single vision. And I roll my eyes at them because that's not a thing. That's not a thing in the world. And high modernism is a disaster. Now we're back to /Seeing Like a State/.

Brian Marick:
There has to be a goal, there has to be a value, there has to be a vision, and we have to all be aligned with that. We all have to be the wood behind the arrowhead.

Jessitron:
When in fact, that single vision is not omniscient and there is no objective perspective, but we do approach objectivity through multiple subjective perspectives. Through multiple value systems, through development's value system of solid software, plus marketing's value system of mindshare or whatever, plus sales' value system of integration into the organization, and more. It's these combined perspectives are like, I don't know, they're like feathers in the arrow shaft, except maybe they go around in circles. I don't know.

Brian Marick:
Yeah, if you pick at the metaphor too much, it’ll make a scab.

Brian Marick:
Actually, that last statement, I think that actually it was a good summary statement. So I'm thinking I would like to end with that.

Jessitron:
Okay.

Brian Marick:
But do you have anything else to say?

Jessitron:
I always want to tell people that if at your work, they don't work this way, if they talk relentlessly about business value and pretend to aim directly for it: they don't. But it's okay. You don't have to agree with everything everyone around you says. You [can] still choose to adopt a compatible agency and it's okay that your values are different: they can still be compatible.

Brian Marick:
That is another good summary statement.

Jessitron:
I just hate for people to feel trapped, and I hate for people to feel like they have to either “change their organization or change their organization”. If you're in it for the money and you're content enough and your team is nice, you know, if you're happy, great. That's enough.

Brian Marick:
“You don't have to change the world” is not a bad summary statement. You're really tossing off the summary statements: bam, bam, bam.

[Laughter]

Brian Marick:
Well thanks for the conversation and enjoy St. Louis.