Jessica Kerr: How Some Shared Fun Time Increases Your Team’s Productivity

Richard:

Hello Jessica, how are you?

Jessica:

Hello, Richard. I’m good, I’m good. It’s a beautiful day.

Richard:

It is. I actually don’t know where you are, but I’m here near Boston and it’s a beautiful day here.

Jessica:

I’m in St. Louis. It rained this morning, but it’s lovely right now.

Richard:

Perfect, perfect. Let’s see. So in addition to telling us what a semanticist is, is there anything else you would add onto that intro?

Jessica:

Oh, I work at Honeycomb, so I get to work on observability tools which is my favorite thing at the moment because they’re just important for creating feedback loop, but creating feedback loops in the systems we work in.

Richard:

And we say more about observability. What is that about? Observability tools, what does that mean?

Jessica:

So observability is being able to see inside your software, like what it’s doing, what decisions it’s making, what’s slow, what’s failing, what’s causing that. And you do that by getting the software to tell you and it tells you by like shooting out events of, hey, I got request, hey, it failed. Hey, it’s from this user agent in this region, and everything else that it thinks might be relevant. A lot of these events come from libraries, but also you can add your own data like, oh, it was for this customer, oh, they have this many users or data points or whatever. And you can add all that stuff to the events that it sends to you. And then a tool like Honeycomb or there’s open source versions like Jager plus some metrics tools puts all that together, assembles it into a trace, gives you a little map of what’s going on in your software. And also you can add them up and say, how many requests are failing, blah, blah, blah, blah, blah. You can get both a high level and a very detailed view of what’s going on in your live software. And that’s really important because honestly what’s going on in the live software has always been a mystery to me as a developer. We have our models of what we think is going to happen based on our understanding of the code which are always partial and always out of date. And it’s kind of magic that it ever really works. Really, we don’t talk about that.

Richard:

I just feel lucky. It’s fairness running as far as I know, I got lucky.

Jessica:

Yes and a lot of people are involved in that, but being able to see a whole picture of really what triggers this function that I wrote, what caused that and what customer activity made that happen is kind of magical and it makes me feel really good about having an impact in the world.

Richard:

All right, cool. Cool, I think I could use that kind of help. And what about… What about this word, symmathisist.

Jessica:

Symmathisist. Okay, let’s… Symmathisist is my personable amplifiable, my mutation of the word symmathesy, symmathesy, S-Y-M-M-A-T-H-E-S-Y from the Latin sim together and mathesy learning. This word was coined by Nora Bateson anthropologist because as… Because the word system is too vague, too wide and implies a mechanisticness that live systems like ecosystems and organisms and teams and communities, they are systems, you know, are in their systems in the sense of more than some other parts, the relationships with the parts form the system much more than the individual parts themselves, but in a symmathesy in particular, it’s not just that it’s that the parts are also a product of those interactions. And the parts are each learning. The people in the system are learning or the species and the ecosystem are evolving and learning. And as a result, the system as a whole is learning, both through the changing of the parts and the new relationships that develop between them. So symmathesy is a learning system made of learning parts. And you can’t treat it the same way as say, a software system. If you take a software system at any point in time, if you like snapshot a software system, look at like one, get commit in a library or something like that. There’s a lot of parts in there. Maybe there’s a couple of services. Maybe there’s just a bunch of classes that call each other and their relationships are crucial, but if you put enough effort into it you really can’t break it down and understand the whole thing, it’s complicated and if it’s a distributed system, there’s also complexity, but even then you can get a handle on it. You can measure it. You could predict the future state of the system based on what it’s doing now, that is not true of an ecosystem and it’s not true of your team. So while software itself might be a system at any given point in time, over time as our software changes because we change it. As the software calls out to changes, as all our interfaces change and as our… The people who use the software are changing and expectations are growing and new security vulnerabilities are discovered that technically always existed but they didn’t really exist. They weren’t vulnerabilities until someone figured out how to use them for that. That’s a symmathesy. Yeah, it doesn’t hold still and you cannot predict the future. You can plan a little bit and respond a lot.

Richard:

Okay. I’m kind of getting it and I’m sure I’m going to learn more and I–

Jessica:

Oh, oh, oh, but you asked about symmathesist. So that’s the word symmathesy which is what it comes from. It’s about a learning system made of learning parts. And in particular, I think that our software teams are symmathesys. Any team is a symmathesy, we’re all learning individually and collectively, but software in particular, because I can include the running software as a learning part. It learns ’cause we change it. We learn from it because if there’s exceptions, especially if you have observability, then you learn a lot from it. It can teach you what’s happening ’cause you do not understand all of the code involved or the underlying databases and libraries and interactions and everything. So we can learn from it. And that makes the running software participant in the symmathesy.. So then I use the word symmathesist to describe participating in a learning system made of learning parts and doing so consciously in a way that cares about the future of the system to deliberately increase the flows of learning in our symmathesy. There that was a lot.

Richard:

Okay. I’m getting it more and more. You and I are a symmathesy right now?

Jessica:

Maybe a kind of like little baby one. So I mean, two is definitely like a degenerate size and also an hour is a degenerate length. However, at that timescale, yeah. At that timescale, we are symmathesizing.

Richard:

Okay, cool. It may be all of our future viewers and listeners and–

Jessica:

At a much wider time scale and a much wider scale the entire software industry community is a symmathesy and we are participating in that and everyone who’s listening is participating and writing software that will impact people for years to come.

Richard:

Oh yeah.

Jessica:

Both from a use and development perspective.

Richard:

And I love doing that as much as… Maybe as much as I think you love doing that. I got a strong feeling as you were talking. The words, the body language, the expressions on your face, you really love this stuff.

Jessica:

Yes, yes. Software is such a fantastic industry to be in right now. I mean, I really think that software is something very new in the world. Yeah, it’s not the same as engineering because it operates more quickly. We can change it faster and it impacts the world faster. And so the expectations of the people in the world change more quickly. I mean, when I was a kid video calls were fantasy and now it’s just like, oh, another Zoom, you know.

Richard:

Now the three year-olds are getting tired that they have to do more video calls with friends and grandma.

Jessica:

Yeah, yeah. I remember the first time my kids were toddlers and we were in a restaurant trying to have dinner and they were like wanting to dump even more of the Parmesan cheese out all over the table. And I pulled out my phone and found Tom and Jerry on YouTube and handed it to them. And restaurants were so good after that. And the kids thought Tom and Jerry was synonymous with YouTube. They eventually learned it had a broader name, but that’s just… The interesting part to me about that is how not ridiculous that seems now, how the pace of change of software it just changes our expectations about how quickly the world should get better. The kids, they’re teenagers now and I was asking about drawing programs and the 13 year-old was like, “Oh yeah, that one’s not very good “and it never updates, this one updates all the time. “It’s much better.” Like they want their software to change continually.

Richard:

It’s a signal that it’s better, yeah.

Jessica:

Right, right, right. Whereas I grew up expecting software to install on my… Wasn’t a laptop then. On my desktop computer and to hold still and not break and not require anything further of me. Expectations are different now.

Richard:

Yeah, yeah, all right. For sure. Okay, so we’ve been talking about teams already and this podcast is about teams. And what I’d like to ask people is to share about the best team that you’ve ever been a member of in your life. So what team would that be? What would your best team work team, non-work team, any group of people with shared goals? What’s your best one of those?

Jessica:

I mean, there were two teams that I grew a ton on as a developer. One that was really productive and one that just had a really strong enemy in management, you know, a common enemy can really pull you together. And we learned a lot. That was where I learned a lot about Agile and XP and pairing, and that kind of teamwork was so good. But the one that was productive was where we actually got to interact with our customers directly. It was a small team and we had complete control over our deployments and everything like that. And there wasn’t anyone, any architect of doom standing between us and the business people who used our software making sure we didn’t get uppity and make a commit to the main branch.

Richard:

Right. We know what could happen. You might please some 13 year-old by changing the software. Which one of those should we go deeper into?

Jessica:

You know, the one where we were a really close team, we worked really strongly together against great obstacles. I left after a year. I got… I really wanted to get something done. So even though I learned a ton and I have great friendships out of that, it wasn’t a team that I could stay working on even. Whereas the other one eventually got laid off ’cause I was the highest paid. That’s why. During some crunch or other, but I worked there for several years because it was sustainable. And we replaced the point of sale system in our stores. We went from like one store to a dozen and we needed a new point of sale system and it needed to integrate with our catalog backend which was entirely custom in a language no one has ever heard of and I don’t even remember the name of it. So it needed… We needed a custom point of sale system and like three and a half of us wrote that point of sales system in a year and implemented it, and we like went to the stores and helped them with their initial inventory for rollout. It was great. So you know, it was a small team and incredibly productive which… Have you noticed that too that like smaller teams can typically do more faster than larger teams?

Richard:

Yeah, I totally feel that like the cost of coordinating ourselves. The overhead of that seems like it gets in the way of just getting it done.

Jessica:

Yeah, yeah. It really does. And it feels like–

Richard:

Of course we can do more.

Jessica:

It feels like… Okay, it feels like cheap as in few developer salaries or fast, choose two or zero, you can’t have one.

Richard:

Right. All right. I want to dive deeper into either of these teams. I mean, they both sound like there’s a lot to dig into. Pick one or pick both and take yourself back there and tell me what it feels like. And if you could, if you could summarize the feeling of that team, the sensation of being with that team, if you could summarize that in one word, what would your one word be?

Jessica:

Lunch.

Richard:

Lunch?

Jessica:

This applies to both of them.

Richard:

Okay, what about lunch?

Jessica:

We had lunch together because we liked to, yeah. On the smaller team, we played Hearts. There were five or six of us in our near vicinity that would get together every day and play Hearts at lunch. And Hearts is a different game when you have a group you play with regularly that all kinds of politics develop and so many inside jokes. But the other one too the building we worked at had really nice little cafeteria and also an outside area, and we would go fetch food and bring it back and sit together and eat. And if we were outside and pretty sure our managers were out of earshot bitch about the architects and the other golfers who were in charge of us and just did not understand.

Richard:

You’re introducing me to new disparagement. The other golfers.

Jessica:

This company had a huge golf culture and all the developers are like, you want us to what? There was like an annual golf outing that was a big deal. We had to have our own little IT golf outing beforehand to be like, teach us how to golf ’cause we don’t know what we’re doing.

Richard:

And this is hilarious. My aunt and uncle host an annual bigger family get together and the day before the golfers go out golfing together and I never get invited. And this year I was thinking, well, gosh, they never even invite me to go golfing. I don’t want to go this year, but actually I don’t want to go golfing. I just want to be able to say, no, thank you. Thanks for thinking of me.

Jessica:

Yeah, yeah. The company golf outing wasn’t any fun. But the IT one where none of us knew what we were doing that was a blast. We went to this golf course in the city of St. Louis, like the oldest public golf course west of the Mississippi I’m sure. But it’s like the clubhouse sells hot dogs in lemonade.

Richard:

Perfect.

Jessica:

Yes, yes. This is my level of class for a golf course. And so it was super informal and we’re just drinking cheap beer and driving little cars and you play scrambles. So whoever gets the best hit everybody pretends it was theirs. So you only need one competent person on the team to actually like complete a hole in a reasonable amount of time. Yeah, yeah. It was… That was a blast. Would totally do again. Golfing with actual golfers, heck no.

Richard:

Only if we do that best ball scramble. That’s the.–

Jessica:

Yeah, yeah, yeah. They did a scramble with the other one, but it was still like, that was a fancy golf course. They’re like houses everywhere looking at it instead of trees and yeah, it was… When we were… I don’t know when you were supposed to care about the golf, it wasn’t any fun, but as a companionable outdoor activity where you get to drink and drive and it’s not particularly dangerous, great recommend.

Richard:

And before we pressed record button, we were talking about this a little bit too with music, like learning violin can be fun if it’s just for fun and you’re not like thinking about, oh, I have to learn this piece ’cause I have to perform it next week.

Jessica:

Yeah, my violin teacher always likes it when I show up because I am happy to be there. I am at these lessons because I chose it and I pay for it and I come out of my like own volition and excitement, unlike the children who were like, oh, I have to do this again.

Richard:

Yeah, I was a little bit like that when I was a kid doing piano.

Jessica:

But now you do it for fun.

Richard:

But now I do it for fun and it’s just fun, yeah.

Jessica:

And you progressed a lot faster doing it for fun.

Richard:

Oh, I sure did. I mean, I had a strong foundation and I just want to do it now.

Jessica:

Yeah.

Richard:

And I don’t. Okay, another thing when I was a kid, I decided piano wasn’t cool enough and that definitely hurt my learning. Now I realized piano is actually really, really cool. Being able to play any instrument is really cool. I still, I still want to be a guitarist, but I never will be a great guitarist, but I actually am a pianist and I’m taking what I hear awesome guitarists do and I’m doing it on piano which is super fun. I have a really nice new arrangement of, “Welcome to the Jungle” for solo piano singer.

Jessica:

Wow.

Richard:

Fun.

Jessica:

Yeah. It really is, it really is.

Jessica:

And there’s that connection between like wanting to be there, wanting to do it, and being able to learn. And we see that in our teams and sometimes you get the wanting to be there. I mean, the strongest force in wanting to be somewhere is who you’re there with. And that’s why in positive or negative circumstances, both of these teams were great learning places for me because I was happy to be there with those people.

Richard:

Yeah. Yeah, that’s it. And you had lunch together, which is a sure sign that you were friends. I mean, at least while you were together at the office you were friends.

Jessica:

We were totally friends. We’re still friends.

Richard:

Maybe you were outside. If maybe… Yeah, okay, friends, yeah. So what else about… pick a team or we’re talking about two teams subjectively. How do you know these were great teams or one of these was a great team. Subjectively or objectively. Like how do you know within you or how would somebody else–

Jessica:

Because of how much I changed.

Richard:

How much you changed?

Jessica:

Yes, yes. Because I am a different person after working on each of those teams.

Richard:

Okay. In what ways?

Jessica:

On the first one, on the good one, I actually learned a lot about software and good development practice. There was one developer I worked with who’s just a genius, both of design and implementation. And of course also I got to learn more about like the whole caring for a software system through its whole life cycle and troubleshooting all the production errors and being responsible for everything. I mean, it was a pretty low pressure environment. Retail isn’t up all night. Yeah, no, no, okay. Every year, one direction of daylight savings would screw us up and we never did get it fixed before the next year rolled around. But that was like… I mean, the biggest emergency was like, “Oh no, the managers reports look wrong. “Let’s see if we can fix this before Friday.” So it wasn’t high pressure, but it was responsible for the whole system including what should it do. Looking at user needs and finding creative ways to fit that into the software that made sense both with the design and what it needed to integrate with. Also, I got really good at Hearts.

Richard:

And Hearts skills.

Jessica:

Yeah, yeah. And the other team I mentioned we implemented a lot of agile practices. Every employee there got an office because golfers, it was a prestige thing. And we were like, “We don’t want offices. “We just want a team room. “Give us a team room. “We’re taking over this conference room, it is a team room. “We’re moving our computers in there “and we’re working together.” And they were like, “Ugh, okay if you insist.” That one was… They hired us in a downturn. It was after I got laid off from the longer term team, but it worked out well. They hired all of us in a downturn so they got a bunch of really great developers cheap. And that’s another thing I think that went into the closeness and the progress that we made in this team, including one dev who was… I mean, he came in as dev, but he’s like director level manager really but he’d taken some time off from his career while his wife was hospital administering and he wanted to start again as a developer. So we had an incredibly senior person, his name was Steve Stamps, great agile coach and leader and manager and he taught us all how to pair, how to do various other practices associated with Agile and XP. And also just like built relationships within the team was wonderful. And then of course we had the common enemy, which was the architect of doom and generally management that had no clue, no clue about software and how it works and how software developers… What software developers need. And then we had the software itself is of course a big part of this and the good team, the productive one it was Greenfield actually. So we all knew the code, we had the legacy system to interface with which we did occasionally, but we had people who knew that. The half on our team was an expert in the legacy system. So we had all the knowledge we needed, whereas in the unproductive but formative team, we had this big legacy system that, oh, oh, it was during that time that I read Martin Fowler’s “Refactoring.” And I was like, “Oh, this explains so much of our code base “because there were patterns in Refactoring “that by 10 years later were way out of date, “but were rigorously enforced in this code base.” And I was like, “That’s it we’re trapped in 2002.” But it was… There were like custom ORM frameworks. Well, one of them, of course, ’cause everything was incredibly consistent because one architect of doom was the only person who could commit to the master branch. So there were mysteries to solve of how this ORM worked. And I am not kidding how the 14 levels of class hierarchy, 14 levels of inheritance was a minimum.

Richard:

You never know.

Jessica:

In the system.

Richard:

‘Cause .

Jessica:

For domain objects.

Richard:

Before you get specific.

Jessica:

It was. Well, it was 2002 people were innovating with class inheritance and that’s how you built frameworks was with inheritance back then. And of course, by the time I learned Java in the productive team, a few years past that 2005 or whatever, we did not use inheritance hardly ever. We used composition. So I was like, my Java was much more up to date than architect of dooms but it led to great mysteries to solve of how does this ever work and when does it not. That system was really fun in a pathological sort of way. It had 16 gigs of ram in production and we had to restart it every night because it would run out of cache space. But that was fine ’cause it was insurance, nobody cared. It’s totally fine to restart it every night. But it would run out of all that ramp with 70 users, there were 70 total users and like 10 developers. This is not efficient. Anyway, it was… I am so happy to have had that experience and to have those friendships. I would not go back to those days but I have very fond memories of lunches outside.

Richard:

Okay, so we’ve got lunch outside as one of your concrete behaviors for lunch inside, lunch outside, lunch together as a concrete behavior on both teams. What are some other concrete behaviors that you engaged in together on either one of these teams that led to the successes that you had as teams?

Jessica:

If anybody came in on Saturday, everybody came in on Saturday ’cause we were in it as a team. Oh, on the small team where there were only four of us, our cubes were in this little square and we did some common decoration, decoration of shared space. That’s another thing that was present in both. I think we had like a giant inflatable palm tree in the team room, in the larger team. But yeah, we had like some really silly… Oh, it was a rooster rug, yes. ‘Cause we were working for a cataloger that sold rugs and some of them were silly and one of them had a rooster and we got one and we put it in the center of our cubicle square. And it was, if I had a problem I could just like yell it out and people would chime in and help. Also in the team room that would be a thing of blockages immediately cleared.

Richard:

All right.

Jessica:

And rooster rugs that was very concrete.

Richard:

Definitely rooster rugs. In addition to rooster rugs, what advice do you have for our listeners and our viewers? How can they get some of the success from either of these teams.

Jessica:

If you’re a leader of a team, try to provide them with that shared space, that’s hard remotely. But you can have like a shared Zoom that we pop in and out of. That can help. You can send everyone a rooster rug or at whatever goofy team. At Honeycomb I think at some point everyone gets a stuffed bee. These little common physical things, that’s tiny stuff. Remotely it’s really hard to have lunch together. On one more remote team, we used to have stand down at the end of the day. So there’d be stand up in the morning, what are we doing today, blah, blah, very serious. Stand down would happen at like 4:30 PM in some time zone. And it was encouraged to have beer and just bitch about anything that happened and generally sort of this was the informal get together every day was the stand down. And now if you actually want the productivity out of a team, give them all the abilities that they need to do their work. Give them permission to deploy, give them observability to find out what’s going on in production, give them direct contact with people who use the software, not through your product manager, no. You are not saving them time by passing through the questions. You are adding speed bumps when you do that. In general, also with lunches and with the social time, we generally divide time into working and waste. But that’s not where it is. Efficiency is not about removing waste when waste is idle time. Idle time is fine, idle time is slack, idle time is clearing other people’s blockages immediately, idle time is being able to breathe and do a good job on your work. We should have idle time in our days, most days. Some days you’re the bottleneck and you don’t have any in, but if you don’t normally have any and then you’re the bottleneck forever. That’s it’s the traffic jam. Waste is when work is stuck, waste is blockages, waste is I can’t deploy this ticket because there’s a deploy freeze, okay. Look at the work moving through the system and see where it stops, where that inventory of code change or whatever it is, is sitting on the floor, that don’t waste the time of the work moving through the system. The more you smooth that out, the more throughput and the more throughput you get which is indirect because you’re actually reducing latency as well. And as you reduce latency of change, as you can get from, “Oh, hey, the store manager had a problem with this,” to “That’s fixed in production.” Or now you have that field on that report. When that’s a day, everyone’s happy. And when there’s a problem with it you hear about it immediately, you’re still in that head space you can fix it immediately. You have a lot less rework when changes move quickly when the lead time is low. And when you do have rework it’s easy. So it’s another of those things. This is the whole DevOps loop of changes getting out faster means fewer failures and also shorter failures and frequency of deploy goes up and that lowers the lead time for changes and it’s all a virtuous cycle. You get all of these or none, this is not a trade off.

Richard:

All right. And you get them from giving people all the abilities they need.

Jessica:

All the abilities they need. To reach the goals you’ve set for them.

Richard:

Yeah and some individual person slack time because it’s not about individual person slack time. We need that to keep the work flowing through.

Jessica:

Yeah, yeah. Keep the flow of work busy and let the people be idle because with that idle time they will make the system better.

Richard:

Yeah. And in case anybody is confused. We’re not saying like keep people idle. Make sure nobody does anything. Make sure nobody has work to do.

Jessica:

You know keep them idle but when they’re idle, that’s fine. That’s not the issue. Don’t fill the time with more work than then sits in queue accruing merge conflicts and bugs.

Richard:

All right, excellent advice. Now, do you have anything else you want to add? Anything you’ve been thinking about? I used to often run into you at conferences and you–

Jessica:

I saw you the other day.

Richard:

Both of us were sharing things–

Jessica:

At Agile & Beyond.

Richard:

It was my first work travel in two and a half years, my first conference with actual humans in two and a half years and it was awesome seeing you. I came back… I came back energized and creative and wow, that’s what I miss from… Before two and a half years ago.

Jessica:

Because in those conferences we find a wider, slower scale symmathesy. We exchange ideas and we think together.

Richard:

Yeah. And it was great, yeah. I was really happy to see you. I was really happy to see other old friends and make new friends and yeah, it was great. It was great. Yeah. So what were you sharing at Agile & Beyond or what else is on your mind or is there anything else you want to share?

Jessica:

Well, what I talked about at Agile & Beyond and my topic for the year is about game design. And this ties into the being a symmathisist and working consciously with our teams. But if you… There is wisdom in games that we can incorporate into how we work in our teams. It is not what we think of as gamification today, okay. Points are stupid and tell people to narrowly focus and I mean, literally you give people a metric for gamification you are asking them to game it, okay. It’s a game now and it’s not real work and it strips the real meaning of work of having impact on the world and developing relationships with each other ’cause now you’ve set us in competition and like everything about ordinary gamification is corrosive to the collaboration on our teams and strips away the deeper meaning to replace it with these superficial incentives. But if we look deeper, if we copy the questions of game design, instead of these superficial characteristics of games. Game design is about designing an experience for the player and we design that experience by giving a player in a specific agency. Agency, meaning a mode of action in the world and made up of goals, rules, and abilities. So when… Oh, I love this. This all comes from a book by C. Thi Nguyen by the way called, “Games: Agency As Art.” That’s the thing to look up. And when in Super Mario Brothers, you were given the abilities to run and jump and you are also presented with a world full of chasms to jump across and monsters to jump upon and a goal of a flag that you can just exactly reach the top with you running and jumping. It’s beautiful in this confluence of goals and abilities gets us into flow and it creates a great experience. So as game players, we choose to adopt the victory condition, getting that flag in Super Mario Brothers isn’t like feeding my family or anything, but it’s… But we… But I adopt it in order to have the experience of playing. And so we use the abilities given to us and we follow the rules of the game on computer games, you don’t have a lot of choice. But even in board games and sports and card games and other forms of play, we follow the rules because it enhances the experience. We do that voluntarily and also we do this in our teams. We set goals for our teams of, okay, we’re going to try to implement this feature or we’re going to try to reach 99% availability at under one second response time. And we set these goals, we have some abilities, we have the ability to change code, do we have the ability to see into our system? Do we have the ability to upgrade our libraries? There’s do we have an understanding of the code? Do we have the relationships we need to get the information about the systems we’re interfacing with? There’s so many abilities a team needs in order to achieve its goal. And there’s also rules we follow. We don’t log into production and change the code there. We go through source control. We do code review. We pair, we write tests. We follow a lot of rules because we’ve learned that it’s a better experience overall if we do that. But as leaders and as participants in an Agile team, we have a lot of… We have a lot of control over our goals, our abilities, the abilities that we gain as we go along and the rules we follow, we can adjust our processes. And can we work with those things in order to give the software developers an experience that is game like, an experience of flow, an experience of knowing what victory is and being able to achieve it, an experience of comradery and working together, not competing. I think that’s where game design has a lot to teach us about how to work in teams.

Richard:

All right. And I took a note… Well, we will undoubtedly have a link or a QR code just popped up somewhere. People can find this book.

Jessica:

I like QR codes.

Richard:

I always joke these days that your web browser came with a built in camera.

Jessica:

That’s true, yeah. Did not have that expectation 20 years ago.

Richard:

I was also thinking yesterday about how people used to say, “Why would I want that? “I just want to talk on the phone.”

Jessica:

Yeah. Why would I want that.

Richard:

The last thing I want to do is talk on the phone.

Jessica:

Yeah, that’s a lot of things. Observability like distributed tracing is one of those things that, why would I want that? I have logs. Yet you just don’t know because your logs are like black and white film photographs that you have to take to the pharmacy and wait a week to get them back. And you’re… Until you’ve experienced a digital camera with a screen on it so you can see what picture you just took you don’t know why you need observability.

Richard:

Observability, why would I need that?

Jessica:

Yeah, it’s fine, it’s fine. I can just… I can just dig in logs and eventually figure something out probably.

Richard:

Right. All right, Jessica, we’re going to wrap up. Is there… If anybody wants to get in touch with you, is there a way they can do that?

Jessica:

I’m Jessitron on Twitter, J-E-S-S-I-T-R-O-N also jessitron.com for my blog. Oh, oh, oh, and if you want to just have a chat about something, if you have some ideas or questions, I have office hours available honeycomb.io/office-hours. And now that I’m officially developer relations, I get to just talk to random people.

Richard:

This is so cool.

Jessica:

So I would love to talk to you.

Richard:

All right, I love .

Jessica:

Y values of you.

Richard:

What a great idea. I love office hours, it’s great. Go join Jessica for office hours. Hey, Jessica Kerr, thank you so much for joining us today. It has been a lot of fun, thank you.

Jessica:

Thank you, Richard.

Richard:

And dear listeners and viewers to support this podcast, visit my website, kasperowski.com.