I've been thinking about how much I favour measurements in time vs. size and how the shift to a chronological perspective allows me to overcome my fear of engaging with large tasks. This week a few things have overlapped in my mind to reinforce this idea.
First, during my summer holidays I've been binge-watching the Escape to Rural France YouTube channel, where Dan Preston is restoring a burnt-out château ruin (the Château de Chaumont). My eldest daughter has long been a fan of various château restoration channels, which is partly why I suspect this series ended up in my YouTube recommendations. "Dad, you'd love this," and she's right. I initially watched one episode, then another, and now I'm hooked. The task he's taken on is enormous, and the hubris and total disregard for practicality is what makes it so engaging.
It's slow, which I love. Each episode is focused on a day of work, which might entail clearing trees, shovelling debris, repairing brickwork, or discovering a beehive in an old bathroom wall. There is no urgency to the pace. The scale is both human and beyond reach: nothing big happens, and yet over time and bit by bit, large transformations occur. In an episode I watched a few days a go, Dan pauses his work laying floor joists to reflect: the key to this work is thinking about everything as a set of small jobs vs. the whole, which would overwhelm.
One of my favourite regular characters on the channel is Nick, the tree surgeon. Dan and Nick spend a lot of time thinking about how to open up and restore the grounds, which have been badly overgrown. Nick even spends one episode removing a massive tree that's grown inside the Château. He also reflects on the need to think in years and decades, planning for the woodland, but recognizes how small actions taken now, in the present, will come to influence the future.
Watching Dan and Nick slowly pick away at massive jobs has been inspiring for me. This past week it motivated me to start work on a project I've wanted to do for a few years. On our property we've been overrun with Spotted Knapweed, an invasive plant from Europe that takes over Ontario grasslands, outcompetes native species, and increases fire risk.
In the past decade these "purple flowers" went from being something we thought were pretty to being the dominant plant in many areas of the property. My youngest daughter has got me thinking more and more about the negative effects on biodiversity that invasive vs. native species have. I've long wanted to do something about it, but every time I've contemplated it, the job has felt impossible. You can control Knapweed with chemicals, but I don't want to go that route. The alternative is to hand-pull it.
The weather here recently has been rainy, and with the rain the soil has been perfect for going to work on the Knapweed. I've spent days carefully removing plant after plant, making sure to get the root. Some plants have been taller than me, while others are just starting to come up. Regardless, they all get pulled.
The task seemed ridiculous at first. And yet, bit by bit and slowly, the patches of Knapweed are giving way. Because I'd always thought about this project as a whole, starting it never made sense: surely there is no way to do this by hand, the job is too big! But by converting the size of the task to a series of steps in time (i.e., "I'll do this patch today, that patch tomorrow, ..."), I've been able to make an impact.
The consequence of approaching problems from the perspective of time is that it becomes possible to begin. I'm not worrying about completing the project, which in the case of the Knapweed will likely never be done; rather, I'm deciding to participate today. The problem is no longer measured in square meters but hours and days.
As I've been pulling Knapweed, I've also come to realize that this is my preferred approach to software as well. I spend most of my time working on software vs. natural ecosystems, and in that work I've long known that many small fixes are invariably better than one massive effort. I learned this first when working on Mozilla, where the scale of the code was inhuman (no one knew or understood it all, least of all me), but everything was accomplished through the repeated contributions of individuals.
I've since been reminded of this in my work with Taras on chatcraft.org. I would never have started this project on my own because it would have looked too big. Taras coming to me with something already started made it feel possible–I'm much more comfortable fixing bugs and improving code vs. writing it from zero. That's the risk of "product thinking," focusing on applications vs. their code, where the former requires everything to exist, but the latter can be useful at various stages. The reality is that by picking away at something, editing and refactoring what was already there, and slowly fixing and cleaning-up the code, you're able to make something really amazing. Especially if you don't get fixated on being "finished" and instead learn to embrace the half-finished nature of the work, it's possible to go very far.
I'm generally not good at being on vacation, but by allowing myself to exist at the intersection of a French château, Spotted Knapweed, and chatcraft.org, I'm enjoying the possibilities of existing in time.