The Commonplace blog has been writing a lot on tacit knowledge recently. As someone who’s been programming for a long time (8ish years), these articles resonated deeply. I won’t go into too much detail what tacit knowledge is about, since the above posts do such a good job with it. If you’re not familiar, check them out.

Explicit knowledge vs tacit knowledge

Essentially, explicit knowledge is that which can be transferred verbally. For example, I could tell someone the method name for pushing to an array in JavaScript, what version of Python print went from a keyword to a function, and the range of HTTP status codes that represent success. Maybe they’d need to do some spaced repetition learning or something, but they can just memorize these bits.

Tacit knowledge is resistant to this type of learning. For example, how would you transfer the ability to debug a complex program, or how to determine when to abstract, or how to evaluate a new technology? You might be able to come up with some heuristics, but to reach your level they’d need the same experiences. They’d need to struggle with debugging programs for roughly as long as you have.

Monads

This is the part where I trick you into reading my monads tutorial, which will be the only monad tutorial on the internet to successfully explain monads. The thing about monads is…

Just kidding. I think monad tutorials are an excellent case in point. The monad tutorial pandemic went something like this. There are 47 monad tutorials online. Bob reads all of them. He’s reading about how monads are burritos, how they’re just laws, how they’re adjectives not nouns, how they’re just monoids in the category of endofunctors. But at the end of the day, Bob sits down at his computer and can’t program with monads any better than he could before reading about burritos and endofunctors. Bob charges ahead anyways, and suddenly finds that he understands monads! He must share his discovery with the world. Now there are 48 monad tutorials.

The problem revealed by the (ongoing) deluge of monad tutorials, is that working with monads is tacit knowledge, and tacit knowledge (by definition) is resistant to direct knowledge transfer, like blog posts and videos.

The monad tutorial problem, generalized

Using monads is far from the only thing in programming that is more implicit than explicit. My explicit knowledge is very very little of what makes me a good programmer. If tomorrow I forgot every HTTP status code and all the Python standard library I know (embarrassingly little, and I’ve used it at three jobs), I’d be barely affected. All of that is a search away. But if you somehow took away the patterns engraved in my brain for debugging, or the gut feeling for whether a problem lies in this module or that module, or how to structure a program, I think I’d just quit. Because I can’t just search for that stuff, I’d need another 8 years of struggle to get that back.

I think about this kind of stuff for a lot of the programming material I see online. A blog post will espouse the author’s thoughts on ex. premature optimization, or abstraction. Unfortunately, knowing when to optimize and when to abstract are hard-earned implicit skills. You probably won’t be able to explain how to do them well in a blog post any better than you’ll be able to explain how to swing a tennis racquet.

I’m not saying all programming material is useless. I’ve benefited a ton from programming blogs/videos. Most of the time, the value comes from being pointed in a direction. For example, years ago I read a post on how a company set up mutation testing, I read through it all and somewhere in my brain there was a small note: “hey you should check out mutation testing”. I checked it out later and it was cool. Was I any better at it because I had read through that whole post? Nope, but it got me to check it out.

In the vein of useful programming material, there are a ton of blog posts that solve a specific problem, and these have been invaluable. I don’t know how I’d get through the day without posts like “How to Set Up letsencrypt on Kubernetes” or “Minimize Haskell Image Sizes With Docker Multistage Builds”. These easily-transferable bits can save hours.

The point

The point here is different for different audiences.

For beginner programmers, try to recognize when what you’re learning is implicit knowledge. If you’re learning something fuzzy like how to best structure a program, or when to use OOP vs FP, or how to scrape websites, you probably won’t benefit too much from reading about it. Maybe read a small amount of high-level stuff. To analogize programming to tennis, read enough to know that you should hold the racquet with one hand and that you need to get the ball over the net, but then go hit some forehands.

For expert programmers, I think it’s useful to know when trying to convey your knowledge is going to be futile. For example, I consider myself very good at determining when I can hack something together quickly and when I need to take things slow. I’ll never write a post on how to make that distinction though. If I got that skill erased from my brain, I wouldn’t be able to go back to my post and re-learn it from some post-hoc heuristics. We’ve learned from trying and failing to build expert systems that that’s just not how tacit knowledge works.