A little over a decade ago, I was part of a team introducing new practices to a 200+ person, distributed development team. A lot of people were too quick to understand them. Some participated in stand-up as if it were a one-way status meeting. Others were still creating long-lived branches in Perforce as if they were still using ClearCase. "Stories" was just a new word for the technical tasks they had always assigned. Two people I was working with at the time pointed that everybody would be well served to approach these new practices with "beginner's mind."
While on vacation in Western Ontario Province a few years ago, my wife suggested we visit an amethyst mine. I had distant memories of doing some lapidary work with my dad back in the 1970s, so I picked up enough small stones for tumbling. Over the years, my dad had grown serious enough about the hobby to build out a considerable workshop of tools, slabs and rough. When I told him that I had picked up a few pounds of amethyst, he gave me a spare rotary tumbler. Five weeks later, I had my first batch of polished stones in nearly 40 years.
I was also disappointed. The polished stone looked good but not great. Why did so many have fractures and chips?
I did some research and tumbled some more stones and learned that to get better results I would have to improve the quality of the rough as well as my technique for tumbling.
To improve the rough, I learned to recognize characteristics of amethyst crystals that were more likely to fracture in tumbling, and excluded these. I did a full inspection after every stage of the tumbling process and removed any stones showing signs of damage so that a shard would not float around the barrel and contaminate other stones in the batch.
I had to improve my technique, too. Stones take quite a pounding in a rotary tumbler. While this action erodes sharp edges off the stones, it also increases the probability of damage. I learned that ceramic media in the barrel can cushion the impact. I realized that the barrels can be difficult to completely clean; even a tiny piece of previous-stage grit can contaminate a batch, so I obtained different barrels for different stages of grit. I also questioned the 7-days-per-each-stage tumbling recipe: what's so special about a week? I sampled stone in the tumblers once per day, comparing it to stone that had been in for a full week, and found I could reduce the amount of time spent in every stage.
Eventually, my dad gave me a lapidary arbor so I could grind the rough into shapes that would tumble more successfully. Later, he gave me a lapidary saw so I could cut fractured stones, allowing me to harvest more from the rough: instead of grinding away one half to save another, I could cut a stone along an obvious fault line and shape each part into a stone that was more likely to tumble successfully.
I quickly realized that the saw and arbor would let me do more than prepare stones for less bad tumbling outcomes. After a bit of research led me to cerium oxide belts and expanding drums, I figured out how I could hand-shape stones from rough to polish without using the tumbler. Hand shaping a stone is time consuming, but far less damaging than tumbling. There is risk: what appears to be innocuous sanding can expose a deep void, and careless handling on the arbor can result in a shattered stone. Still, when I have a very special rough stone, I can shape and finish it by hand, sanding out imperfections while retaining its unique characteristics.
The lapidary world is not too interested in making unique shapes out of small rough on saws and arbors; it is primarily concerned with creating faceted stones or cabochons (domed shapes in fixed sizes). To be serious about lapidary work, I would have to make one or the other or both. I had the tools for cabs, so over the course of several months, I taught myself how to slab, trim, dome and polish cabochons. I had some jewelry findings from my dad and acquired a few more of my own to set the cabs into as finished jewelry pieces.
It occurred to me that what makes lapidary work so satisfying to me is that I approach it with beginner's mind every day that I get to do it. Every stone I work on, every technique I follow, every tool I use is an experiment and therefore a learning opportunity. Through the simple, frequent act of trying lots of different things I have made hundreds of little adjustments to my workshop, my tools, and my methods. The net result is I am more efficient, more accommodative to failure and mistake, have higher throughput and better product quality today than I did at any point in the past.
And I'm still learning. Every day.
The joy of the lapidary work is not the final product. If it ever became that, it would be a chore, a job, and it would lose its allure. The joy of the lapidary work is the never-ending discovery. Some days I work in the workshop, some days I work on the workshop, but no matter which it is I learn something every day, and every day I take action on what I learn.
In the business of software development, the primary focus is on the product: these features, this timeframe, this cost. When the product disappoints - it costs too much, it takes too long, it isn't reliable, it is difficult to use, it doesn't do what it's supposed to do - the process of how it is made gets as much attention as the product we're trying to make. Those times of focus on the process lead people to investigate things like Agile and Lean and continuous delivery. Sometimes, to people unfamiliar with them, Agile and Lean and continuous delivery appear to be magic.
There is nothing magical about things like Agile and Lean and continuous delivery. The only magic is the (re-)experience of beginner's mind when somebody is first exposed to them. They force us to re-examine the orthodoxy we have long accepted - for reasons we no longer remember - for how we work. They let us break out of the psychic prison that is the modern operating company environment.
Despite containing elements of continuous feedback that drive continuous improvement - build pipelines, retrospectives, experiments - the change to Agile or Lean or continuous delivery does not typically result in a permanent state of beginner's mind. They captivate only for the short period when people care about process: we're broken, we need a fix, this process looks like a fix, let's adopt this process. As important as change may be at the time, product eventually triumphs over process, while change fatigue casts a pall over attitudes and budgets alike. Management wants mastery of whatever mechanical processes they've agreed to; they're not interested in perpetual, indefinite refinement.
Dan North has long argued that first and foremost a company should aspire to be a learning organization. A propensity for organizational learning underpins a lot of well established management theory and more recent instantiations of it, things like autonomous work teams, Agile practices, and Lean startup. If the real objective is not to become a learning organization, these will be little more than mechanical acts that serve only to make software development less bad.
There is merit in being less bad. There is value in fleeting moments of joy from reconnecting with our younger, knowledge-acquisitive selves. But change that does not aspire to rewire people permanently to their beginner's mind does nothing more than make a job less of a slog. It is still a job.
It is not a passion.
