Chapter 0. Introduction
Chapter 1. Scope
Chapter 2. Mu
Chapter 3. The Middle Way
Chapter 4. Rigourism
Chapter 5. The Ecclesiastes
Chapter 6. Meditation
Chapter 7. Suffering
Chapter 8. Attachment
In this book, I'll be explaining various concepts from spiritual traditions from all over the world in a language that's understandable by professional software engineers. Yeah, that's it, that's the idea.
What you'll do with all that knowledge is literally none of my business, I'm not going to promote any particular “righteous way of living,” I definitely won't be endorsing any particular organisations, and there was a lengthier disclaimer in an early draft, but Claude AI told me to throw it away because it was horrible.
Now, as we've all seen many times, there's a common trope in the books in this genre. It's when the author goes, like, I was in the village of emerald miners, about halfway between Kathmandu and Ulaanbaatar, and that's where I met Saint Haregandjah Ramakrishna, who, after we ingested the Seeds of the Sacred Pumpkin, initiated me to Ancient Secrets, some of which I'll share with you.
I won't be doing any of that either. In fact, I'm a depressingly normal bloke. I live in a middle-class loft near Amsterdam Centraal station, and I work in FinTech. I don't belong to any specific lineages, I didn't undergo any flashy initiation rituals, and my drugs of choice are Cortado and Carmenere.
Oh, and also, my regular psychedelic ritual begins with firing up a Haskell REPL, but let's not get ahead of ourselves.
All I did was I discovered Tao te Ching and the Gospels while in my teens, and then I spent the next twenty years figuring out what do they actually mean, and how to make use of them in my life... Oh, mind you, when I say “twenty years,” I don't mean I spent all that time sitting on my bum in a remote monastery meditating. It was parallel to (and, really, intertwined with) everything else that was happening in my life, like getting my engineering degree, having a modestly successful career, and generally enjoying my 20s and 30s.
That's why on several occasions I've been told it'd be so nice if I could quietly leave the dinner table and never call them again. When a talk about things like inner freedom or unity with the Universe comes from a dirty hippie with metre-long dreadlocks who has been non-stop high for years, that's very convenient to ignore.
Whereas, when it comes from a bloke in a Hilfiger jumper who smells Dior and earns six digits, it sometimes hurts...
Anyway, enough of these introductory courtesies. Let's go to the first chapter, where I'll explain what this book is really about.
To clarify the scope of this text, let me first elaborate on what I don't mean when I'm talking about the spiritual.
First of all, I'm not talking about a purely intellectual pastime when you sit in a comfy armchair and philosophise about the true nature of Buddha, or whatnot. Some 80% or 90% of what I'd call “spirituality” is practice, such as meditation, asanas, prayers, integrating the insights into daily life, and so on.
It's a bit like, imagine climbing a mountain. An instructor can sketch you a route, and warn you about the obstacles, and share some anecdotes from the famous climbers. Which is super-important because without this knowledge, there's a good chance you'd get stuck in a dead end or fall into an abyss. But nobody can teleport you to the summit, and nobody can climb the mountain for you. You'll have to do it yourself. And, if you're writing computer code for a living, this whole mountaineering metaphor might give you an eerie feeling.
I mean, if you had to describe the most cringeworthy technical conversations that you've ever had, what would they be? For me, it would be those where the other side implied that theory is the only thing that really matters, and, once you learn it, practice is trivial. Like, use this framework or apply that pattern or “just make it simple,” and it would automagically make everything better. Of course it will! These ideas were developed by people much smarter than you! How dare you question them with your puny fifteen years of experience in the field?!
In the software engineering field, we don't talk about craft and mastery nearly as much as we should. In part because it's hard and tedious and much less fun than selling or buying the shiniest silver bullet of the month. But it matters, and it matters a whole lot.
Theory is important, but it's not hard-hard. I can teach you how to do the Zazen sitting meditation in fifteen minutes. I can explain the key refactoring techniques in a few hours and walk you through the GoF patterns in two days (if we really go into the details)
And look, you definitely must study all that. Reinventing the whole corpus of engineering (or spiritual) knowledge is a waste of time for a genius, and way too much to ask for the rest of us. But it will only prepare you for the journey, it's not the journey itself.
Heck, I can explain long-distance running to you in one sentence. You put your left foot in front of the right one, then you put your right foot in front of the left, then you repeat it fifteen thousand times. That's it, that's all marathon theory that there's to know.
Then it will take you years to practice either of those to mastery. And that's just how it works.
Second of all, I'm not talking about official religions. Official religions are... They're pretty good. I've been going to churches somewhat regularly at various times in my life, and I met wonderful people there, even though it never really stuck with me.
And yes, I'm confident that most people reading this text identify as atheists, and would be less generous than I, but hear me out. Official religions are a bit like the Django framework or like taking Uncle Bob Martin's commandments at face value. They're useful for certain purposes and in certain circumstances.
If you have no idea how to define the coding guidelines for your team, taking Clean Code verbatim is much, much better than unrestrained freedom of artistic expression. Likewise, if you have no idea how to structure your webapp, Django's default layout will likely do a better job than whatever mess you will code yourself into. Besides that, if you have a department with sixty coders, and you'd rather have a codebase that's “kinda ugly, but in a uniform way,” you can declare that we use “Django way” here, and be done with bikeshedding.
Like Django, like Spring, like Clean Code, like C++, official religions are what you end up with when building a platform that works okayish for a wide population of either coders or churchgoers. So you have to account for huge variance in skill and commitment, and sometimes trade off perfection for consistency and “the least surprise.” You even get a similar “language lawyer” archetype who is a deep expert in features that exist solely to make the whole thing “community-compatible,” and don't hold any inherent value.
So, to make myself clear, I'm neither pro nor against official religions, as well as Django and Spring frameworks, Clean Code, and C++. They're merely solving problems that I personally don't have, thus I have little use for any of these. But I know others who use some of this very successfully, and I'm truly happy about them.
Oh, and, obviously, if anyone claims that official religions hold a monopoly on everything spiritual, I strongly disagree, and on this hill will I die if I must.
Third of all, I'm not talking about tourist destinations when people get together in glampings to chant mantras, do asanas, dance naked under the full moon, eat jackfruit stew, and have a good time... All while this has zero effect on their “normal” life, where they remain the same angry, thankless people with no idea what they're doing with their lives. For me, spiritual practice is an integral part of my daily life, and my daily life is an integral part of my spiritual practice. And this all also applies to my daily job as an engineer. I'm not switching modes between me-the-student-of-Zen and me-the-backend-developer whenever I step into the office elevator. I'm just being me all the time.
When I'm refactoring a legacy piece of code, I'm just juggling methods around. And I'm just taking part in Harmony emerging from Chaos. Without any “not just X but Y” here, as neither of these two sides is inherently more valuable. Or, better to say, there's no meaningful comparison of inherent value here.
When I'm mentoring a junior, I'm practising humility and gratitude. When I'm fixing a flaky CI job, I'm reducing the amount of suffering in this world. And so on, and so on.
I can easily imagine some of the readers going berserk with cynicism about this display of flowery idealism. If you're one of them, ask yourself: what are you trying to protect? Those moments when you sit on your bum and patiently wait until it's 18:00 and you're permitted to stand up and do things you actually like? Oh, okay... Sure, you can have as many of those as you want, fine by me.
In fact, this is where the title of this book comes from. In Zen, there's a proverb that says, “Before enlightenment, chop wood, carry water. After enlightenment, chop wood, carry water.” Or, to rephrase for 21st-century coders who don't do much physical labour: before enlightenment, fix CI, write tests, after enlightenment, fix CI, write tests. It's perfectly common to undergo a profound inner transformation, all while your life looks unchanged from the outside.
Anyway, so the plan for this book is I'm going to introduce ideas from various spiritual traditions, and I will explain how they relate to engineering practice.
We will start with ones which are... Well, they're not so much “simpler,” but they're easier to grasp with less setup. The first one is what Zen Buddhists call “Mu.”
If you're a professional software engineer, it's relatively safe to assume that when you were in your teens, you survived the blunt trauma of having to go to school. Some of us recovered better from it, some worse, and this chapter is especially valuable for the latter.
The way it works in school is you're supposed to know the answers. If you don't know where Timbuktu is located, and you try to weasel your way out by throwing random guesses and reading the cues, you at least have some fighting chances. Whereas, if you don't know where Timbuktu is located, and you honestly admit that, it means you're stupid, and the whole classroom is now laughing at you.
Some eventually recover from this fear of saying “I don't know.” Others carry it well into their twenties and thirties. I've done something like a hundred coding interviews over the years, and I've seen far too many candidates trying to weasel their way out of my favourite puzzles instead of honestly admitting they don't know.
A more subtle belief, but also much more destructive, is that every question fundamentally has a definitive answer. If you yourself don't know it, you're just uninformed - but somebody knows it, or at least there are means to figure it out.
And that's not true.
In Zen Buddhism, there's a concept of “Mu,” which has many different meanings, and the one important for this chapter is when it's used as a fixed form to express that the question is garbage.
Mind you, it's not a “get out of jail free” card that allows you to evade hard questions while also cosplaying a Zen master. It specifically means: I wish I could give you a definitive answer, and I did my best to find it, but it simply doesn't exist, and that's because your question is flawed.
Let me give you an example.
Which language is better, Rust or PHP?
The answer is Mu.
If the question was, given that we want to build such and such systems, and we have these people in our team, and we have this legacy codebase we can repurpose, and so on, and so on, then we can draw a comparison matrix and make an informed choice.
However, when devoid of any context, the question is meaningless. That's why the answer is Mu.
Next time you get dragged into a debate like that, pay attention. People will be smuggling the comparison criteria, simply because there's no other way for this argument to make sense. But then Joe implies that CPU performance is obviously more important than the ease of learning, while for Mark it's the other way around, and the two can be stuck in this argument until the end of eternity.
Let me give you another example.
Say, your team is working on a project, and a realistic ETA with healthy buffers is twelve weeks. With all non-essential features descoped today and with extensive reliance on inshallah, you probably can squeeze it to seven. And now some bigwig from management barges in and starts asking questions, what can be done to ship by the end of the month (and it's already the 10th).
The answer is Mu.
You don't have any “constructive” answer. And that's not because you're there are some magical productivity hacks and pieces of technology that Proper 100x Engineers would've definitely used, and don't know them because you're too ignorant and incompetent. That's because, given all other decisions made so far, three weeks is structurally impossible, end of conversation.
Or, say, an interviewer asks you if you can recite the algorithm for rebalancing red-black trees exactly the way it's explained in his favourite textbook.
The answer is Mu.
And don't get me wrong here. If the question was if you can improvise a red-black tree using your advanced coding skills, it's an entirely different question, and the correct answer there starts with “Oh, that's interesting, let me give it a try.”
On the contrary, the ability to recite the textbook is utterly irrelevant to your engineering ability and experience. That's why the answer is Mu.
So, there are two key ideas to take away from this chapter. One is that saying “I don't know” is fine. In school, you have a teacher to counterbalance you and tell you that, no, silly, Timbuktu is not in Minnesota. In a professional environment, especially when you're higher in the hierarchy, it so happens that on Monday, you make something up to “safe face.” And by Friday, half of the company is running on that claim, and it only goes worse from there.
The second idea is that when you're struggling to find a “definitive, unambiguous objective answer,” it's not always because you're silly or incompetent.
Sometimes it's because the question is garbage.
In the next chapter, we'll continue our exploration of Buddhism, and we will examine the concept known as the Middle Way.
In this chapter, we'll be discussing the Middle Way. It's one of the core concepts of Buddhism, and it's a rather complex topic. I don't claim complete understanding of all doctrinal intricacies, but nonetheless, I'll walk you through the aspects that are relevant for our craft.
A more basic way to interpret the Middle Way is that if you take a good idea and you push it to the extreme, it always becomes a bad idea. If, however, you take a good idea, and push it to the extreme, and get burned, and then flip around the original idea, and push it to the opposite extreme... Well, that too always becomes a bad idea.
For example, let's consider third-party libraries. As a general heuristic, it's usually good to use off-the-shelf components and not spend your own resources on reinventing something that already exists. That makes a lot of sense. However. There are many teams out there who aren't content with mere “don't reinvent the wheel,” and so they elevate it to “random strangers obviously know better, you stupid.”
Say you have to choose: spend two weeks to integrate someone else's work (and download the entire internet as a transitive dependency, twice) or spend an afternoon to DIY the 5% of features that you actually need. If you're on that team, there's nothing to discuss. Random strangers always know better, and your own version will, of course, be trash. Two weeks to integrate it is.
Also, there are many teams out there that are led by escapees from the treatment I've just described. They overcompensate for the pain they endured and declare that everything must be rebuilt in-house. That's because everything built by the outsiders who don't know the intimate intricacies of our business is, by definition, subpar and not worthy. Oh, and Lord have mercy on your soul if your boss ever finds you copy-pasting swaths of code from public repositories.
Or let's take code review culture. As a rule of thumb, careful code reviews are very valuable. However, when it's not “careful,” but more of a battle of Agincourt level of intensity, and people fight over every semicolon, that's not productive. But when the problem of lengthy reviews is “solved” by just hacking on a production server, and often not even bothering with version control, that's also not perfect, most of the time anyway.
Or let's take... I mean, I can go on with such anecdotes forever. And, if you've been in this industry for a decade or more, you can too. So, the first takeaway: if you take a good idea and overdo it to the point of absurdity, then it becomes a bad idea.
However, there's more to the Middle Way than just that.
First, moderation is not a silver bullet in itself. A middle-of-the-road idea doesn't automagically become good. A bad compromise is still bad. The middle ground can be the worst of both worlds.
For instance, this is how many refactoring initiatives go wrong before they even start. Plenty of those should've been reengineering initiatives: take your codebase, carve out the good parts, burn the rest. Then rebuild from scratch using the architecture and the tech stack that is best for the purpose, rather than one that you're sentimentally attached to.
Also, plenty of those should not have been done at all. That's because, despite all the mumblings and grumblings of frustrated coders, the economics don't work, and productivity gains over the system's lifetime won't make up for refactoring efforts.
However, it often so happens that there's no will to either shut down or bump up the project, so the team proceeds with a sequence of local clean-ups and massages that, at the end, leave everyone involved confused and disappointed.
At this point, you might ask: if a radical decision is bad, and a middle-of-the-road one is bad too, maybe no decision at all will do the magic trick? And the answer is no, it won't. Just remember: moderation is not a valid excuse for indecision.
Sure, you can avoid committing to any particular coherent set of rules, and handwave it with “oh, just rely on common sense...” But very soon you'll learn that there's little common about common sense, and it varies wildly from one individual to another.
Ultimately, it comes down to what Buddhists call Transcendence of Duality. In lay terms, and that would be the second key takeaway, it means you stop obsessing over “how much of X is right?” and take a step back to ask, “What problem are we really solving here?”
Circling back to code reviews. You don't need-need them. They're merely means to an end. It could be that what you really need is consistency and making sure that people can't sneak in code that's obviously bad. Which is a fine goal, but a much better solution here is to add a format checker and a linter to your CI pipeline, and stop wasting precious time on single quotes/double quotes debates for good.
Sometimes you need to take multiple steps back. Your team needs code reviews because you've got a lot of intricate and fragile code, and you want to prevent the occasional breakage. But the reason your team has so much fragile code to begin with is that you regularly add “smart workarounds” without proper structural support. But, in turn, the reason you have so many “smart workarounds” is because you're way too obedient when the product asks, “Can you add this little feature that such and such client asked about?” and that's the real problem you should be solving.
In the next chapter, we're going to take a pause from Buddhism and instead study some wisdom from Roman Catholic theology.
In the previous chapter, we covered the consequences of pushing good ideas to the extreme. In this one, we'll continue with an adjacent theme of extreme dedication, and a good way to illustrate it is rigourism.
Rigourism is a concept in Catholic moral theology. In a nutshell, it means you must always push for your absolute best...
Actually, let me take a step back here and clarify what exactly we're talking about. We're not talking about “try your best not to punch strangers in the face.” Actions like stealing things, killing people, setting houses on fire and such, they're all universally considered bad, and so they're out of this particular conversation. The question is really about how far you go with the good acts, such as prayer, fasting, community service, spreading the word, and so on. That, and also, how high do you set the bar of “badness.” Say, if you're building software for online gambling, does it make you a sinner by association, or is it still acceptable?
And the rigourist answer to that is to go hardcore. You must be morally perfect, regardless of circumstances, consequences, or how hard it is for you. Anything less than perfection means you're a horrible sinner and you will burn in hell.
Now, it's crucial to understand that the modern-day Church formally condemns rigourism as a borderline heresy. Meaning, if a priest notices this pattern of behaviour among his parishioners, it's his job to pull them back and tell them to take it easy and not be so overzealous. The current paradigm is called probabilism. In very simplistic terms, it means you should strive to do your best, but also keep it reasonable and sustainable, and pushing beyond that is not encouraged.
This is also a great idea to apply to professional engineering work.
Hard work is good and appreciated. Spending weekends tinkering with an insignificant module and burning out in the process... That is not good and, in any healthy environment, is actively discouraged.
Decently clean code is great. Rewriting half of the company to attain perfection, not so much.
Speaking truth to power is noble. Barking at your bosses at every meeting until they fire you without you having achieved anything, that's just silly.
Teaching your colleagues is fantastic. Burning through your goodwill on petty squabbles until you're “that angry weirdo” that nobody wants to talk to, make an educated guess.
To add colour to this moralistic conversation, it's worth mentioning that the primary driving force behind the condemnation of rigourism and the adoption of a more pragmatic approach was the Jesuit order. Which is famous for many things, but definitely not a “just take it easy and chill” stereotype.
In fact, I find it quite peculiar. For the outsiders, Jesuits are scary figures dressed in all black, inquisition, world conspiracy, all the good stuff. For the insiders, they're missionaries, educators, diplomats, chaps who keep things running. A bit like that staff engineer guy at your previous job who was floating between projects and solving critical problems nobody realised they had. So in the end, it's not that surprising they'd value sustainable practicality over unbending perfectionism.
Anyway, so, as a takeaway, I've got a rule of thumb for you. If you realise that you're being harsher on yourself (and/or people around you) than the Jesuits recommend, it might be a good time for you to spend some time in quiet contemplation and to stop taking yourself so seriously.
Now, being overly demanding of yourself is bad enough. But it can be even worse, and for that, let me circle back to that angry weirdo that nobody wants to talk to. I'm sure you met at least one. I've met, let's say, more than two, and they all shared this quirky feature. Everybody else's code was garbage, so code reviews could drag for weeks with one wave of nitpickery after another. Their own code, on the contrary, was so perfect that even a fleeting suggestion that there might be a bug in something they made would guarantee you a lecture about how incompetent and unprofessional you are.
So, as I said, asking too much of yourself is bad enough. But demanding perfection from others while also conveniently forgiving your own shortcomings is much worse, and you must first remove the log from your own eye, and then you will see clearly to take the speck out of your brother's eye. That's what the Gospel teaches us.
In the next chapter, we will continue our exploration of Christianity, and we will examine the Book of Ecclesiastes.
The Book of Ecclesiastes is one of my favourite pieces in the Bible. It teaches us that we're all going to die, and we will all be forgotten, and everything we made will turn into dust, and nothing has any meaning in the grand scheme of things, and that's exciting.
Wait, what?
Well, the “we're all going to die” part is not very exciting, but it's also inevitable, and there's nothing we can do about it, so let's not linger on it for too long. But “everything we made will turn into dust” and “nothing has meaning in the grand scheme of things” are fantastic things to realise, and let me explain why.
Imagine this wasn't true. Imagine that every minute decision you make today had to withstand the scrutiny until the end of forever. Imagine that every single thing you build had to be no less than the final wisdom. Imagine that everything you do had to align with some Great Meaning of the Universe. Imagine what a crushing burden of responsibility that would be!
Thankfully, it's not the case. At the cosmic scale, nothing really matters... And that's why we can just chill, have fun, and enjoy this beautiful day for what it is.
Well... Except that some programmers willingly accept that burden. That's why there's a lot of bad programming that stems from a question: “assuming this piece of code will stick around for the rest of eternity, how should I design it?”
Let's spend weeks and months debating the ideal design for this internal utility, so it will be future-proof for generations of coders to use it.
Let's apply these micro-optimisations. They'll pay off in the long run, except that “long run” has to be decades to have any meaningful effect.
Let's design our architecture in such a way that we can seamlessly inflate our coding force by a factor of ten, even though the customer market that can justify such expansion clearly doesn't exist.
Let's abstract away the calendar, just in case our payroll software will have to run on Mars and support 22 months per year.
So, here's one practical takeaway for you: accept the fact that your solutions have a limited lifespan and design them around that constraint. Don't build for Eternity. Pick a specific number N of months, and build for that instead.
Naturally, if you're writing software for a space probe that will have to run for decades without bugfix deploys, then your N will be in the hundreds, it is what it is. In such projects, set up your entire process around the expected longevity and be even more vigilant of the spikes of “occasional perfectionism.”
In a typical enterprise project, however, there's a good chance your “eternal” code will live until the day you quit, and then your colleagues will happily spend the next two weeks ripping it out, to the relief of everyone involved.
If, however, this was the only thing to learn from this chapter, then the Holy Inquisition will find me and burn me at the stake in the middle of Rembrandtplein for the heresy of massively underselling the Book of Ecclesiastes.
That's why I have another lesson. It's a tad touchy-feely, but also much more important.
There is no capital-M Meaning of Life, and that's just the way it is. And that's why you can make up your own meaning and run with it.
You like to build tools that make users' lives better? You like to teach your colleagues? You like to solve puzzles? You like to design systems that make sense? All of that matters, and nobody can take it away from you. Eternity doesn't care, so do your best today.
Run with it.
In the next chapter, we will get practical. We will learn about meditation techniques and why they are a crucial element of any spiritual practice.
In this chapter, I'm about to explain an extremely controversial idea. Next to it, all the flirting with world religions I've done so far pales by comparison. It goes against everything they've taught you at school, at the engineering department, and over the course of your career.
Well, maybe not you personally, but I'm confident many professional developers will find it counterintuitive and alienating.
And nonetheless, say it I must.
Ready? Here it goes.
You have to stop thinking, at least for fifteen minutes per day.
Yes, yes, I know. Throughout your time at school, you've been praised for thinking faster and with fewer mistakes than your peers. Nowadays, you're paid a nice salary to, essentially, think full-time. And I'm pretty sure you have a bunch of cerebral hobbies too, so you do a lot of thinking in your spare time as well. All three of these apply to me for sure.
That's why a suggestion to stop thinking might sound as disturbing as one to stop breathing or to chop off the left foot. Absolutely... Well, unthinkable!
And yet, it is necessary. There are certain... We can also say “abilities” or “techniques,” but let's call them skills for clarity, and the rest of the book will assume you have them. You don't have to master those skills to perfection, but you have to be aware that they exist. Otherwise, certain parts of the later chapters may read like tales about magic, and there's no way around that.
I know, this might sound a tad like initiation rites woo-woo, but it's not. In fact, it's an absolutely normal thing in any proper learning. Take a theoretical physics handbook or course, and it would assume you know how to solve differential equations decently well. If you're not good at it, a lot of the material would feel like a magic show when formulas pop up out of nowhere. Oh, and if you don't know what a differential equation is, then it would be mostly hieroglyphs and gibberish. This is what you'd normally expect, and with applied spirituality, it's not too dissimilar.
Specifically, there are three skills that you'll have to learn: control of your thoughts, control of your perception, and control of your emotions. The way to learn each of those three is via meditative techniques.
Now, to drive the level of woo-woo down a few notches once again, let me explain to you several key ideas about meditation.
First, if you're a software engineer, I'm pretty sure you're already familiar with meditation. Your mind might not recognise the name, but your body certainly knows the feeling. You know the state of flow. You know the state of deep immersion when your entire attention is focused on coding or debugging, so that you detach from the world around you. And you know that this is the state of mind in which you, as a coder, are happiest and the most productive. Meditation isn't exactly the same, but it's a very similar trance-like state of consciousness, so there's really nothing to be sceptical or suspicious about.
Second, the exact choice of technique doesn't matter that much. What matters is that you're comfortable doing it on a regular basis. You can do Zazen, you can do Shavasana, you can hike in the forest, you can run long distances, you can draw mandalas, you can chant “Om Mani Padme Hum,” you can chant “Ave Maria, gratia plena, Dominus tecum,” you can lie on a sofa and listen to psychedelic trance. I've literally tried all of that, and all of that works.
The only constraint is that the task shouldn't consume too much attention, so you have enough left to observe what's going on inside your head. I heard some people saying, “My meditation is driving a motorbike” or “My meditation is playing computer games,” and I'm quite sceptical about those. But then, what works for you is what works for you. That is, as long as it works, you know the drill.
If you don't have any preferred technique yet, try Zazen, it's a safe default choice. Here's how you do it:
I advise starting with 10-15 minute sessions, and then see how it goes. For me personally, fifteen minutes is the sweet spot. Less than ten might be too short to get into a proper mood on a busy day. And above twenty, it begins to gradually slide into the altered state of consciousness territory, which isn't something I like to do on a daily basis. Oh, and when I say “gradually slide,” I mean very gradually. You're not going to get a “magic plants” level of experience by accident, don't worry about that.
Start small, try it out and see how it works for you.
Third, unlike technique, the exact intent is everything.
I knew people who meditated to look pretty in a lotus pose and have something to yap at the dinner parties, and they were very successful at that. I also knew people who meditated to attain Krishna Consciousness, and they were very successful at that.
With your meditative practice, I advise you to focus on developing three skills: control of your thoughts, control of your perception, and control of your emotions. Let me walk you through these one by one.
Control of your thoughts is what you start to feel pretty early on.
It's not uncommon for people to assume that a person and a person's thoughts are inseparable. I'm my thoughts, and my thoughts are me.
Except that this is wrong. You can stop thinking, and you won't disappear into thin air, but you'll remain where you are. You can start thinking about something intensely unusual, and you won't suddenly grow a third eye and a second nose, but you'll remain yourself. You can even ask yourself if you agree with what you think, and it won't be a dissociative disorder. It would be a perfectly normal process of inventorying, which concepts you've actually bothered to examine critically, and which you've just picked up along the way.
Mastering this skill will have bittersweet consequences on your life. Many people assign outsized importance to trifles like “I think about cheeseburgers much more often than about paella” or “I think about this politician much more often than that other politician.” Some will even make them the foundations of their personalities and identities.
Once you learn to notice how hilariously silly that is, it's tough to unsee.
Control of perception is essentially the ability to be in the moment. It's when you look at a tree and see a tree. It's when you take a sip of coffee and taste coffee. It's when you listen to your boss lying to you, and you hear your boss lying to you.
And no, that's not how people normally function. A person who is not trained in either meditation, botany, or sketching can maintain attention on a tree for, maybe, a minute.
Then they'd notice a bird sitting on a branch, and then they'll be looking at the bird, and they will see the bird, and they won't see the tree. Or they'd notice a cloud floating behind the tree, and they'll be looking at a cloud, and they will see the cloud, and they won't see the tree.
Or they'd notice an aeroplane flying by, and they'll be thinking about holidays, tropical island, white sand beach, sunset over the ocean and a few Cuba Libres too many. In no time, they'll be seeing scantily dressed dancers of their favourite gender, and they won't see the tree.
Or they'd notice they're wasting time, so they'd be embarrassed by themselves, and rush home to study from a book about habits of very effective people. Obviously, they won't see the tree.
Some people will take a sip of coffee and taste coffee. Some will take a sip of coffee and taste validation that they're drinking proper fairtrade arabica, not supermarket crap.
Some people will hear their boss lying to them, take notice and start planning measures. Some will take those words at face value because the alternatives are very uncomfortable.
And to be very clear here, I don't mean to shame any of those people. What they do is perfectly normal. Perceiving the world as it is 100% of the time would be very cognitively taxing and inefficient. That's why we have all that processing machinery that takes the sensory input, converts it into labels and patterns, and then attaches it to the knowledge graph of abstract concepts, stereotypes, memories, social conventions, and Kahneman knows what else. Love it or hate it, this is how human beings function, you and me included.
And, as long as you stay aware that said machinery exists (control of thoughts helps a lot with that), and make amends when it takes egregious shortcuts, you should be fine. Troubles begin when a person starts to feel proud of how “smart” (and/or how “right”) they are. Then they begin to act as if their opinion on how things are is more important than how the things actually are, and that's dangerous.
Look, if there's one thing I know for sure, it's that when your idea of reality is out of touch with reality, there's no conversation to have, no negotiations to hold, and no consolation to offer. You are wrong, reality is right, full stop. Reality is always right about what it is, and you adjust to that.
That's why you have to stay curious, stay humble, and pay attention. This way, you can continuously micro-adjust your worldview and your behaviour, rather than stubbornly force your way into one crisis after another.
And look, this is not some deep ancient esotericism I'm talking about here. It's literally just the good old control theory, applied to daily life.
Control of emotions is conceptually similar to control of thoughts, except it's harder. If I tell you, “stop thinking about a pink rabbit, start thinking about a blue monkey,” that's not too hard. If I instead tell you, “stop being so afraid of your boss,” that'd be a genius idea, except you have a whole lot of cortisol in your bloodstream, and you can't just ignore it. You can consciously navigate your behaviour around it, and even that requires effort and trained skill.
When it comes to control of emotions, there are two somewhat popular ideas. One of them declares that you have zero control. Basically, you're like Pavlov's dog, stimuli in, responses out, no conscious processing in the middle.
So, if you look into the source code of that library you've been carefully crafting, and you notice that your colleague Joe has butchered it by throwing a dirty hack in the middle of it, then you're fully entitled to throw a tantrum. You can go to Joe's desk and scream, shout, punch, kick, throw coffee mugs and keyboards across the room. It's all good, you're upset.
Another somewhat popular idea is that you have total control over your emotions. Basically, you're like a high-level Shaolin monk. So, when Joe butchers your library, you must quietly appreciate the beauty in imperfection, and anything less than that means you're not properly enlightened and a horrible human being.
Needless to say, both these ideas are garbage, and the truth is somewhere in the middle. In the example above, the proper course of action is: first, you calm yourself down to a level where you can have a coherent professional discussion. Second, you have that discussion. No fight-flight-freeze-fawn shebang, but a confident technical conversation about which body parts Joe used for thinking that day, and how to proceed from there.
Don't underestimate your ability to control your own emotional state. If you don't believe me, just close your eyes, take a deep breath in through the mouth and out through the nose, and say “I feel kind, I feel grateful, I feel joyful.” Repeat for several minutes. Observe how you feel. I mean, I'm not saying you'll feel radically different after three minutes. But there will be a slight change of mood, and you can experiment with that.
But also don't get me wrong here. All these forms of self-control are about navigating the external circumstances, not about pretending like they don't matter. If you have to spend two or three hours every day commuting, it really helps if you focus on gratitude and joy instead of annoyance and despair. But it also really helps if you sort out the work-from-home arrangement.
This is all I've got to say about meditation. In the next chapter, we will examine the concept that Buddhists call Suffering.
Suffering is one of the core Buddhist concepts. The tricky thing about it is that they repurpose the word from common vocabulary, while slightly adjusting its meaning, and it takes some time to piece together what is going on exactly. Let me walk you through.
In Western culture, we commonly see suffering as something imposed on us from the outside. The world is full of evil people who do terrible things and make your life awful. Also, the world is full of random shit that happens and makes your life awful. Besides that, the world is full of nice things you can't have, which makes your life awful. And then there are variations and combinations, but pretty much everything can be traced back to these three categories.
Therefore, we as a society and we as humankind must achieve three goals. We must eliminate random shit, or at least build a sufficient safety net and civil infrastructure to neutralise it. We must eliminate bad people, and we must make nice things available to everyone. Then, generously assuming we can agree on which nice things are excessive and which bad people are still redeemable, it will be Heaven on Earth.
And then the Buddha comes in and says no, you're not getting the perfect world simply by eliminating the external factors. That's because suffering is an innate feature of human nature, and many people suffer because of that reason and that reason only.
And let me make one thing very clear here. Some people do suffer because of the circumstances they find themselves in, and pushing all the blame back on their “lack of mindful enlightenment” would be very cruel and stupid. If you go to sleep in a peaceful village and wake up in the middle of a warzone, that's not “an opportunity to grow,” that's a catastrophe, and every social media “guru” suggesting to “find a positive side in everything that happens to you” is welcome to trade places with you and your loved ones.
With that disclaimer written down. Many people do suffer while having no rational narrative or redeeming reasons to attach to that. Like, many people just eat junk food. Not because they can't afford proper nutrition. Not because they're looking forward to having a stroke shortly after a heart attack. Not even because it tastes better than the healthy alternatives. They just eat junk food.
In very simple and blunt terms, many people just do shite without a reason... Wait, let me be more precise here. Many people just do shite without a rationale or a purpose. If you ask them, hey, how did you even get into this nasty situation, for sure, there's a story behind it, always. If, however, you ask, do you really have to stay in this nasty situation, that's where things tend to get complex.
Now, you might say, okay, that's a fine idea, but does it really apply to the software development domain you're writing about? We're developers, which means we're usually better educated, and proudly more rational, and hopefully a smidgeon smarter than the general population. We should be safe from harm here, right? Right?!
Well... We have a very particular weakness.
As engineers, we're constantly dealing with sacrifices, tradeoffs, and compromises. That's why when we see a dubious solution, we're often too quick to assume that it must have been a product of one. So, it must have some redeeming advantages, even if you don't see them immediately. Like, it's difficult to maintain; thus, it must be reliable. Or, it's hard to understand; therefore, it must be fast. Or, it's slow; hence, it must be easy to develop. Or something along those lines.
This isn't always true. Some ideas are simply bad across the board.
Sometimes people just use inadequate platforms for their software systems.
Some people just write functions that span multiple thousands of lines of code and take twenty arguments for input.
Some people keep maintaining a dozen heavily interconnected microservices that really should be a single tidy REST endpoint. While some keep maintaining a bunch of heavily interconnected spreadsheets and bash scripts that really should be a single neat application.
Some people produce copious unit tests that don't really test anything. Some copy-paste swaths of code and then painstakingly keep them in sync. Some obsess about carving microseconds off code that is nowhere near the critical path.
So, the takeaway for this lesson is: when you see something bad, don't rush to assume it has some redeeming qualities you simply don't know yet. Some things are just bad, period.
Now, “bad” is a tricky three-letter word that can trigger a variety of complex responses. One is the “it's not a bug, it's a feature” denial we've discussed. The other is to fixate on “how did we even get into this mess?” with the intention to either find someone to blame for their lack of perfect foresight, or to find “the last good version” that you can revert to, or something along those lines.
I mean, don't get me wrong here, “how did we even get into this mess?” is a great tool to gain situational awareness and to learn what decisions were made and why. However, more often than not, you'll discover that this idea / system / process / decision made perfect sense in the past, but had a “reevaluate a year later” asterisk attached to it all along, and now it's time to do exactly that.
Typically, aside from trivial situations when everything can be traced to a singular local mistake, you can't just roll back. Instead, you must roll forward, and the right questions to ask yourself are:
Don't let your perfectionism skip the third question. It can happen that the piece of software you're looking at is absolutely atrocious, but also has very limited scope and impact. Then, just let it sit in its mouldy corner, and look for better problems to solve.
And when it comes to “what is holding us back,” prepare to feel embarrassed. That's because a whole lot of suffering in our domain is root-caused by nothing else but people getting stuck in a rut and “doing what they always did” with nobody there to take a step back and ask questions. When you examine it carefully, you'll find out that a lot of problems originate from blind spots, lazy thinking, cognitive inertia, tunnel vision and similar thought distortions.
This is why you have to meditate. As I explained earlier, detaching from your thoughts and “getting out of your head” is a powerful tool for spotting lazy thinking, and you'll need it.
Tunnel vision is not the only form of distorted thinking out there, there are others as well. One peculiar example is ego titillation, and let me explain what I mean here. When you see a system that is so complex and convoluted that it takes a superhero genius to navigate it, look around. Quite likely, there'll be a bunch of those “superhero geniuses” on the payroll advocating that “this is how things are meant to be, and you're too incompetent to understand.” We'll get back to handling such social conundrums in later chapters.
So, if the first takeaway is that some systems and processes are bad for no reason, then the second one is that some systems and processes remain bad only because nobody bothered to fix them.
And now that we've got a general idea of what Buddhists call suffering, we can continue with the exploration of one of the major causes of suffering, which is attachment. That will be the topic of the next chapter.
I'm writing this chapter now. I will publish it when I will publish it.