In the 6th century a man named Benedict of Nursia retreated to a cave in Subiaco, Italy. What emerged was a 73-chapter document that has governed monastic life for 1,500 years. Studying his life and rules changed the way I approach software development.
It must sound weird at first: how can a 6th century monk influence software engineering? But think about it: the monastery and a codebase have more in common than you’d think. Both are systems requiring constant human cooperation to survive. Both demand discipline without rigidity. Both can collapse under ego, haste, and the illusion of individual brilliance. And both, at their very best, are quiet, humble, daily acts of craft.
I’ll be honest about where I’m coming from: I’m a Catholic, and Benedict is my patron saint. But this post isn’t a catechism. What strikes me, reading the Rule through the lens of my work, is how little it requires faith to follow.
Benedict didn’t set out to write management theory. He wrote a Rule, a living document to govern how a community should work, pray, rest, and grow together. But strip away the Latin and the liturgical hours, and what remains is a strikingly practical philosophy for anyone building things that last with other people.
Here are the eight principles I’ve distilled from the Rule
1. Listen with your heart and act accordingly.
In the Rule, Benedict speaks about the “ear of your heart” (aurem cordis tui). It’s a call to listen with intention, to hear not just words but the deeper meaning behind them. Benedict understood that the most dangerous person in any community is the one who arrives already knowing the answer. In software, that person starts coding before reading a single user story. They talk in every standup and absorb nothing. Good engineering starts in the ears and after that comes action.
2. Commit to your craft, codebase and team.
When Benedict wrote the Rule, the world was in dissaray. The Roman Empire was collapsing and society was in chaos. Benedict’s Rule was a response to that chaos, a way to create order and stability. He emphasises commitment to remain rooted in one place and one community. This vow of stability goes beyond physical location and is a commitment to stay grounded through the ups and downs of life. Instead of relentless job hopping, technology switching, and chasing the next big thing, commit to mastering your craft, understanding your codebase deeply, and building strong relationships with your team.
3. Focus on the work that matters.
In the monastery, when the bell rang for the Opus Dei (the work of God), monks dropped what they were doing immediately and joined in the communal prayer also called the liturgy of the hours. For Benedict, the Opus Dei was the “weight” or “task” of service that a monk owed to God. As a software engineer you should see this pricinple as a separation of the core work (coding, architecting, reviewing) over the “shallow work” (slack, emails, Jira updates). For example you block in your agenda time for deep work and ignore all distractions and notifications at that time.
4. Practice discernment.
In the Rule of Saint Benedict, discretion (discretio) is deemed the “mother of virtues,” representing a balanced, moderate approach to monastic life. It focuses on avoiding extremes in fasting or work, catering to individual needs (sick, elderly, young) ensuring sustainability, compassion, and spiritual wisdom. In engineering, this is the rarest skill. The developer who always abstracts too early. The one who never refactors at all. The team that documents everything obsessively. The one with no documentation at all. Discretion is knowing when a function deserves a comment and when the code is the comment. It’s the judgment that can’t be taught by a linter, only developed through years of consequence.
5. Serve the system, not your preferences.
This one stings a little. Benedict’s vision of obedience was the recognition that the community’s needs outrank personal preference. In a codebase shared by dozens of engineers, my aesthetic opinion is a liability if I can’t subordinate it to consistency. The tabs vs spaces war is not a hill worth dying on. The team’s existing patterns, even imperfect ones, are almost always worth following until there’s a proper moment to refactor them collectively. I’ve learned to save my rebellions for things that actually matter: security, correctness, the user.
6. Take the unglamorous work seriously.
Benedictine monks farmed, cooked, copied manuscripts, built walls. Manual labor wasn’t beneath them it was sacred. Benedict says idleness is the enemy of the soul and ordered his followers to practice Ora et Labora (pray and work). It is a balanced approach that neither neglects spiritual growth nor physical labor. In engineering, the equivalent is the work nobody tweets about: writing migrations, updating dependencies, fixing flaky tests, reviewing someone else’s PR with genuine care, improving error messages that only appear in edge cases. The engineers I most respect are the ones who leave things better than they found them, quietly, without attribution. They are the monks of the codebase, tending the garden while others chase the exciting new feature.
7. Give correction with care, and receive it with grace.
Benedict had a whole protocol for correction, private first, then involving others only as a last resort. It’s essentially the conflict resolution model that every modern engineering manager learns in a book and promptly forgets under pressure. Code review is an act of correction. It can be done as an attack, or it can be done as a gift. The difference isn’t only in the tone, it’s in the underlying belief about the person you’re reviewing. Benedict assumed the monk was fundamentally good and temporarily mistaken. That assumption changes everything about how you write the comment.
8. Commit to ongoing conversion, always be a beginner.
In his book the Rule, Benedict talks about Conversatio morum suorum: the ongoing conversion of one’s way of life. Not “I have been converted” but “I am always being converted.” This is perhaps the most radical of the vows. The monk commits not to a finished state of holiness but to a continuous process of transformation. No arrival. No graduation. No point at which you’ve figured it out. The best engineers I know carry this same posture. They don’t protect their expertise they put it at risk by taking on problems that exceed their current ability. They say “I don’t know” with the same ease they say “I’ve got this.” The Zen tradition calls it shoshin (beginner’s mind). Benedict just called it faithfulness.
The monastery we are in.
I don’t think you need to be religious to take Benedict seriously. You just have to believe that how you do your work matters, not just what you ship, but how you treat your team, whether you stay when things get hard and whether you protect the silence that lets you think clearly,
The monastery was never really about monks. It was about what it costs to build something that lasts, with other people, over a long time. That’s what we’re doing too, whether we know it or not.
Ora et Labora pray and work. Or in our language: think carefully, then build honestly. Rest, then return. Leave it better. Show up again tomorrow.