Denis Defreyne

Weeknotes 2026 W38: On tacit knowledge

September 14​–​20, 2026

Quick bits

  • After passing the audition, I have now enrolled in drama school. Two weeks until it starts.

    This drama course also likely officially makes me a student again — part-time, but a student nonetheless — and I’ll qualify for discounts.

  • My current six-week drama course finishes coming week, just in time for the aforementioned semester-long course to start. The six weeks went by quickly, but it was helpful to get back into it, and I learned a thing or two in the process.

  • I added a podroll to my web site: the list of podcasts that I regularly listen to.

  • I’ve done a few flat viewings this week, but nothing stood out. Slowly, I am becoming more aware of what exactly I want in a flat. I have grown rather used to my current place, and I’m not moving unless I find something that is a clear upgrade.

  • An IKEA glass spontaneously shattered while it was in the sink. There was no trigger. Now I’m afraid that my other IKEA glasses will spontaneously shatter in the cupboard — or worse, in my hands!

  • I have fixed the hyphenation of “Kee­Pass­XC”. It got hyphenated as “KeeP-ass-XC” on macOS! Adding the appropriate ­ (soft hyphen) fixed that issue. That process is, of course, fully automated in Nanoc.

  • In the process of making ddenv more modular, I fear that ddenv is growing its own distinct package manager. I have no experience building package managers, and I feel like this project is ever so slightly more than what I wanted.

  • I’ve been dealing with AI-generated documentation slop — slopumentation, perchance? — and I loathe it.

  • My phone has started suggesting that “tube” be corrected to “tuberculosis.”

Shower thoughts

  • Even though it is technically true, saying “I have killed less than seven people” makes people upset, somehow.

  • The Jubilee Line is henceforth known as the Jube Tube. I will not be taking questions.

Tacit knowledge

Cedric Chin’s Why Tacit Knowledge is More Important Than Deliberate Practice caught my attention this week. I’ve yet to read through the entire series, but I’ve got some thought already on the topic of tacit knowledge!1

Part 2 of the series (Copying Better: How To Acquire The Tacit Knowledge of Experts) contains this:

More bizarrely, competitors who poached TPS experts away from Toyota were not able to replicate Toyota’s system in their company. It appeared that TPS required an organisational culture to develop alongside the implementation of the system itself.

I am not surprised, and I’ve seen similar situations play out elsewhere.

When I was working at Shopify, there was the GSD (Get Shit Done) framework. In this framework, each project goes through three phases: proposal, prototype, and build. The framework was documented and expected to be used company-wide. My team, however, existed on the periphery of Shopify, working on a non-core product, and the team consisted primarily of people who weren’t otherwise familiar with Shopify’s way of working. As a result, the team followed the letter of the GSD framework, but not the spirit.

There was one particular project where I watched first-hand how the misapplication of this framework ruined a perhaps otherwise good project. When this project left the Proposal phase, I was put on the project to see it through the Prototype phase. My task was to integrate a machine-learning model to create a recommender system — something I was keen on doing, because it is a domain I had some expertise in. However, at the start of the six-week prototyping phase, not only did that machine-learning model turn out to not exist, but the data needed to build that model wasn’t even collected yet. Collecting enough data to begin creating a model would’ve taken so much time that the prototyping couldn’t realistically begin anytime soon.

I raised this as a blocker, and urged my manager to delay the Prototype phase. Alas, because the GSD framework dictated a Prototype phase, I had to implement a prototype no matter the cost. I ended up building the least-shitty alternative option, and a real-world user test revealed that practically nobody used the feature. And so, the project was canceled before being able to move the Build phase.

This was perfectly in line with how I expected the prototype to perform. I made it explicitly clear to my manager that building this prototype was futile. If instead the Prototype phase had been delayed until a reasonable machine-learning model was available, the project might have yielded useful results. Alas, I spent six weeks working on something that I knew would perform abysmally.

What does this have to do with tacit knowledge?

  • All of us (my fellow team members, my manager, and myself) read the specification of the GSD framework. But I know from experience that documents that describe processes cannot properly communicate all aspects of the framework. To use the GSD framework as intended (as opposed to specified), it would’ve been crucial to have an experienced GSD practitioner on board to get the process going correctly. Yet I could not convince my manager that following the GSD framework to the letter would be missing the point.

  • I have experience with machine learning and recommender systems. My master dissertation subject was on recommender systems, which is exactly what this project was about. Yet that wasn’t enough to convince anybody that the alternative prototype would be (as predicted, and evidenced) utterly ineffective. I didn’t have number or charts to use as evidence, and collecting that evidence (effectively doing research) would’ve taken time that I didn’t have. Tacit knowledge, it seems, is useless when constructing an argument.

Sadly, I don’t know what I could have done differently. Perhaps the team was simply too low-trust for any alternative to be effective.

Something related happened later, also at Shopify. When I came back from an extended break, my manager told me that the team was wondering whether to use a monorepo for an upcoming product. I instinctively responded with a confident “yes, let’s use a monorepo!” — not realising that an entire working group had been set up to tackle this very question, with about a dozen team members working full-time towards an answer, for more than a week.

My split-second reaction unintentionally annoyed my manager, and I wasn’t allowed to be part of this working group, despite my extensive experience with the matter. Had I been involved in this question at the start, there would, I believe, not have been a need for such a working group at all.

I have actively maintained repositories that predate the existence of GitHub. I have actively and proficiently used five different version control systems over the course of more than two decades, and worked in countless repositories of all shapes and sizes. In short: I’ve got heaps of experience to draw from.

But I faced the same issue as before: when asked for concrete evidence, I have nothing to produce. I unfortunately don’t have much more than “trust me, I’ve been there.” I could have gone through the research process to collect evidence, but that would’ve taken significant time, which is exactly what I wanted to avoid.

On the topic of code repositories: I believe that the current standard way of working — pull requests with review before merge — is often not optimal, yet it is so much a standard that the vast majority of developers cannot imagine an alternative to it.

Meanwhile, I have hands-on experience working with an approach of reviewing after merging. I’ve used this approach on a large codebase (approx. 1 million lines of code) delivering high-impact changes for huge customers across multiple continents. Review-after-merge is an entirely valid approach, but unfortunately one that has practically disappeared.

I wish I had concrete documentation of how to work with such a setup, and I wish I had concrete evidence to show that this approach has legitimate benefits.

Again: I have code repositories that predate GitHub. I have been developing and releasing software since before the concept of “pull request” existed. I know that this approach can work, because I’ve been there and seen it work well.

And yet, when I tell developers to consider review-after-merge, I get called out of touch, a contrarian, delusional, and irresponsible.

Then there’s this bit:

You just want to learn how to acquire what is in your more skilled colleague’s head.

That is only part of it. There are two more questions that interest me greatly:

  • How do I help others acquire the skills I have in my head? There are topics around which I’ve built expertise for decades. A large amount of the tacit knowledge is not written down anywhere, and this is the reason why my project to codify my software engineering principles could be worthwhile. I’ve written articles, coached coworkers and students, given presentations, all of which feel useful, but somehow still not enough, and not as effective as I’d like it to be.

  • How do I convincingly communicate with others that I have the necessary (tacit) knowledge? The two examples I gave earlier touch on this very question. The giant challenge here is to not come across as pretentious, and to not fall into an argument-from-authority trap.

    In this industry, I have to prove myself over and over again.2 In practically every job interview, I am tasked with solving basic Ruby code challenges — a practice that, by this point in my career, I find insulting. There is a vast amount of evidence on the internet that I am more than capable as a software engineer; if even evidence of concrete knowledge is not taken into account, then perhaps tacit knowledge has no value at all here.

Perhaps I am more interested in these two questions than in acquiring what is in my more skilled colleagues’ heads.

Have I gone off on a tangent while writing my thoughts on tacit knowledge? Maybe. Probably. But my week­notes are not a medium for ultra-refined thought anyway — preliminary observation and analysis only.

Perhaps all of the writing above on the subject of tacit knowledge is, in part, an attempt at turning that knowledge into something more concrete, even if it’s just sketching things out. It has, in any case, made me realise more than ever that I have a large amount of experience that could benefit from being made explicit.

I’ve got a bunch more thoughts on this topic — and a bunch of reading left to do — but I’ll leave that to a later point in time.

Entertainment

  • Spiritfarer3 is relaxing and remarkably emotional! I’ve had it for a while but never got into playing it.

  • I’ve been playing Freedoom on UZDoom. I’m surprised by how good the free maps are!

Tech links:

  1. I’m not too fond of the term “tacit knowledge,” because it doesn’t properly convey the entire concept. “Innate understanding,” perhaps? “Embodied ability”? ↩︎

  2. People frequently guess my age as roughly ten years below my actual age, which is a little flattering, but also distinctly infuriating because they instinctively assume I can’t really have as much experience as I claim — even to the point of accusing me of lying! ↩︎

  3. Spiritfarer (Thunder Lotus Games, 2021). ↩︎

You can reply to this weeknotes entry by email. I’d love to hear your thoughts!
If you like what I write, stick your email address below and subscribe. I send out my weeknotes every Sunday morning. Alternatively, subscribe to the web feed.
Incoming links: