Week 22, 2025 - Forests and Deserts

I’m sitting in the Hungarian Railway Museum’s amazing park, under the shadow of buckeye trees, in the middle of a chirping concert from at least a dozen different birds. Halftime of the 2-day Craft Conference, I arrived a bit early to be able to finish this newsletter on its usual schedule.

The first day of the Craft was great, as usual. I wrote about this weird mixture of a tech conference and music festival last year, and fortunately, there hasn’t been much that has changed. The only significant difference is that, being the host of two fireside chats, I have some obligations that make me miss important talks.

But it’s a good swap, I got to chat with amazing people! Yesterday, we had a panel about AI Security, with founders of two interesting companies protecting the user-facing and infrastructure side of AI implementations, discussing attack vectors, the differences between traditional and AI-age IT Security, Shadow AI, and the legal aspects of it all. And today, an hour after I write this, I’ll share a stage with Charity Majors, Bruno Passos, and Ferenc Kárász to discuss Engineering Efficiency. What an honour!

The keynote talk from Kent Beck explained his Desert and Forest concept, two fundamentally different environments for building software. While the concept is not radically new — for example, Theory X and Y explains roughly the same idea — a genuine a-ha moment for me was that, unlike a lot of things in management, this is not a scale, not a gradient where most organizations fall somewhere in between. Sure, there are Desert companies where a few small oases of Forest exist, but if you think about it, that's not anything in between: that's essentially still a Desert organization. These two are, to borrow the title of the talk, parallel universes. And therefore, communication, goal setting, motivation, team setups, performance management, any approach that's coming from the Desert mindset will spectacularly fail in a Forest — and vice versa.

I had a thought about how this duality relates to wartime / peacetime software development. Is one organizational setup better suited to survive in wartime? What about peacetime? If I plot a 2x2 matrix for internal culture and external circumstances, what kinds of behaviours, expectations, cultures, and organizations will fall into the four boxes? Maybe something to explore deeper another day.

Unrelated to this, the week’s Lead Time Engineering Management challenge was about diagnosing systematic failures and rebuilding trust on all levels after a failed launch. Read the details here if you missed it.

🤔 Articles that made me think

Stuff Will Larson learned at Carta

Will Larson is leaving Carta’s CTO role, and he summarized his learnings in a blog post. A lot of good details there, from engineering strategy through LLM introduction, Staff+ engineer representation, to organizational and other topics. The reason I share this, though, is to remind my readers (and myself, too) of this practice of creating a “things I learned” document after leaving a job, or even just a role within a company. It’s a great way to ensure lessons are not missed, and the exercise can even serve as closure to unresolved conflicts, failures, and stressful events.

Luck, Preparation, Opportunity

I was searching for a source for the Seneca quote “Luck is when preparation meets opportunity” because I wanted to use it to demonstrate the underlying thought about increasing the likelihood of success by preparation, while acknowledging the importance of pure chance, too. (Side note: playing backgammon is a great way to accept the full spectrum of consequences of this concept.)

The article here summarizes the preparation factor well, but I want to add that there are things we can do on the other side of the equation too, and work towards increasing the number of opportunities we have: by intentionally looking out for them, taking more chances, more risks, and in general, getting familiar with being outside of our comfort zones.

📈 Something Cool: Beszel

It’s been a while since I wrote about homelabbing. Nowadays, I have less time to tinker with my small two-box setup, but this tool is perfectly filling a gap I didn’t even know I had, so I couldn’t resist installing it. Beszel, a simple, minimal-setup monitoring tool, nails the depth and visualization aspects I need: Netdata is too much for me, Glances with Homepage is slow and resource-heavy, and the native Proxmox observability tools are not granular enough when most of my services are in Docker. Beszel is simple, intuitive, and gives me immediate answers to questions like Why are my Mac Mini’s fans screaming again?!. Once I’m done with setting up alerts, I’ll remove all the other tools except for Uptime Kuma, and I'm done with observability for a while.

Side note to my Hungarian readers: Yes, I reached out to the author to ask if the name was taken from our language. (Beszel is the third-person singular conjugation of the verb "talk".) In short, yes and no: the author got inspired by the book The City & the City, in which events take place in a fictional East European city called Besźel.

Now you know.

That’s it for today, get lost in a forest this weekend,

Péter