# Wabi Sabi: Nothing You Are Building Is Ever Finished
> Beth Kempton's Wabi Sabi for software teams: learning, careers and code are never finished, so stop measuring yourself against everyone else's snapshot.

*13 November 2026* · Jamie Taylor


This post is part of an ongoing series on the books that I have read as part of my continual professional development (CPD). All of my CPD posts are available at the following link: [Continual Professional Development](/tags/continual-professional-development/)


[Last week's post](/blog/the-calendar-that-reached-the-big-bang/) was about a calendar that reached back to the beginning of time, on a device that still could not make a phone call. The engineers who built it were not careless. They kept building for requirements that might one day turn up, because nobody was willing to tell them that the thing in front of them was finished. You cannot build for every future you can imagine, and trying to is how a talented team ends up spending years on a single, exhausted attempt.

I want to turn that idea around this week, because I think most of us apply it to ourselves far less kindly than we apply it to code. We talk about skills as though there is a complete set to acquire, and about careers as though there is a correct shape to have reached by a certain point. Then we look around the room, find someone who seems further along, and measure ourselves against them. If there is no finished version of a piece of software, is there a finished version of a developer to measure yourself against?

Beth Kempton's [Wabi Sabi: Japanese Wisdom for a Perfectly Imperfect Life](https://app.thestorygraph.com/books/6e56a04f-26c3-424e-9d8f-806f1a9b8afc) says there is not. [Wabi sabi](https://en.wikipedia.org/wiki/Wabi-sabi) is a Japanese way of finding beauty in imperfection and impermanence, and Kempton's book applies it to the way we live and work. It earned a short section in [my 2023 reading round-up](/blog/continual-professional-development/2023/), where I leaned on its lessons about slowing down and avoiding burnout. I have written about perfectionism more directly since, through Brené Brown's [Daring Greatly](/blog/continual-professional-development/into-the-arena-lessons-for-tech-leaders-from-daring-greatly/#perfection-is-the-enemy-of-done), so this post leaves that argument alone. It is about the other half: what happens to us, and to the people we lead, when we forget that nothing we are building is ever finished, ourselves included.

## There Is No 'Done' With Learning


Software teams have a precise word for finished, and they argue about its definition more than most would like to admit. A ticket is done when it is merged, or when it is deployed, or when it has survived a week in production without anybody noticing it. What nobody seriously believes is that the product is done. A release is a snapshot of the code at the moment we agreed to stop changing it for a while, and the next change is already sitting somewhere on the backlog.

Kempton applies the same honesty to learning.

> There is no 'done', 'complete', or 'perfect' with learning. There is just learning.
>
> — Beth Kempton, [Wabi Sabi: Japanese Wisdom for a Perfectly Imperfect Life](https://app.thestorygraph.com/books/6e56a04f-26c3-424e-9d8f-806f1a9b8afc)


That is an uncomfortable sentence for developers, because so much of our industry is organised around the idea of arrival. Certifications have pass marks. Job adverts ask for a number of years with a framework, as though skill accrues like interest. Somewhere along the way many of us pick up the belief that there is a point at which a senior developer simply knows things, and that until we reach it we are pretending.

The developers who believe they have arrived are the ones who stop learning, and I have written before about [what happens when that belief spreads through a team](/blog/when-your-team-thinks-theyre-done-learning/). Frameworks and platforms move on, and the tools we write code with are changing faster now than at any other point in my career. A skill set is a release, too. It was accurate on the day you shipped it.

## A Career You Construct as You Go


Careers get the same treatment. Progression frameworks draw a ladder from junior to principal, with neat boxes describing what each rung should know, and it is very easy to read a ladder as a timetable. People at the start of their careers feel this most, comparing notes with the friends they studied alongside and concluding that whoever was promoted first has found the correct route.

> There is no single perfect career path. There is only the one that we are constructing as we go.
>
> — Beth Kempton, [Wabi Sabi: Japanese Wisdom for a Perfectly Imperfect Life](https://app.thestorygraph.com/books/6e56a04f-26c3-424e-9d8f-806f1a9b8afc)


Close to twenty years in, I could not have drawn my own route in advance, and I have stopped expecting anyone else's to look like a ladder. A path only looks planned from the far end of it.

## With the Fall of a Single Leaf


One of the Japanese proverbs Kempton includes explains why none of this can ever be finished.

> The Japanese expression 一葉落ちて天下の秋を知る (_ichiyō ochite tenka no aki o shiru_), tells us that 'With the fall of a single leaf we know that autumn is here.' As a proverb, it is used in the context of recognising imminent change.
>
> — Beth Kempton, [Wabi Sabi: Japanese Wisdom for a Perfectly Imperfect Life](https://app.thestorygraph.com/books/6e56a04f-26c3-424e-9d8f-806f1a9b8afc)


In software the leaves are small and easy to walk past: a deprecation warning that scrolls by in the build output for months, or a library the team depends on that quietly stops getting releases. Each one tells you the season has already turned. A developer who thinks of their skills as finished tends to treat these as noise, because noticing them means admitting there is more to learn. Someone who expects to be unfinished notices them early, while there is still time to prepare. Kari Leibowitz makes a related point about [seasons you did not choose](/blog/continual-professional-development/how-to-winter-what-dark-seasons-say-about-difficult-quarters/#seasons-you-did-not-choose) in *How to Winter*; change arrives whether or not we are ready for it, and the only choice is how we meet it.

## The Pond Keeps Getting Bigger


This is the passage I return to most, because it explains something that confused me for years.

> The better we get at something the more we widen our field of vision. We move from a puddle to a pond, from pond to sea. The ideal is always changing, and as long as we use that as motivation to do more quality, heart-and-soul work, that's fine. But when it becomes an exercise in comparison it's a dangerous place to be.
>
> — Beth Kempton, [Wabi Sabi: Japanese Wisdom for a Perfectly Imperfect Life](https://app.thestorygraph.com/books/6e56a04f-26c3-424e-9d8f-806f1a9b8afc)


Early in my career I spent a lot of time debugging with a voice in my head asking, "I should know this. Why don't I know this?" It got to the point where I would leave temporary comments in the code while I worked, asking myself why I did not understand whatever was in front of me. I assumed the senior developers around me had no such voice, because they always seemed to find the answer so quickly. I was comparing my puddle with their sea, and it never occurred to me that they could see an even bigger sea from where they were standing.

Scott Hanselman wrote about this from the other side in 2018. He had suggested using a couple of Unicode glyphs to solve a problem, and one of the engineers he was working with asked him, "how do you even know this crap?" His honest answer was that he had not known it: "I didn't actually KNOW that these glyphs existed. I knew only that they SHOULD exist." He goes on to explain where that instinct comes from.

> A new developer doesn't have this intuition - this sense of technical smell - yet. How is technical gut and intuition and smell developed? Certainly by doing, by osmosis, by time, by sleeping, and waking, and doing it again. I think it's exposure. It's exposure to a diverse set of technical problems that all build on a solid base of fundamentals.
>
> — Scott Hanselman, [How do you even know this crap?](https://www.hanselman.com/blog/how-do-you-even-know-this-crap)


That is what I wish I had understood while I was writing those comments. The senior developers were not drawing on a finished store of knowledge; they were drawing on exposure, and exposure only comes from time spent not knowing things. Kempton's warning is that the moving ideal works as motivation and turns dangerous as comparison, and I think that is where much of the impostor syndrome in our industry comes from. I have seen it at every level, from people in their first job to very senior engineers, and it is almost always the same mistake: measuring our own work in progress against somebody else's snapshot.

In [an earlier post on impostor syndrome](/blog/on-impostor-syndrome/) I argued that some of that doubt is useful, because it keeps you curious and asking questions. The comparison is where it stops being useful.

## Lack or Inspiration


> There will always be some people who know more, have done more or have more experience or knowledge than us in a particular field at a particular moment in time. We can choose to look at this as a reflection of lack in ourselves, or an opportunity for inspiration from them.
>
> — Beth Kempton, [Wabi Sabi: Japanese Wisdom for a Perfectly Imperfect Life](https://app.thestorygraph.com/books/6e56a04f-26c3-424e-9d8f-806f1a9b8afc)


There was a time when I very nearly chose the first of those. I had convinced myself that I was on the wrong team, surrounded by people whose skills were so far above mine that I would never catch up, and I was close to handing in my notice. I mentioned it to a colleague, who listened and then said something to the effect of: if you're not happy here, that's your decision, but come with me first.

They arranged for the team to meet us in one of the conference rooms, and we walked in after everyone was already seated. What followed was, in words to the effect of what my colleague said, that the team had let me down. I was struggling. Teams exist because everyone needs to pitch in, and they had failed me by not spotting it and not offering help. That stopped today.

Standing at the head of that room while someone told everyone I had been comparing myself with how I was feeling was a little embarrassing. I recognise it now as what Brené Brown, in [Dare to Lead](/blog/continual-professional-development/leading-with-heart-and-mind-lessons-from-dare-to-lead-for-the-modern-workplace/), calls rumbling with vulnerability. I did not hand in my notice.

That colleague is the reason I look for the same signs now, both in junior developers on client teams and in the T-Level students I work with. Comparing yourself with your peers at the start of a career is close to unavoidable, because everyone around you is further along at something. What a leader can influence is which way the comparison points.

I was lucky to have the other kind of example as well. A senior developer I worked with taught me that I could not possibly know it all, and that not knowing it all was not a failing. I have modelled a lot of my own behaviour on him. He knew far more than I did, and he made that feel like an opportunity for inspiration rather than a reflection of lack.

## Nobody Is Waiting for You to Fail


He was always the first person in a meeting to raise his hand and ask the "silly" question: the one everyone else wanted answered and nobody would ask, in case it revealed that they did not understand what was being discussed.

> We have to stop telling ourselves that everyone is watching, waiting for us to fail. They really aren't.
>
> — Beth Kempton, [Wabi Sabi: Japanese Wisdom for a Perfectly Imperfect Life](https://app.thestorygraph.com/books/6e56a04f-26c3-424e-9d8f-806f1a9b8afc)


What he understood was that the room is not watching you nearly as closely as you fear; most of the people in it are busy worrying about their own gaps. When someone senior asks the obvious question, everyone else gets permission to stop pretending. I try to do the same now. Asking a basic question costs a few seconds of looking less clever than you would like, and a room full of people nodding along to something nobody understands costs a great deal more.

## A Lens of Grace


Of course, if nothing we build is finished, some of it will break in front of other people.

> Our perception of our problems does not just depend on how we frame them, but also the lens through which we view them. We can look through a lens of judgement or a lens of grace, and that determines how much of an emotional toll we allow the 'failure' to take.
>
> — Beth Kempton, [Wabi Sabi: Japanese Wisdom for a Perfectly Imperfect Life](https://app.thestorygraph.com/books/6e56a04f-26c3-424e-9d8f-806f1a9b8afc)


I saw that choice made in real time at a previous client. One of their senior developers was famous within the team for saying, in stand-ups and retrospectives, that they were just that good: they did not get impostor syndrome, and they never needed to learn anything new. Amy C. Edmondson warns about exactly that attitude in *Right Kind of Wrong*, where [she describes overconfidence as a precursor to failure](/blog/continual-professional-development/embracing-failure-a-key-to-success-in-the-modern-workplace/#the-danger-of-overconfidence-and-the-power-of-responsibility). The "I'm just that good" developer is the mirror image of the one leaving anxious comments in their code, and just as stuck, because neither of them can learn from the people around them.

Then that developer had to give a live demo, with management and the client's biggest customer in the room, and hit a bug they could not understand or explain in the moment. After all those stand-ups, there was a moment where schadenfreude could easily have taken hold of that room.

Instead, I persuaded several of the developers present to start debugging it with them, live, and we raised a ticket there and then in front of the customer. The developer found out, at the moment they most needed it, that their team had their back. Management watched a team help one another under pressure, which is a very hard thing to fake. And the customer came away with evidence that they were working with the right team. A lens of judgement would have cost that client far more than the bug did.

The plate at the top of this post was mended using kintsugi, the Japanese technique of repairing broken ceramics with lacquer and powdered gold. The repair is not hidden; the gold traces the breaks, so they become part of the object's history instead of something to disguise. That is what happened in the room that day. The bug was fixed in the open, in front of the people most likely to judge it, and the team was better regarded for it.

The same lens is available when the broken demo is your own, and it is usually harder to reach for.

## It Is What It Is


In 2019 I interviewed Richard Campbell for the show that is now The Modern .NET Show, and part way through he described a principle he leans on heavily.

> I lean heavily on this concept called ontological humility, which is: don't presume that the way you're thinking is the only way or the right way of thinking, and that new people who are going to look at your code in the future are going to think differently. If you can help them to understand what you've done, and if they have the humility to acknowledge that you did the best you could with the skills and knowledge you had at the time, knowing that later on there will always be new knowledge and you'll perceive things differently, then we respect the code that we wrote before and we sustain it, we find ways to maintain it.
>
> — Richard Campbell, [The .NET Core Podcast, Episode 18](https://dotnetcore.show/episode-18-the-history-of-net-with-richard-campbell/)


Campbell was talking about code, and about resisting the urge to rewrite whatever the previous team left behind. It applies just as well to the earlier versions of ourselves: the developer leaving anxious comments while debugging, or the one about to hand in their notice. They did the best they could with the skills and knowledge they had at the time. Later there was more to know, and there always will be.

> Wabi sabi teaches us to accept that the past was then, and it was what it was. This is now, and it is what it is. Your life is happening right here, and every day is the beginning of the rest of it.
>
> — Beth Kempton, [Wabi Sabi: Japanese Wisdom for a Perfectly Imperfect Life](https://app.thestorygraph.com/books/6e56a04f-26c3-424e-9d8f-806f1a9b8afc)


The software you are working on will change again next week, and so will you. Neither of you was ever going to be finished, and that is what makes both of you worth the work.