Software through Wabi-sabi
Permanence and certainty are not always something you have, rather it’s what you work to achieve.
Tim Jarratt can explain many things about the ideas of uncertainty, failure, influence, feedback loops, and abstractions that each include the core elements of imperfection and incompleteness, and how those are actually the goals we should strive for.
Tim’s demeanor is immediately disarming, and he has a way that he speaks about hard realities that inverts them into mysteries worth exploring. At first blush, you could mistake it as inscrutable, but you would be wrong and quickly learn that he is clear, thoughtful, and willing to explore discomfort in order to find comfort.
There is a Japanese world view called Wabi-sabi, that promotes the idea of accepting transience and imperfection. When you talk with Tim, you understand pretty quickly that he invests a lot of his thought and energy into this worldview, and how it could make software development better. While we visited, he was juggling what looked like small bean bag sack balls.
Tim shared his thoughts about juggling, and it was deeply considerate and intimate. He says:
As an engineer, I have a very hard time keeping my hands off the keyboard. When I would pair program I had a variety of techniques for this, but it’s harder when everyone is fully remote and most people are multi-tasking. I juggle to keep myself accountable in remote calls and meetings. If I’m juggling, I’m listening or speaking. I’m not touching the keyboard, I’m not reading email, I’m not looking at the code we’re thinking about, I’m present.
At the moment, it was curious, but after a bit of our conversation, I realized I could see it as a physical metaphor for the fluidity of the conversation and the constant iteration of thoughts. It is also a very interesting parallel to the intrinsic value of Wabi-sabi, because it is the “present” that counts and not the past or the future, and in the present, things are evolving, moving, breaking, and repairing.
Tim currently lives in France but says, “I spent 10 years working in San Francisco before I came here to France, and so, like, in a certain sense, the last person I was who was an American was San Francisco.” Immediately this confronts the notion of transience the way he said: “the last person I was,” and lays a groundwork for the rest of the conversation.
I was born in Emeryville in the East Bay, and grew up on that tiny little island in the San Francisco Bay called Alameda, that looks out onto the city so I could look out and see the fog cover the city, but never actually reach us.
When I asked where his favorite place on earth is, he said: “My happiest place on earth is hard, because once I visit a place it loses all the magic.” Again, you find that imperfection is quick to his tongue, but it’s not the point. The point is that happiness can be found iteratively, in many places.
I would say right now Tokyo is the place where I want that to be. That would be my happiest place on earth. But I haven't visited there yet, it's my favorite place too long for. Ok, I’ve thought of my favorite place on earth. It's sitting in the woods around the UC Berkeley campus with the river running through there. There's Redwoods, that was where I discovered Haruki Murakami. That is definitely my happiest place on earth. It's just very calm.
As he mentions reading books, I asked if he has found that he learns the most from books, people, or places.
It depends on when you ask me that question. If you would have asked me five or six years ago, I would have said people. I learned a lot from people. I learned a lot from just sitting down next to a human being and writing software with them. But I spend a lot more time reading and reflecting on systems. What causes people to behave a certain way? What are the various forces that cause people, or an organization, to work a certain way? And for that I just read a lot of books because it's hard to find people who think the same way. Not everyone knows about systems theory. So you basically have to go read books to get that kind of insight.
I asked Tim whether he is a pen or pencil person and his answer provides another glimpse into his Wabi-sabi thinking. He says, “So just looking purely by what's on my desk and in the pencil holder that my son crafted at school, it's pens. It's like 99% pens.” He goes on about the idea of imperfection.
Yeah, just don't make mistakes.
On the face of that comment, you’d imagine Tim is saying to be perfect. But quickly what I understood is that he actually intends to never recognize mistakes as something wrong, rather they are simply a part of the history and quality of your work.
I took a class in fifth grade, and our teacher taught us, I think it's a Japanese art technique. It's what you see in pottery where your work blemishes and mistakes are kept in the art. When the ceramics break they rebuild them, lacing gold in the cracks and it strengthens it. And that's a spiritual healing for the art piece. That's just like if you make a mistake with a pen, just live with it. What's the big deal? Sure, a little blemish, but you could turn it into a doodle or whatever.
As Tim describes this art form that leaves blemishes in the work, his soft and thoughtful demeanor makes you feel completely Ok with mistakes. He has a way of talking to you that removes the pressure and stress of being perfect. It is an open door to ideas and thoughts.
The next question I asked Tim was how he gets motivated to code, and his answer launches us into a wonderful direction towards uncertainty and how many things are imperfect, but that is Ok and in fact normal and good.
If it's something where I’m starting from a high point of uncertainty, and I don't think TDD is going to be the right thing yet, I think about it. When I bike to the office a couple of days a week, I'm just telling my subconscious to chew on things and come to me with ideas. Often I’ll just go to people and find someone by the coffee machine, and just instigate a conversation to see “Hey I'm thinking about this thing. I see this problem. Do you see that problem, too?” And then just check to see how all of that thing is understood, and what ideas might exist out there.
But if I feel like I have an idea in mind, I’ll put on maybe Daft Punk, David Bowie, or Brian Eno, or something like that and just set up to run some unit tests. And it's like “Okay, can I like poke and prod the way I want to and get it to a good point?” Okay, great, but that's like few and far between these days. I manage one team directly, and 2 teams indirectly, so I don't always have a lot of time for coding. But when I do it’s: set up everything just right, and then run the unit test as quickly as you can. Now, quick is very good, but not as quick as Gary Bernhardt would want!
The quip about Gary and quick tests is yet another peek at the idea that imperfection is Ok, and so long as you’re staying directionally correct, iterating towards perfect, you’ll eventually get to the best outcomes.
We began talking about writing code and the conversation, then turned to how teams go about measuring the work that is coming, and how people express the amount of work they feel it is, or how complex it could be. Tim began describing his opinions on this.
Well, I mean, I think we fool ourselves a lot. We fool ourselves a lot by saying we know things, but in reality, when you are sitting down to build something, you're not building something the same way you did last week. And if you're rebuilding something you have to rediscover how that thing works, you're never exactly doing the same task twice, and if you are, well, you should probably automate it and that automation is itself a different work than doing the work by hand, so that has uncertainty in it too.
And admitting you don't know things is very hard, to be vulnerable, because often we believe: “I’m paid a lot as a software engineer to know stuff, that's my job” and once you realize how much you don't know it's like you're looking into the void. I think it was Friedrich Nietzsche who said you're looking into a void, the void looks back into you. It's really hard to be comfortable with that and just be like all around me, all I see are question marks and risks, and I’m not even sure how to quantify these and how to go to sleep at night or how to show up not shaking the next day from fear.
A scary description of uncertainty, but Tim closed out the topic with a clever way to bring Wabi-sabi into the certainty problem, and how it allows the team to grow a shared understanding of the product faster. If you go into a user story, and one person is very uncertain, but another is really certain, you pair those folks up, and you distribute certainty. And then the general certainty level rises with the entire team and it's not stuck with one person or a few. The joinery of people, with varying certainty levels, increases the overall strength of the team. It's a very interesting intangible that really becomes a measurable thing. As long as you are really mindful, that is what we're trying to measure. “As long as people are willing to pair up!” Tim adds. He reminds me we are still humans and that sometimes pairing up with someone else is still quite a complicated thing to ask, which compounds the complexity.
Letting people fail
While answering the question, “who is or was your favorite coach?” Tim told me a story from his career that shaped how he feels about failure. It involved a revelation that failure is usually not due to any one person, but rather it is contextual and sometimes systemic, and learning this made Tim rethink many things about leadership.
So I had maybe my biggest failure at Pivotal. I had a lot of failures earlier in my career, like I was definitely fired from a startup once. I had a lot of days where I had no idea how to do anything, and no idea how to advance, but I had one day that was the lowest possible day while I was working on a project at Pivotal. We were building an iOS SDK for a company that was purchased by IBM. They were sending people from Washington and Oregon to San Francisco to work with me and another person on this SDK. And I’m learning Objective-C, like in real time trying to figure out, “How do I build this framework?” And so the client engineer I was pair programming with, he was a really difficult type. He was always wearing this C++ hat, and often reminded us that he was a regular contributor to Clang and LLVM–he was a real serious guy, and he's quizzing me on various things about Objective-C that I just don't know because I’m not there yet, and I’m trying to help guide them to building these things. But they're so against the process and so distrusting of me and the rest of the company that it's just basically going downhill to the point where their stakeholder was shouting at my stakeholder. I was like Wow! That was a real moment. What could I have done better there?
At some point later that day, my manager, Matt Parker, took me out for lunch and the first words I remember him saying were the most meaningful. It was just: “This is not your fault, like you made a mistake. You didn't have all the knowledge here, but that's not your fault. That was a management fault for staffing you on this and we're gonna make it better.” That stuck with me for a really long time, because you have to give people a chance to fail, and then let them know that sometimes they fail and that's not entirely on them. And that really touched me, this amazingly human thing that Matt Parker did. But yeah, that was the darkest day followed by someone telling me, “Hey it’s cool. Don't worry about it.”
Tim then went on to describe how we can help people by simply reframing failure in a way to relieve them of the pressure, and allow them to open up to what is really an opportunity to learn and grow. He said allowing this gives people an opportunity to open up and not lock themselves out of the growth, because it’s a chance for promotion-focus and not protection-focus.
If someone can sort of relieve you of that framing, how valuable it is! Because when people give me that opportunity, I can absorb the whole experience deeper, but until then I’m locking myself out. I'm saying that it is just an abject failure, and for whatever reason, I should avoid it. But when somebody frees me from that framing, then it's like “Well, what exactly was that? How did we get to that situation?”
We often carry this idea that we can't get code to work and somehow that's a failure. And you get sort of wrapped around the axle with that framing instead of seeing it as a system. This unit test is inside of a system. So what about the system that could be making this failure? It's not that I’m incapable of understanding how to make this work, it could be something else. It could be an entirely external force that I'm not aware of at the moment, and it's preventing me from getting to my solution. And so, if I reframe it, then it is not a failure. It's very tricky though, because you have to be okay with having failures. Some failures are hard to accept.
Tim added a leadership quality that sometimes people leave off, which is while you help reframe people through tough times, you also have to be careful how you do that.
Okay, now, how do you get this thing back on track without hurting that person who you're trying to trust, and it's especially hard when you're a manager because not only are you trying to set people up for success but you're also responsible for delivering an outcome. We don't often think about that impact, if you are responsible for delivery as well as individuals, and those are very conflicting on occasion.
Sphere of influence
Tim and I then began talking about how developers make the choice between being an individual contributor or possibly going into management. I asked him what his advice would be to new folks in the industry, and he gave an exceptional way to think about this, and it had to do with the influence developers want to have in their careers.
I would say let's start with how they're similar, and we'll talk about how they're different. I would start by saying they're similar in that success in either of those over time looks like influencing more and more people or having a larger sphere of influence. When you're starting as a developer, your sphere of influence is the function, or the module, you've been tasked with. Writing and doing it as well as you can, then maybe that grows to the size of the entire application or the size of an entire framework. Eventually, if you want to be a principal or staff engineer, you need to influence multiple, dozens or hundreds of engineers, and that is technical because you have to put in place solutions that are maybe fully working code. You’re working for tens or hundreds of people and need them to go along with you. You need your peers’ buy-in and you need their acceptance, otherwise they won’t follow your leadership. And the same is true of management. Eventually, you’re managing one person or a small handful of people in a small team and trying to help give them guidance on how to do their job. It’s getting more and more people focused on doing the right thing at the right time.
Tim finishes by saying: “Your growth is in your ability to influence more and more people.”
Tim speaks about building code in a way that feels as though you’re being guided by external forces. And on the face of it, you could giggle and think that sounds ridiculous. But the deeper you accept this idea, the more you recognize how completely true it is. Everything we do depends on some form of feedback, whether its unit tests, market fit, or leading a group of people. Everything has a feedback loop.
… the feedback loop is another tool for clarity…
The feedback loop is not simply the iteration of code along the path to passing tests. It’s also the most meaningful mechanism that we have to find clarity in our work, and to assure success. It’s a process in which imperfection is required in order for it to be successful. You must fail sometimes in order to get feedback.
And just as in Wabi-sabi, the feedback loop is visible. It’s the outcomes from the code or the team. You should be able to see these improvements, so that the art is represented to its fullest. Blemishes should be enhanced and a core element to the strength of the product.
I think the hardest thing is, if someone has never had a faster feedback loop, they've always had tests like this, then they're just complacent. If that feedback loop is really, really slow, then that means your next step is slower. Our feedback loop should never be rapid enough.
You cannot understand true happiness if you don't understand true suffering, and the opposite is true. So if you've only ever known slow feedback loops, then you don't know what better looks like you might suspect it could be better, but you don't truly know and you're not hungry for it. That is one of those things that I often find very hard to coach. It's interesting how most folks find it hard to believe it could be better.
Tim went on to describe the difference between these fast feedback loops for the building of code, and the slow feedback loops related to building teams and people.
My feedback loop is in the order of 13 to 26 months right now. So if I make a decision today, I don't expect to know if that was a good decision for weeks, and I don't know how to speed that up because I think I’m dependent on a bunch of other smaller feedback loops, who themselves are generally probably pretty rapid. But it takes a while to measure the things you want to measure, like, for example, if I pick someone to lead an initiative, knowing that was the right person at the right moment in time, especially if it's really high stakes.
As Tim was describing feedback loops, it was very clear to me that while he was using words like fast, rapid, and immediate, he very emphatically understands that is all balanced with patience. Which also lends itself to the transience of Wabi-sabi in that, while you apply your best work at the moment, you never know when new feedback will come in the form of a broken art piece, that will require new joinery of gold lace, leaving the art in a constant state of a feedback loop, visible for everyone to appreciate the growth and strength of the work.
Abstraction is an act of violence
Close to the end of our conversation, Tim gave me a very thought provoking idea about how we generalize and the impact that abstractions have over people, and why it’s a quite possibly a terrible thing.
This is way off topic, but I’ll give you one of the lines that I discovered recently that I love, which is that abstraction is an act of violence. I'll give you a good example like “all female software engineers are bad”. Clearly, this is not correct. There are some who are good, there are some who are bad, there's some more in between. These different people have different skill sets, but it's not true that all female software engineers are bad. If you do that, you're abstracting over all the people and to do that is an act of violence. You're basically treating all these people the same. You deny them their individual humanity and saying “all of you are in the same group.”
I think about that a lot, because a lot of the things we do in software are about abstraction and the more you want to derive value from software, the more abstraction you have to do. And it's really hard for me to try to correlate that with the fact that abstraction is violence. And that's why the connotation of an experiment is bad with management because you cannot interchangeably use folks as controls because that's ignoring humanity and empathy. We kind of struggle with what is the right balance between abstracting enough such that you can actually achieve your outcomes versus doing active harm.
Tim was optimistic about this idea though, as he described how this could be a form of deeper empathy for people we work with. If we avoid abstracting people as resources for a team or project, we can then allow for everyone to experience the work according to who they are at the moment. He shared a few examples of people going through rough times in their life and said: “It's like yeah, you just have to accept that person is not going to do good work for a while and say it's cool. I understand. We’ll get through it.”
This is very much inline with the art of Kintsugi. I heard Tim describing this idea that treating people the same was an act of violence and I couldn’t help but think that without Kintsugi, you’d inevitably just throw away broken pieces, because each break is unique, and they wouldn’t fit the abstracted patterns available to fix them. And you would be throwing away precious art that has the potential to be improved and enhanced with gold joinery that gives the piece even more character and strength.
Book of truth
To answer the question, “who would you call if you could call anyone back in time?” Tim gave me yet another glimpse into the idea that nothing is complete and imperfections are a part of the process, but also in this idea it is important to save and record truths that we learn, and not blindly move past them, for good, and for bad.
After a good “dad joke” about the distance of the phone call, Tim said he would call Richard Feynman, and he would want him to share jokes, but also in a timely way, to keep telling the truth.
Time travel phone calls are very, very long distances, I don't know. I don't know. Maybe Richard Feynman, he was a funny guy. I think I’d ask him if he knows any good jokes. He’s a really funny guy, just really immensely clever. There's a subreddit about “explain it to me like I’m 5,” and I think he was the one who coined the phrase that if you don't understand something well enough to explain it to someone who is 5 years old, you don't really understand it at all. I think it was he who did the report for the [NASA] Challenger explosion. I would tell him to keep telling us the truth. The American people are gonna look to you as an expert, keep telling us the truth. People need to hear it. Even if it hurts, keep telling us the truth.
As we closed out our session, Tim shared with me that he takes notes and keeps them in his “little book of truth”. It’s an idea similar to a “WTF book” that Tim’s friend Nat Bennett uses to help acclimate to new teams or products. In both uses, it’s a way to avoid getting stuck in the present and move forward.
This is your book of truth you carry with you everywhere. While you're working for a period of time, just fill it up with all of your good vibes.
This little book of truth cemented the idea for me that as we consider all the things we are proud of, or have learned, we need to document them for ourselves. We need a visible form of all the gold joinery we’ve collected that improves our daily experiences. Just so that every once in a while we can look back on it and recognize the beauty of transience and impermanence that appears in our lives.
I had a wonderful time with Tim and it’s very clear he has philosophies and values that hold people as unique and valuable in their own way. He believes it is critical we respect those differences between us, but also find ways to make them come together in order to strengthen the final outcome. Along the way keep visible all the lessons and growth — because that is what makes the product strong and beautiful. Thanks Tim!
This is the third in a series of profiles in software. If you enjoyed this subscribe to continue getting the series. I’ll be writing profiles of industry leaders and interesting people from all areas of tech every month.