Episode 036: Metaphors and Microservices with Matt Stine


Coraline Ada Ehmke | Sam Livingston-Gray | Rein Henrichs |
Astrid Countee | Jessica Kerr | Janelle Klein

Guest Starring:

Matt Stine: @mstine | mattstine.com

Show Notes:

00:16 – Welcome to “Chinchilla Chat: Where It’s All Chinchillas…All The Time…” …we mean, “Greater Than Code!”

Want to help make us a weekly show,
buy and ship you swag,
and bring us to conferences near you?
Support us via Patreon!

Or tell your organization to send sponsorship inquiries to mandy@greaterthancode.com.

03:10 – Matt’s Origin Story in Software Development

09:04 – The Business of Consulting

16:24 – Empathy in Consulting

20:07 – Rigorous Communication and Shared Language; Microservices

Ludwig Wittgenstein

Sapir-Whorf Hypothesis  

Metaphors We Live By

39:05 Ubiquitous Language

Surfaces and Essences: Analogy as the Fuel and Fire of Thinking by Douglas Hofstadter  

Coraline Ada Ehmke: Metaphors Are Similes. Similes Are Like Metaphors.

Wittgenstein’s Ladder

Performance of Genetic Algorithms For Data Classification by Matthew Stine

Are you Greater Than Code?
Submit guest blog posts to mandy@greaterthancode.com


Matt: Ludwig Wittgenstein and language games.

Coraline: The shortcomings of pattern-matching.

Astrid: Using evolution as a model.

Rein: The Beginning of Infinity: Explanations That Transform the World

Janelle: Language as a mechanism of control.

Sam: Building a bridge of understanding with progressively less incorrect metaphors.

Please leave us a review on iTunes!


SAM:  Hello and welcome to ‘Chinchilla Chat: Where It’s All Chinchillas… All The Time…” I’m Sam Livingston-Gray and here with me is my fellow chinchilla, Jessica Kerr.

JESSICA:  [Producing squeaking sounds.]


JESSICA:  I’m not going to correct you, instead I just like to say how happy I am to be here today with Astrid Countee.

ASTRID:  Thank you, Jessica. I will remind you Sam that it is Greater Than Code, just to put that out there and I’m here with my great friend, Rein Henrichs.

REIN:  Thank you, Astrid, it’s my great pleasure to introduce Coraline Ehmke.

CORALINE:  Hey, everybody. For a long time listeners, you may be comfortable and used to a weekly show and we really want to be able to do weekly shows but unfortunately, with the level of support we’re getting from Patreon right now, that’s no longer possible. We’re announcing that we’re moving to a bi-weekly format. There are a lot of things we could do with extra funds and this can come from individual Patrons, as well as corporate sponsorships.

Beyond sustaining a weekly show, we’d like to focus on listener perks and swag for the people in Slack community who go above and beyond and are themselves, greater than code. We’ve also talked about doing conference appearances, which of course brings travel costs into the picture. If you are not yet supporting us in Patreon, I encourage you to do so at Patreon.com/GreaterThanCode and if you want to sustain the conversations, we also encourage you to talk to your employer about possibly sponsoring the show and we have information at GreaterThanCode.com/Sponsors.

JESSICA:  Also, can we say that it’s really exciting that we do have enough Patreon supporters to fully finance two episodes a month of this fantastic editing and transcription and website and social media, etcetera?

SAM:  Yay! That’s really wonderful, actually. One of the things that we really were hoping for when we started this show was to be able to continue to employ Mandy in doing the work that she does so well. I’m really glad that we can do that at least twice a month. I’m also here with Janelle Klein.

JANELLE:  There’s a lot of people on this call today and I am introducing Matt Stine whom I really excited to have here today. I met Matt a few years ago really just being a participant in No Fluff Just Stuff tour and he’s always been one of my favorite speakers just because he’s so anchored and pragmatism but so knowledgeable from software architecture standpoint and just being able to see so much scope and problems and patterns across the industry. He’s been one of the most fascinating people to listen to a talk to so I’m super excited to have Matt Stein with us here today. Welcome Matt.

MATT:  Very excited to be here. I love podcast composed entirely of chinchillas so I’m really excited to see what happens.


CORALINE:  Jessica is making more chinchilla noises.

JANELLE:  I got a question for you Matt, as soon as we can calm the chinchillas down here but I was just wondering how did you originally get into software development. Where did all of your excitement about this come from?

MATT:  How did I originally get into software development? It depends on which starting point we come from. If we start with say, I was… what? Seven years old? I don’t know. My dad woke me up and brought me into the dining room and there was this Atari 800 connected to a TV, sitting on the table and said, “Hey, I got a computer.” I’m like, “Cool. What’s a computer? You mean like the thing on Star Trek?” He’s like, “Well, not quite,” but he showed me some stuff and then we’re typing commands and I’m like, “What was this thing we’re typing stuff into?”

He says it’s BASIC. I’m like, “Okay, well, what does BASIC do?” He threw a bunch of family computing magazines in my lap and said, “There’s programs in the back of that, type them in and see what they do,” and that’s where it really started. But it was mostly this informal romance back and forth with computers and games and gaming and didn’t really do a whole lot of software development, although I did poke around a little bit. Then it came time to go to college and I had to pick a major and I said, “I kind of do stuff with computers. That seems fine. Let’s do computer science.”

Then I found out what computer science was, which was a really jarring experience but I honestly don’t think I learned a whole lot about software development in studying computer science. I learned algorithms. I learned all sorts of interesting things about data structures and of course, all those things are pieces and are related to what we do but we had this class called software engineering and every class, every year gets a theoretically real customer, usually somebody from the community around the university that needs some software built. We’re supposed to learn software engineering by building the software for this customer, which sounds great until you realize that nobody’s ever actually taught you how to do that.

We had the dubious distinction of being the first class ever that this professor had that actually did not deliver the software so my first software project was a failure. I learned to fail from Day 1 and got out into the real world and actually learned software development and really from a bunch of people who’d come from other places that came to this little nonprofit that did not have any kind of discipline or whatsoever and we kind of invented everything that we did as we went along, which was both really good for me because I got to explore a lot of interesting ideas and do different things. But really bad for me when I went to my first job that actually had legacy structure in place. I said, “We need to do this.”

“No, you don’t get to do that here.”

“What do you mean?”

“We don’t do it that way here. We do this,” and I’m like, “Well, that stupid,” and we kind of grew in and learned from there. Now, like seven-ish years on the other side of that jarring transition from we’re making it all up as we’re going along to going to help really large companies that are figuring out that the big process of things that they’ve created is not helping them succeed and figuring out how to actually get them closer to. Really a lot of the early experiments or weird stuff that we’re making up as we went along back in the earlier part of my career says this weird kind of full circle feedback loop and I don’t even know how I got to this part of the story but we’re here now.

ASTRID:  Matt, I have a question. You talked about how when you picked computer science for your major that it was really jarring, kind of a slap in the face and not exactly what you were planning and that your first software engineering experience wasn’t that great so what motivated you to keep going?

MATT:  I was going to run out of scholarship money if I didn’t graduate so I wanted to keep going and people kept telling me that I was going to make a lot of money and I had no money so making a lot of money versus no money sounded pretty good. This was maybe a year before the dot-com boom exploded. The fact that you could theoretically walk out of school with a computer science degree and make serious cash and actually be able to not eat ramen noodles and stuff like that, that was real. I thought some of this sucks but I wasn’t really acquainted with the idea that work could actually be separated from toil because I watched my father toil for my whole life: work with something that he hated and I thought that that’s kind of what work was like the thing that you did to make money so that you could do the stuff that you really wanted to do. I’ve since obviously learned that there’s so much more to it than that.

I just thought that things were hard and you needed to continue going so the fact that it was maybe not what I expected or maybe not the most fun, I thought well, maybe this is just how things are. It took me a while to break out of that mold of people would say, “This is the way this is. This is the way we do this,” and to say, “You know what? There’s a lot of structure and assumptions that you built up there, what if things weren’t that way?” And people kind of look at you, “What do you mean by what if things weren’t that way?” This is what I do all the time now is just kind of try to find the underlying structural assumption that people have about the way something should be and say, “Let’s set aside all the challenges that we think we have. Let’s challenge that and see what happens.”

JESSICA:  You must be a consultant because people who are usually like that from people who actually work with them.

MATT:  People don’t like a lot of the things that I do.

CORALINE:  I don’t like the fact that you dinged ramen. I love ramen.


CORALINE:  We don’t talk shit about ramen on this show.

MATT:  I like ramen. I just don’t like the stuff that I buy for 25 cents in the pack at the grocery store.

CORALINE:  MSG-flavored packets are so good.

MATT:  If that’s your thing, that’s great. Now, we did used to make this stuff that we called, ‘Oh, shit ramen,’ in high school with ramen noodles plus 18,000 spices and the whole goal was to see how fast you could make somebody sweat. That was entertaining and that was a great use of those packets. But I do like the fancy ramen that I can get down the street from the office. That stuff is really good.

CORALINE:  How long did it take you between your first job to becoming a consultant?

MATT:  I worked my first job for 11 and a half years.

JESSICA:  The one with non-profit or the —

CORALINE:  Yes, the nonprofit. The St Jude Children’s Research Hospital that’s in the bio on my website, for 11 and a half years. Then my next job, I worked nine months.

SAM:  Sounds more industry-appropriate.

MATT:  That was partly because I have a decent amount of need on a daily basis to have really good medical insurance for various family things that we have. This company’s medical insurance was almost as bad as not having any at all. I was paying ridiculous amounts of money for just almost nothing and I needed to find something else. VMWare happened to call me and say, “We’re looking to hire people who know Spring to go do consulting stuff and in the meantime, we’re going to give you this much,” and I said, “Let me do the math. That’s 37% more than I make right now. Yes, please,” and I became a consultant.

JANELLE:  Interesting to me because you seemed like one of those people that would generally have a hard time fitting inside of a box because you’re always challenging the status quo with everything. You fit well into that consultant thing where your job is to challenge everything. It seems like you would gravitate toward that, even outside of all these other kind of factors but maybe not. I don’t know. What do you think?

MATT:  It’s weird. I saw a consultant when I was working that original job and you saw people show up in suits with briefcases and telling you all kinds of things and language that you didn’t really understand. If you go back to the idea that we were the shop that started with seven people and eventually grew to 30 and we invented everything as we went along, it usually wasn’t based in, “Somebody told us to do this best practice because this would work and this is why,” to, “This thing hurts. Let’s figure out a way to make it not hurt. Okay, we fixed that. Now, this other thing hurts. Let’s figure out a way to make it not hurt,” so we kind of experimentally discover in the process that we had. It didn’t look like anything that anybody else did.

Then as we got bigger, people said, “Maybe we should figure out how other people do things because we’re getting big enough that we need to start acting like the big companies,” okay fine, so we brought in consultants. They said, “You’re doing everything wrong. You should do this,” and then we started trying to do that and everything got worse. My initial exposure to that was really negative and I kind of stiff arms, keep that away for a long period of time and it became the next obvious thing to do in my career that would help me, again make the money that I needed to support my family.

That nine-month job was the most important thing that I did to succeed as a consultant of anything I did leading up to that point because if I had only ever worked one place and I had never actually seen what went on outside of that artificial world that we had created for ourselves and saw, “This is how the big companies do it,” I would have been a really bad consultant because I would have been like oil and water as soon as I walked in to another customer and basically said, “You’re doing everything wrong,” and they’re like, “No, we’re not doing everything wrong,” and we would have never actually been able to communicate. I had some empathy for the people that I was now starting to work with as a consultant because I had experience the other side of that.

I had to evolve into the ability to do this work. There’s one thing that just challenge everything. It’s another thing to challenge in a way that people are receptive to that and that’s the thing that I’ve had to learn through doing over the last… I don’t know, I guess how long have I been doing the consulting thing? Maybe five and a half years?

REIN:  It’s really interesting to me that the market for consulting is so inefficient that those consultancy described having been pushed out of it.

JESSICA:  No doubt that implies that your objective in hiring a consultant is to do anything better. Seriously.

SAM:  Rather than doing something to do, something better?

JESSICA:  Yeah, I have an answer. Those consultants were bringing answers, right and you are bringing questions?

MATT:  Well, there’s model in this. My current view of what consulting feels like is very much driven by the way we approach things at Pivotal. So much of our practice is based in discovery and research and asking questions and trying to figure out what are the real problems that we’re trying to solve. Most of the consultants that I experienced before that were walking in with, “Here’s what you should do. I don’t even know who you are. I don’t know what your problems are. I don’t know what’s hurting you but you should do this.”

There’s another type of consultant, which was the consultant I’m friends with, who I would very often hire when I was in management for a period of time to say, “This is what I’ve been telling people and they won’t listen to me but if you say it, they’ll do it because you’re a consultant.” This actually as I found out goes on all over our industry right now, which is you need to be able to appeal to some of outside authority sometimes to get some change that you want to actually take place so you basically coach the consultant — who already agrees with — “This is exactly what I’ve been trying to say. This is what I want to happen.” They show up for a short term engagement, present this and it’s the same thing I’ve been saying for the last three years that nobody will listen to and he doesn’t go off script at all and all of a sudden we’re doing it.

CORALINE:  It’s like being a woman in tech.

REIN:  I’ll be honest with you, when I was a consultant one of the things I would do was survey the team, ask them what they think should be done and then pick a thing that they suggested and suggest it. The reason for that wasn’t so that I could take credit for their ideas, it’s so that I could take the blame if it failed and because they’d listen to me because they’re paying a lot of money.

MATT:  Yep.

CORALINE:  Matt, you mentioned empathy a little while back. How important is empathy in the work that you do.

MATT:  I think empathy is almost these center, the foundation of everything that I do because again, learning the hard way that trying to push change on people that aren’t at the same place that you are — I was having a conversation this morning about how in 2003, I went to an extreme programming conference and became infatuated with XP and then walked back into my organization and basically called a meeting of everybody and gave this manifesto and said, “This is what we’re going to do,” and people are like, “Yeah, that’s funny.”

The walk in with a big stick and swath everybody with that approach, doesn’t ever work, at least not in a positive way. You can make people do things if you coerce them enough but I wasn’t exactly in a position to do that. But the more of that I’m realizing that I have this place that I want to help people get to but they’re all starting from a different spot in their journey, either as an individual, as a team, as an organization and if I don’t tried to look at it from their perspective and stand in their shoes and understand the constraints that they feel like they have, the pressures that they feel like they have, it’s very difficult for me to communicate with that group, just trying to be them mentally, even emotionally because I walk into emotionally charged situations all the time.

One that happened a month or so ago at a large bank actually is still very vivid in my mind of two competing groups in the organization that have very different agendas that came to this meeting that had an agenda that was separate from either one of their agendas. Immediately, these two people — who obviously have some power — start co-opting the session and start trying to drive the agenda the direction they wanted to go, to the point where moments later, there’s 10 of us just standing there watching these two people arguing with one another about something that has nothing to do with what we were there to talk about and we’re like, should we stop them? What should we do here? We eventually just waited until the heat ran out in the room and said, “Let’s break for lunch.”

Then I walk back in and say, “We’re going to come up with a structure of this meeting that prevents what just happened, not to say that either of you are wrong but the rest of us didn’t really know what to do with ourselves and we’re not getting towards any of the goals that we said we were going to have on the agenda so let’s make a list of things that we’re not going to talk about and if they come up, you agree that if I say you can’t talk about that because that’s on the list of things that we’re not going to talk about, that you have to stop,” and people are really hesitant like, “Should I agree to this? I don’t really like this. Okay, we’ll do what Matt says.” The rest of the day was much better. In fact, most of the things that we said we were going to talk about actually never came up again and we got a lot of things done.

Sometimes you have to figure out, “There are some emotional political power play thing going on here that maybe has nothing to do with what we’re here but it’s infecting everything that we’re doing. Now, we have to figure out how to diffuse that,” but again if you walk in with a fixed agenda and you can’t be flexible and you can’t relate to where everybody in the room is coming from, it’s very hard to do that work.

Actually, what’s funny is that part of the thing that got my mind so much on this metaphor communication track recently was actually a result of that same meeting with that customer that I was talking about having to defuse all the crazy political driven emotions in the room. It’s pretty easy to segue into that conversation because in some ways, a lot of what I’m finding in a power struggle is people want to own the language because they feel like if they can own the language that’s used across the organization, they can control the conversation and drive it in the direction that they wanted to go, if that makes any sense.

REIN:  It just occurred to me that we’re going to spend the next 30 minutes recapitulating Wittgenstein.

MATT:  Really?

REIN:  Talking about language games and things like that.

MATT:  I’m not familiar with that.

REIN:  Wittgenstein was a philosopher, probably the most influential philosopher of modern times and one of his big concepts was that we all are playing a game with language and we each have our own language that we use and sometimes they overlap with other peoples and sometimes they don’t. We each have our own goals that we’re seeking when we play this game, with the language that we use and things like that.

MATT:  I’ve not heard that or articulated that way but it fits perfectly in with everything else that I’m thinking about right now so there’s probably a reason for that. That’s cool.

CORALINE:  There’s also the Sapir-Whorf Hypothesis that posits that the language that we use constrains our thinking. I think that what you’re describing could be considered weaponized language, where if you’re controlling the vocabulary of describing a problem, you are also constraining solutions to that problem to the space that you establish.

JESSICA:  Matt, can you give a concrete example of controlling language.

MATT:  Yeah. Right now the one that is happening everywhere that I go is microservices. Every company that I’ve worked with is now writing their definition of what a microservice is.

SAM:  — as definitions overlap.

MATT:  There’s some weird Venn diagram that we could draw that as differing amounts of overlap that eventually would become impossible to decipher. We’ll leave it at that but the interesting thing, going back to the weaponized language idea is that you find competing tribes within the organization that have their definition that they’ve come up with and they want their definition to win. Usually, it feels like it’s based in, “I want to establish constraints around people that I don’t necessarily have direct day-to-day control of so that I can control what they do because this is the organizational standard so therefore you have to do it this way.”

I have walked in to, again that same organization. I can think of maybe three or four different individuals who are with various different architect type titles, leadership titles that say, “I want microservices to have this bullet point list of characteristics and you have to do what’s on this list.” Part of that shouting match that we talked about was about differing opinions about, “Microservice should have this. No, it shouldn’t have this. No, this is crazy. What are you doing?”

JESSICA:  This reminds me a lot of Agile because the point of microservices that was each one could have different characteristics.

MATT:  Yeah, that’s not how the Fortune 100 conversation around microservices is going right now. It’s everybody is building a PowerPoint deck with, “Here’s what a microservices and here’s the characteristics that it must have.” Now, what’s really bizarre and happening that kind of sucks is that deck is now being broadcast to a huge organization of people who don’t have any understanding of what they’re paying told to do and they’re just naively going through and checking off the bullet points and saying, “Our service does this, it does this, it does this. Okay, we’ve built a microservice,” and no freaking clue why they have built one, what they’re supposed to be getting out of it, what the value is but they were told they’re supposed to build microservices so therefore, they built them.

Another organization, I’m giving a huge talk and there’s a question and answer session, somebody stands up and says, “We’ve got fifty microservices in our application and new ones are appearing every day and this really hurts. What should we do?” I said, “You should probably build less microservice,” and people laughed and it went back and forth a little bit. Somebody comes up to me afterwards, the sponsor of this particular event and says, “Let me tell you the back story to that question that you’ve got. His organization has been incentivized by their manager to build as many microservices as they can so that he can basically demonstrate to the rest of the org how awesome their little sub-org is at being on with the microservices initiative and all the stuff that they’re doing and here’s all these metrics that we have to demonstrate that fact,” but it’s leading the people who are actually living that life to experience ridiculous amounts of pain.

Janelle and I have been talking about lemmings a lot lately and we have all these lemmings and they’re marching off the cliff dutifully because they know that’s what they’re supposed to do but they fall to their death. They don’t know why because that’s what lemmings do. Maybe we’re doing it consciously and I just don’t know it but I feels like I want to believe that it’s unconsciously that we’re creating these legions of lemmings in software development in these large organizations that are going and doing all this work.

They don’t know why they’re doing it but they’re told that if they just do it, it’s going to solve all of their problems. It ends up creating new problems — big surprise to the group of people talking on this podcast — but very often the answer is, “You’re just not doing it right. You must not be microservicing correctly because microservices solve all your problems and so let’s try to microservice even more.”

Now, I this person who’s been hesitate to say, thought leader in this particular area, people pass around my little 50-page O’Reilly book like it’s the Bible or something and say, “You should do everything that’s in here,” and now I’m going around so you do know all that stuff I said about doing in all these microservices, I don’t mean this. Don’t do what you’re doing right now. This isn’t what I said and they’re like, “But you’re the microservices guy.” I’m like, “No, I’m not. I’m the, let’s build software and solve problems guy and microservice is a tool in my belt but no. Stop. What you’re doing is going to hurt. It’s not going to end well.”

REIN:  Your book isn’t just one page that says, “Microservices. Yes, more of those please?”

MATT:  I think that’s what people have translated it to.

REIN:  It’s interesting to me. We could probably have a whole conversation on the choice of count of microservices as a proxy for successful implementation of the microservices or whatever.

JESSICA:  It’s like the line of code metrics.

CORALINE:  Yes, Jessica.


JANELLE:  It’s interesting to me too because there’s a whole control dynamic here going on with internal fiefdoms competing against one another and then trying to come up with some metrics that gave them control to influence another organization and then using language tactics and things like this to own vocabulary. There’s a whole entire empire building thing going on. One of the things I see happening on the engineering floor is it’s so difficult and takes so much energy to fight the momentum at that organizational empire level that people just decided not to care because it’s easier. At some point it is like, “Whatever, we’re all going to walk off the cliff. It’s fine by me,” and like genuinely choosing not to care anymore as a coping strategy.

SAM:  If we can, I’d like to go back to something you said a little bit earlier, Matt about how there’s these different competing definitions of microservices and architects are putting together PowerPoint slides and saying, “These are the characteristics that your microservice must have in order to be considered a microservice.” I’m as cynical about corporate power structures as the next person but I really want to give people the benefit of the doubt and I wonder how much of that comes from the architect’s previous painful experiences of like, “I tried this and it sucked and I’m trying to save you from that by just telling you the answer,” despite that strategy perhaps not being the most successful one for actually getting people to do what they should be doing. What do you think about that?

MATT:  I think that most of the time these efforts come out of a place of good intentions like what you just described like I’ve been down Road X, I have the scars to prove it and I want to help you not feel that same pain and that part is good. I’ll probably butcher the cliché but that’s fine of you can’t solve the problems that you have with the techniques that got you here. The various forms of the thing being said but it’s like, “This thing hurts. I don’t want people to repeat that so I’m going to tell people how not to hurt themselves by following the exact same process that I followed to hurt myself in the first place.”

One of the biggest examples I had of this — I only deal with large organizations right now because that’s who we try to sell to — they sent me this 150-page Word document that describes their microservices strategy for the organization. As painful as it was to read it, I read it. It was a mishmash of cargo-culted paragraphs from blog posts from Martin Fowler and other people that have authority. Eric Evans was in there and all kinds of things, then it describes this reference architecture that as I talk to people in the organization, I found out what they basically did was they took the thing they already had and rename all of the things to match the terms that are floating around in the industry right now and change the technical stack to be basically with our Spring Cloud Foundry stuff with some other things thrown in there.

I said, “Basically what you’ve done is you’ve created what you already had with new toys and you went to great lengths and pain to do it. The whole point in my mind of going down this road is to free you from the very constraints that you’re actually trying to reimpose upon yourselves,” and they’re like, “Yeah, but we have to have these constraints.” I’m like, “Well, let’s look at that from two different directions. One, we can challenge whether you have to have those constraints or not but that’s a hard conversation. We don’t have to have that one right now. Let’s have an easier conversation. You have to have these constraints. Why do you need to change anything then? because you’re actually making it harder for you to enforce these constraints with this new set of disciplines and techniques and technologies than what you already had, because the things that you already have are actually designed to enforce those constraints and you’re now trying to take something that’s designed to free from those constraints and use it to enforce these constraints.”

They’re like, “We’ve never really looked at it that way before.”

SAM:  And they’re using tools that don’t have those constraints.

MATT:  Right and so I was like, “How do I do control X with microservices technology?” And they’re like, “We don’t.” I’m like, “What do you mean? How do you not do control X? Have to do control X.”

“What is the goal of control X?”

“Well, to prevent those –“

JESSICA:  Transactions.

MATT:  — other things. We’ll prevent that thing from this –” Oh, let’s not even talk about transactions.


MATT:  I just don’t want to go there. That’s just such a bad, bad place but everybody’s going there so we should probably go there too.


JESSICA:  And that is one of the constraints that people are used to from a relational database like Oracle. But when you go to microservices, you don’t get that.

MATT:  That’s probably actually okay in a huge percentage of circumstances but because we made transactions so easy, we made everything transactional. Now, it’s hard for us to even conceive of a world that has things that aren’t transactional so when I say, “Think about the process as separated from the software. Is that process inherently transactional by meaning ACID transactions? Is it truly atomic, which is usually we don’t have to go beyond atomic. But is it truly atomic?” They’re like, “Actually, this thing happens one day and this other thing happens another day in the real world.”

I’m like, “Then why are you trying to make software do anything but that and I’m not even trying to tell you to have it spend a day. I’m trying to tell you have it spend seconds and you’re resisting seconds but the actual thing that happens in the real world is taking multiple hours and we get tongue tied because we’re walking into a set of fundamental assumptions and were saying, poke that one and kick that one out and now reformulate the world.” All of a sudden, not only is it more freeing but it’s also more scary because we haven’t been there before and this constraint, while it’s limiting, is also feels like protection.

JESSICA:  Like it’s comfortable?

MATT:  Yeah. Going back to the original, I want to define the language conversation, it’s because we’re trying to find a structure. One of the things that Janelle throw this book at me metaphorically and I’m digging through this bit about structural isomorphisms between different things. The one that they’ve been beating on now for a while is argument is war and it points out all the language that we use when we’re talking about arguments. That’s all based in talking about war.

They extrapolate on that a little bit so I started thinking about how does that play out in conversations that I’m having. The thing that I stick with is people come with the structure that they want and then they tried to create a mapping from the popular conversational metaphors to the structure that they want, like why do I care so much about owning microservices and bounded context and all of these things as terms. If I can own those terms, I can map the structure that I want and I can appeal to outside authority at the same time. I can get power from the words but then use the power and inherent in the words to actually get this other thing that I want.

ASTRID:  What you’re saying, Matt sounds like something that I heard recently that was about interviewing. It was not about technology at all. One person was talking about like when you got and interview somebody, you have a way that you try to make them feel so that you can get what you want out of the interview. His version of it was trying to make people feel at home so he would try to be welcoming and eat whatever they gave him or drink whatever they gave him. He was saying there’s another interviewer, I think it was Jorge Ramos who’s interview style is war because he is used to being a person who learned journalism in Mexico where the press was marginalized and suppressed. He’s used to having to poke at the bear to get the answers that he wants so his interview style is much more aggressive.

Maybe it’s related to what you’re saying because if you’re in an organization, where in your position, you have to be aggressive, then when you’re talking with your own staff, you’re going to be like that, whether you realize it or not and be less open to their suggestions as opposed to somebody who might be much more like collaborative in trying to gather all of the information. You’re not going to notice that you’re not talking the same language.

MATT:  Yeah, so the extensions of that — and I think that’s right on — is that I, as an observer without that context of why I’m behaving the way I’m behaving, sees that person being aggressive or sees that person being welcoming and saying, “That person behaves this way and that person is successful, therefore if I behave that way, then I will also be successful and I divorce the practice from the context.” That same aggressive behavior that works in that context taken into a context where aggressive behavior is viewed as pathological is going to blow up in your face. That’s an obvious example. But the less obvious example is if I do what Netflix did with their software, I will be successful in software but we’re forgetting the very important point that I am not Netflix.

SAM:  My problem is not their problem.

MATT:  Exactly and I’m not to say that there are no other organizations that can use the exact same set of practices and techniques and be successful. It just means that not necessarily you. It could be you but may not be you so it’s probably better to figure out where we are and try to get to where we need to go.

SAM:  As kind of a follow up to my previous question about people who have come up with their own language around defining the constraints that they want to impose on everybody else, I’m wondering how you can facilitate a conversation between people who have different words and different idioms that they’re using to try to impose these things and if you can get those people to come to some common agreement and how do you do that?

MATT:  I probably haven’t done that exactly the way you posed the question and that would actually be interesting. You’ve got a couple different scenarios. You’ve got two people showing up with different words for the same thing. I usually have, maybe the inverse of that which is people are using the same word to mean different things.

SAM:  That never happens in software.

MATT:  Right, it’s everywhere. One of the things that I’m using, I think more as a trick than it is a technique right now is to double down on the fact that everybody seems to be newly obsessed with Eric Evans and Domain Driven Design. I start talking about ubiquitous language and I start saying that, “You’re using a word to mean this and you’re using the same word to mean something different and that’s leading you to frustration.” Eric Evans talked about this problem and I expound on the whole idea of ubiquitous language in a nutshell being that when we use the same words, we mean the same things.

Sometimes, I’ll even go often to talking about, “And that’s what a bounded context is. It’s a domain model that has ubiquitous language,” but depends on how excited that particular group is about that term or not because most of the time it’s a language that they picked out of the industry conversation. We talked about microservice. I’ve mentioned bounded context as another term. There’s a lots of these there floating around right now so they’ll grab one of those terms that people are saying is, “This is a good thing. This is something that you should strive for and they’ll define it to mean what they want it to be.”

I’ll say, “You know what? That thing that you want, that’s valuable. That’s a good thing and this other thing that you want, that’s different is also valuable and a good thing. Let’s name those things.” You don’t get to use microservice as the word for that thing. You need to call it something else.

I kind of go back and forth with them a little bit about if you find things that are valuable, you should make up a language that makes sense to you so that other people in the organization — when they encounter these terms — they’re not confused because I read this book that said that word meant this or I read this blog post that said this word meant something else. You’ve defined within your organizational lexicon that this term means this thing that you value as an organization and that helps diffuse things a little bit because I was like, “Oh, cool. We get to invent new words. That sounds like fun.” That helps a little bit. It helps people to feel like the ideas that their brain to the conversation are in fact valuable ideas, instead of being told, “You’re wrong. That’s not what a microservice is,” because I’ve tried that strategy and that strategy doesn’t work very well. They feel like, “Oh, my thing is good. My thing just needs a name and the name that I’m using is confusing because it’s defined elsewhere,” and I understand that. That feels right.

Then we start to get into a useful language defining conversation that feels a little bit like modeling and who doesn’t like modeling a problem space and giving names to things? Then you’ll say, “You know what? We’re creating ubiquitous language right now, at least amongst the group in this room,” and then now we can use that to expand and educate other people in the organization, instead of confusing them by redefining all these words that they’re either already using or they’re encountering in a conference talk or a magazine article or something else.

CORALINE:  There’s a recent Douglas Hofstadter book that talks about metaphors and similes as the fuel and fire of thinking. One of the things that’s pointed out in the book is the supremeness of metaphors. I think we’re particularly susceptible to this in software development because we are not really involved in neologism so much as repurposing existing metaphors. We use smoke tests, we use server, we use client, we use composition, we use all these words that have barred from different disciplines and I think it’s only natural that, as human beings we conceive of these terms differently. We mapped the metaphors differently. I think neologisms is a really interesting way to frame a solution to that problem.

JESSICA:  Neologism. Does that mean making up new words?


JESSICA:  Did you make that word up?

CORALINE:  No. Yes, I invented that word.

REIN:  Matt, this idea that you’re talking about of universal language, I just want to mention is exactly the concept of language games by Wittgenstein. It is building a shared group of concepts that you use to describe your shared activity in the real world.

MATT:  Yeah. The interesting thing, when you’re going back to that metaphors we live by a book, the premise of that book and I’m only about a third of the way through it at this point but I already feel like I’ve got probably a few months’ worth of things to think about just from reading that third of the book, is that we kind of have these metaphors that are so ingrained in the culture that we use them without realizing that they’re metaphors. The argument that it is war is one that’s easier to see but there was one that was really good. Janelle, you should be able to jog my memory on this, maybe.

There was the whole structure in there about talking about things that aren’t containers and calling them containers because he would say that a person, for example, is in love. If you’re in something, you’re inside of a container so the metaphor is actually that love is a container. He talked about that a little bit and I can’t remember half the stuff he said. It was really good stuff but we walk around communicating in these metaphors all the time and he makes this statement that really there is no such thing as non-metaphorical conversation. At least what I take away from it is that you can actually walk everything back to a metaphor and it feels like there’s this concept that eventually you should get to things that are atomic and there’s a whole chapter in there that challenges the idea that there’s actually anything that’s atomic from an idea perspective, that you can always take something and break it down even further.

CORALINE:  Hofstadter talks about that as well. In a talk that I gave recently which is called, ‘Metaphors Are Similes. Similes Are Like Metaphors,’ I talked about how the standard scientific method is about seeking the atomic components, about solving small problems and composing solutions to small problems into a larger solution. Then we have something like category theory, which says the small pieces don’t matter. Let’s look at things from an even higher perspective and find the similarities that way and compose a problem-solution pair that is about shared characteristics, rather than differences.

REIN:  We’re talking about how to bridge two different people sort of universes of language so they can share an understanding of something and we’re talking about metaphors and their relationship to some truth. Metaphors don’t actually describe the thing. If they perfectly describe the thing, they wouldn’t be metaphor. Metaphors are leaky analogies or are very leaky abstractions. Wittgenstein has another concept called Wittgenstein’s Ladder which might be more familiar to some people as lies to children, which is where we attempt to bridge a differential in understanding between two people by saying something that is not true but is more true than their current understanding. If you do that enough, you eventually bridge that gap with the caveat that you then have to throw away the bridge that you’ve built because it’s no longer hopeful, because it’s a lie.

MATT:  That’s simultaneously fascinating and terrifying.

SAM:  Don’t take off in the middle of that process.

REIN:  Strong agree.

JESSICA:  If you give people a whole list of check boxes for what it’s a microservice for instance, some of those are like with those equality, the [inaudible] resilience or [inaudible] breaking. Some of those are going to be within reach and useful now but some of them are not.

MATT:  The one that I think is both the most misunderstood and also the most dangerous is this database per service concept. There’s this idea that I think’s a very valid one that if you have a bounded context and you’ve got this domain model that has a boundary put around it that controls what comes in and what goes out so that you can protect the integrity of the language you use within that circle. One of the things that we say is you can’t have a shared database across multiple-bounded contexts because then I can actually not go through your front door to engage with you. I can go through the back door and talk directly to your data and make it do the things that I want to do or get the information that you say I can’t have. That’s important and valuable and it’s a principle that I think is interesting.

What we’ve done is we’ve taken that and we have turned it into a bullet point on a slide that says microservice should have their own database. Or even worse, every microservice should have its own database. Notice the difference there?

SAM:  Now the implication is microservice should have a database.

MATT:  Right.

JESSICA:  Whether they need one or not?

MATT:  Yes. Exactly.


MATT:  And so, I walked into an architecture’s conversation. They’re showing me they’re like, “Every single microservice had a database,” and I said, “Why does this one have a database?” They’re like, “Because it’s a microservice.” Like, “Yeah but why does that microservice have a database?” They’re like, “Because every microservice has to have a database. That’s what makes it a microservice,” and these were genuinely confused people. They had been taught this and they were doing what they were told. It’s worse than cargo culting. I don’t know what it is, like cargo culting, “We adopt something, we don’t know why we adopt it. In this world, we’re doing something we were told to do and we don’t know why we were told to do it but it’s the rules because it was in the slide deck that said this is how you microservice and we were told we have to microservice.”

There are these things that we put on the list that are based in some truth and because we want to simplify it, we want to get people closer to this thing that we want people to adopt in a way of building software, the simplification becomes actually adopted as the truth, which is the thing that I thought was so scary about as you said is we built this bridge and then it’s appropriate to throw it away at some point but not only do we not throw it away, we actually double down on it.

REIN:  Yeah, you sort of engrave it into the structure of your organization and say, “You have to understand this bridge. This bridge is now part of our organization,” when in fact the bridge was only there to get everyone to a shared place of understanding and past that point is counterproductive.

SAM:  But the bridge was given to us by an authority and that short circuits a lot of stuff in our brains.

REIN:  I mean, we can get really mad in here. We can talk about how do you create knowledge in another person’s brain. We’ve talked about through rote just by telling them the thing and how that often isn’t very effective because they don’t really internalize it. We can do it by building a bridge through metaphor and through analogy. I think, Jess you were talking about earlier, sometimes it’s important to let people fail because sometimes the best way to gain your knowledge is through experience.

JANELLE:  I feel like the other major theme here is that everything is this solution-centric conversation and everyone gets caught up in this argument of what the solution is supposed to be and everybody’s forgetting about what problem it is we’re trying to solve to begin with that at the end of the day, getting back to the pain, getting back to the problem that we’re trying to solve is the thing that I think anchors everybody back to that same goal and purpose of why we’re here to begin with. It’s just so easy to get lost in all the solutioning that we end up just forgetting that.

SAM:  I think that as technical people, we also have an obvious bias towards solutions and shiny new toys, which does not help us in any way in this conversation.

CORALINE:  I know, let’s replace our government with software. Let’s all be technocrats. Every constraint on a system is a scar from a previous experience.

MATT:  There was an interesting conversation that we had on Twitter, I guess two days ago and it was a broken conversation for me because I started it as a flight was getting ready to take off and then I’ve continued on in-flight Wi-Fi poorly and then I started again while I was trying to get out of the airport — this is how committed I was to this conversation — and I forget exactly what the trigger was but we were talking about this transition from this thing that Simon Brown calls a modular monolith, all the way over to the microservices as an evolutionary thing and why that’s a good way to go.

Adrian Cockcroft pipes in and says, “In Netflix, we spent like X number of months –” or years, I can’t remember it was, “– struggling and trying to build a modular monolith and we have initially eject it and went to microservices.” And I asked the question to follow up and say, “I bet you learned a lot through that struggle. Do you think –?”

SAM:  Are you assuming it was a struggle?

MATT:  Well, he said it was a struggle. I said, “So you had a struggle there. I bet you learned a lot, do you think that you would have been as successful had you not had the struggle? Had you just gone straight to microservices on Day 1?” He responded. “No, we developed and anti-architecture of painful things to stop doing,” was I think his exact quote. That really resonated with me because the thing that I felt going through my mind in the earlier part of the conversation, maybe a couple minutes ago, was solutions versus what problem we’re trying to solve. It feels like an economic problem. If we could just get the right solution on Day 1 and just implement it, that should be cheaper than struggling through the figuring out of the problems stuff because that takes time and effort and that time is not free.

But if you pick the solution on Day 1, assuming that it’s going to be correct, it looks like, “We didn’t go through all that stuff, all that discovery process, all that figuring out the problem. We just have the solution so we saved all that money,” and then it blows up in our face later on the project and we end up paying for that and probably paying beyond what we would have originally paid, had we just struggled through the original discovery process.

SAM:  It will just blow up.

CORALINE:  That’s why I like to say that monolith is sort of an important part of the evolution on any software system because creating a monolith — the system — lets you define the domain and you have no idea what services you need until you thought the pain of having everything be tangled.

MATT:  Right. Exactly.

SAM:  And having the monolith gives you the ability to move things around without crossing a service boundaries that are significantly more expensive than module boundaries.

CORALINE:  Yeah, you don’t even know what those service boundaries are when you’re just setting out to solve the problem because you don’t have that perspective yet.

JESSICA:  Matt, you mentioned that you tried to put in the solution to all the problems that you’re going to have at the beginning and then it blows up. How does it blow up?

MATT:  By blowing up meaning that we adapt a solution without going through this process of discovering and finding where the pain points actually are, where the boundaries ought to be so we get a completely different set of — going back to the idea of accidental versus essential complexity — accidental pain versus essential pain. There’s pain that’s inherent in the problem that we’re trying to solve and we adopt a solution that doesn’t address that pain so we now get different pain, which is the pain inflicted by the solution on the things that the problem didn’t actually inflict upon us.

This is manifested in a lot of clients that I’ve worked with where they set out and they figured out, “We’re going to draw all these microservices on the whiteboard and these are good so we’re going to build that,” and then six months into that project or a year into that project, they come back and I say, “Show me the architecture,” and it’s not the same architecture. Usually, they have less services than they had before and say, “What happened to this?”

“Those services made life worse so we backed them back into monoliths,” which one of the very first things that I did before microservices [inaudible] in the term that [inaudible] around, I was working in the world of OSGi and we have built this whole architecture based on different OSGi modules. We did a very bad job of defining our modules and OSGi made our life a living hell. One weekend I said, “Screw it. I’m backing OSGi out and I’m recreating a single codebase.” The pain of the modularization that we needed was still there but all the pain of the stuff that we had created artificially went away.

I am well-acquainted with a bunch of microservices and then back it back into a monolith. It’s a painful expensive process to go through so myself and a couple other folks have theorized from different directions, maybe we should defer the creation of the distributed system. I don’t want to say things like to the last responsible moment because people have used that in weird and crazy ways but defer it until something obviously hurts and then figure out is separating along a boundary of where this pain point is, is that going to potentially make the problem better? Do that one thing. Do that one thing and limit the expense to attacking that one pain point, which should be a smaller experiment than we’ve got 25 microservices and we need to go back to 12 or we’ve got 12 and we’ve got to 25. Then experiment.

Is this better? If it is better, great. We’ve got a microservice and we’re going to run with it. If it’s not, it shouldn’t be nearly as disastrous to bring it back in. In fact, we should just be able to, in theory, revert to that particular commit in the codebase and move forward. But that seems to be a better approach. Now, what I haven’t done is taken this approach out and run with it on multiple projects to see if the theory is correct or if it’s just as busted as the other idea. But it feels like it would be better.

REIN:  Matt, I think you talked earlier about this as evolutionary process and Coraline, I know you said that too. I think that’s such a useful metaphor for this that we should unpack it a bit. For one thing and this allows me to get on one of my favorite horses, evolution is a process whereby progress is made by making choices that are in aggregate better than random chance. It turns out that’s actually all you need to make progress on some time scale.

The other thing is that a lot of people look at this problem, I think as a path-finding problem or you say, “There is the goal. Let’s find a path to that goal,” and the problem with that is that implies we know what the goal is, where really it’s a different kind of search problem where we don’t know where the goal is and we won’t know until we get there. There is no way that you could just pick a random point in the space and say, “Let’s go there because we think it’s where we’re supposed to be.” I think, in thinking about this in terms of evolutionary search of this problem space is a really good metaphor.

MATT:  Yeah. When I actually did my undergraduate thesis on and then published another paper on in grad school was using genetic algorithms for optimizing search spaces. I’m pretty familiar with the idea of, “I’ve got a haystack and there’s a needle in there somewhere but I don’t even know what the needle looks like or if it’s even really a needle but I’m going to go look for it anyway.” I just start throwing solutions up the problem space and tweaking them in various ways, using again metaphors to biological processes to see if we can come up with better solutions.

Now, Neal Ford and Rebecca Parsons are working on a book on the same level from an architectural standpoint called Evolutionary Architecture and they’re not implementing genetic algorithms so much as they’re borrowing the concept of a fitness function and saying, “We’re going to define a fitness function for the things that we find valuable in an architecture and then use that fitness function to evaluate our architecture at various stages of evolution and either the architecture is getting better or the architecture is getting worse and that will allow us to drive the decisions that we make in different directions.”

REIN:  It’s always interesting to me how this is well-explored in the software engineering domain than at the process in organization level, lags behind by decades.

MATT:  True.

SAM:  It seems to me that the costs of doing some genetic algorithm are relatively well understood in software and you can do thousands of generations in a reasonable amount of time, whereas if you tried to do a truly evolutionary process in an organization, you would run out of money long before you got anywhere.

REIN:  You know, it’s interesting there are cases where you can take this aggregate approach to problem solving. If you need to solve a problem, you can buy 10 tools that you think might solve the problem, then maybe one of them does and maybe it’s cheaper than having developed a tool in-house. There are times where you can do it but there are also other ways to do better than that aggregate method.

MATT:  One of the things that I see a lot is at the organizational level is our obsession with reuse of we want to make sure that we only develop one service of this type and that service is going to be the one that does that type of work for all time, which again flies in the face of the whole microservices that should actually be now easy to replace and you should be able to create new ones cheaply and throw things away. I kind of challenge that with notion of like why are you trying to control that? Why not let multiple services that do the same type show up in the organization and then whichever one actually ends up being used the most and delivers the most value, that one survives?

Once a service is like no traffic has been routed to the service for three months, maybe we can turn that one off. Depending upon who I’m talking to, people are either fascinated or terrified by that idea because so much of governance is about controlling and preventing those types of things from happening but it seems like an approach that, again I haven’t seen done it scale but would be very interesting to see an organization and say, “You know what? We’re going to stop that particular type of control and allow the service typology to actually evolve and use some function to evaluate which services survive and which ones do not and see where that goes.

SAM:  It seems like in order to accept that, you would first have to accept the idea that your first idea of what that first microservice in that category was, you actually have to give up the idea that that was the right choice. You really invested in that, right?

MATT:  Yeah. You know, I think that’s one of the things that the earlier incarnations of kind of when we were figuring out this Agile thing of we rewrite a test and then we make the test pass and then we’re supposed to refactor. The refactory thing tends to get set aside because I wrote that code and I labored over that code and I’m really proud of that code and I want to keep that code around. We promote that idea to larger and larger and larger structures. I saw some cost-fallacy flyby in the chat a little bit earlier, we haven’t learned that thing because we invest in an architecture that we know to be poor but we’ve invested in it so therefore, we need to keep it.

The best crazy example of that that I remember is a project from four years ago where we were working with an organization that shall remain nameless as always and they were doing scrum — I’m doing air quotes right now for folks that can’t see me — and they had done their sprint planning and we had something that we were supposed to bring to the project and we were late but we showed up four days into this sprint. The sprint was going to be a month and they said, “We’ve got the thing now. Can we start working on it?” I said, “No, we’ve already done the sprint planning. You have to come back next month.” They said, “But we have new information that invalidates this.”

“It doesn’t matter. We’ve done the sprint planning so therefore, you have to show up next month.” It’s comical and tragic at the same time but there are so many examples of us doing exactly that, of we have created something whether it’s a plan or a piece of software or an architecture and we know. We now have new data that tells us this is wrong. But the process says or something else says that we have to go on. It’s irrational but at the same time, it’s so prevalent. I don’t really know how to cut through that other than to say, “It’s irrational and we need to cut through it,” but yeah.

SAM:  The best summation of that pattern that I’ve heard so far is defining the waterfall process as ‘a shared agreement not to learn anything for the duration of the project.’

REIN:  There’s a mental model of it that I use that comes from Karl Popper, a philosopher of science who’s probably best known for this notion of falsifiability that was pretty popular while ago. His political philosophy, which you can take or leave, incorporates the idea that we focus a lot on making the right decision. We put a lot of time and effort into making the right decision but it turns out, that’s not the only way to achieve progress. You can also achieve progress by recovering from bad decisions. If you do that enough, you’ll eventually have the right ones will stick. If you have a culture that focuses on recovery from failure, rather than preemptive and trying to make sure you never do anything wrong, that culture can be a lot less fragile.

JANELLE:  Going back to the whole metaphor thing, I think one of the foundational metaphors that drive a lot of this type of behavior is the manufacturing metaphor. When we think about our software as we’re building these little parts and they were putting these little parts in a box and shipping them to customers, that metaphor is so foundational to our thinking that this idea that we’re going to perfect things up front versus that evolutionary process, you’re talking about of being able to adapt after the fact that we need to move to a mindset of software is inherently a discovery process and that we’re always going to get it wrong and we’re always going to make mistakes. The best way that we can make progress, as you’re saying and evolve toward whatever that goal is that we don’t even know yet is to learn how to respond to the pain and observe the pain and figure out how to adapt from those things as early as quickly as possible.

CORALINE:  We probably need to stop talking about iteration and start talking about evolution because iteration is not a metaphor and metaphor is more powerful than descriptive terms.

SAM:  We would love to continue this conversation but we are running short on time. We, unfortunately need to wrap up the show and get into reflections. This is the part of the show where we talk about something that is maybe going to stick with us, that we learned or that we maybe want other people to spend some time thinking about. Matt, would you launch into that?

MATT:  Was it Wittgenstein that we mentioned earlier? I was not familiar with that particular philosopher and the whole language games thing but I have definitely added something additional to my reading list from the conversation because, again going back to the idea of metaphors and trying to create isomorphisms, once I see something that shows up in more than one place, I want to go collect as many other examples of things like that as I can to figure out, “Am I actually seeing a pattern or am I not?” Now, I’m fascinated by a new potential candidate for that list. I have homework to do.

CORALINE:  I’m going to be doing some thinking about the shortcomings of pattern matching. We didn’t specifically talk about pattern matching during the show but I think it was a subtext where we see what we think a problem is and pattern matching tells us what the solution is, regardless of whether it’s actually appropriate or not.

ASTRID:  I actually really enjoyed the talk about using evolution as a model. One of the things I really like about that is that evolution occurs because of mistakes and I think it’s a good idea to remind ourselves that allowing for mistakes to happen gives us the opportunity to see a new way that we can adapt what we’re doing and actually utilize that to make ourselves better.

REIN:  Astrid, that actually reminds me of a thing I wanted to say before but forgot, which is sometimes the best thing for an organization to do is to make it cheap and easy to fail, rather than to succeed. My reflection would be I want to mention a book called, ‘The Beginning of Infinity,’ that sort of expands on this Popperian idea of how to make progress just by correcting mistakes. It’s a little bit woo, a little bit philosophy, a little bit science. It’s pretty interesting book and that definitely gave me a lot to think about.

JANELLE:  I’ve been thinking a lot about this idea as language as a mechanism of control and constraining the vocabulary and space of meaning as a means of controlling the thought patterns and stuff of others. I’ve never really thought about it that way but it’s amazing to think about how a tribal argument is war, can take place via language control.

SAM:  For me, the thing that really caught my attention — I mean, there was so much — the idea of building a bridge of understanding with progressively less incorrect metaphors is when I heard that I thought immediately of the process of raising my daughter who is now eight almost nine. That’s something that I’ve definitely been going through. I haven’t really thought about it but when she asked questions that I get frustrated and trying to think about how to answer them, I’m realizing that it’s because there are several segments of that bridge and I’m not sure I have time to build them all right now so that I can answer the question to her satisfaction, so thank you for that model. That’s really useful.

ASTRID:  Thank you, Matt for this great conversation today. I think you gave us a lot of stuff to think about. Especially, now my head is very twisted with metaphors and trying to understand how and talking and listening to other people. Hopefully we can have more conversations like this where we get to go on for a little bit longer than usual but to all of our listeners out there, thanks for listening and will see you in another couple of weeks.


This episode was brought to you by the panelists and Patrons of >Code. To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode. Managed and produced by @therubyrep of DevReps, LLC.


Amazon links may be affiliate links, which means you’re supporting the show when you purchase our recommendations. Thanks!

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.