Every software developer has encountered code without comments—functions whose purpose is mysterious, algorithms whose logic is opaque, decisions whose rationale is lost to time. You can see what the code does, but you don't know why it does it that way.
Good programmers comment their code. They explain not just what the code does (which you can see by reading it) but why—the reasoning behind decisions, the edge cases being handled, the context that makes apparently odd choices make sense.
This practice illuminates something theological: the relationship between Scripture and tradition, between text and interpretive context, between what's written and the living community that explains it.
The Self-Commenting Code Myth
Some programmers claim code should be "self-commenting"—so clear that it needs no explanation. Just write clean code with descriptive names, and its purpose will be obvious.
This works to a point. Good naming helps. Clean structure clarifies. Obvious algorithms need less explanation than clever ones.
But some things can't be inferred from the code itself. Why did you choose this algorithm over that one? What edge case is this weird check handling? What external constraints shaped this design? The code shows what; comments explain why.
Similarly, some Christians claim Scripture is "self-interpreting"—so clear that tradition and church teaching are unnecessary. Just read the Bible, and its meaning will be obvious.
Again, this works to a point. Scripture is clear on central matters—God's existence, human sinfulness, Christ's saving work. But Scripture also contains passages whose meaning isn't obvious, commands whose application requires context, principles whose implementation demands wisdom.
The Autistic Documentation Need
As an autistic programmer, I especially value documentation. I don't automatically infer social context or unspoken assumptions. If you don't document it, I won't guess it.
Tell me why this function exists. Explain the business logic it implements. Describe the problem it solves. Don't make me reverse-engineer your intentions from code alone.
This isn't a deficit—it's a different cognitive style that demands explicitness. And it often results in better documentation that helps everyone.
Similarly, in biblical interpretation, I don't automatically absorb cultural context through social osmosis. I need the explicit work of scholars who explain ancient contexts, trace theological development, and articulate the reasoning behind interpretive traditions.
When Documentation Conflicts with Code
Sometimes code and comments diverge. The comment says one thing; the code does another. This usually means the code changed but comments weren't updated. Which do you trust?
The answer: investigate. Maybe the comment is obsolete. Maybe the code has a bug. Maybe both are wrong. You can't automatically assume the code is authoritative—sometimes comments preserve original intent that code has drifted from.
This parallels theological hermeneutics. When Scripture seems to conflict with tradition, which takes priority?
Protestants typically say Scripture. Catholics and Orthodox typically say Scripture and tradition together. But even Protestants rely on traditional interpretations more than they often admit—they just call them "obvious readings" rather than "tradition."
Living Documentation
The best documentation isn't static—it evolves with the code. As code changes, documentation updates. As understanding deepens, comments improve. Documentation is living, not dead.
Christian tradition works similarly. It's not arbitrary additions to Scripture but developing understanding of Scripture's meaning. The early church wrestled with Christological questions Scripture doesn't explicitly answer. Their conclusions became tradition—living documentation of how Scripture's principles apply to questions it doesn't directly address.
This doesn't mean tradition is infallible or that it can't be corrected by Scripture. But it means dismissing tradition entirely is like deleting all comments and documentation because "the code should speak for itself."
README Files and Creeds
Most software projects have README files—high-level documentation explaining what the project does, why it exists, how to use it. You can understand individual functions without reading the README, but you'll miss the big picture.
Creeds and confessions function like README files. They summarize essential teachings, explain core commitments, orient newcomers to the tradition. You can read Scripture without them, but they provide context that prevents misunderstanding.
The Nicene Creed doesn't add to Scripture—it summarizes Scripture's teaching about God's nature in response to specific heresies. It's documentation: "Here's what the church, reading Scripture carefully, concluded about who God is."
API Documentation and Systematic Theology
Application Programming Interfaces (APIs) need documentation explaining how components interact, what functions do, what parameters mean. Good API documentation makes complex systems usable.
Systematic theology is like API documentation for Scripture. It explains how doctrines relate, how principles apply, how various teachings fit together. You could study individual passages without systematic theology, but systematic theology reveals the architecture—how everything connects.
My autistic love for systematic thinking makes me appreciate systematic theology. I want to know how doctrines relate, how principles cohere, how the whole structure fits together. Systematic theology documents the "API" of Christian truth.
Git Blame and Church History
Git has a "blame" feature (unfortunately named) that shows who wrote each line of code and when. This is invaluable for understanding why code exists—you can trace its history, see what problem it solved, understand its original context.
Church history serves similar functions. Why does the church teach this? Trace the history. What problem was this doctrine addressing? Look at the historical context. How did this practice develop? Follow its evolution.
Understanding history doesn't mean being bound by it. Sometimes historical code should be refactored or removed. But you should understand why it existed before changing it—otherwise you might reintroduce bugs it was solving.
Code Review and Accountability
Modern software development uses code review—other developers examine your code before it merges into the main project. They catch bugs, suggest improvements, ensure quality.
Christian community functions similarly. We don't interpret Scripture in isolation. The church reviews our interpretations, challenges our assumptions, corrects our errors. Tradition represents centuries of collective code review.
This doesn't mean majority opinion is always right—popular code can have bugs. But it does mean individual interpretations should be tested against community wisdom.
Technical Debt and Theological Distortion
"Technical debt" describes shortcuts that make future maintenance harder. You skip documentation to ship faster, but later developers struggle to understand the code. Debt accumulates.
Theological traditions can accumulate similar debt. Shortcuts in thinking, unexamined assumptions, cultural distortions that get transmitted without critique. Eventually, the tradition needs refactoring—reformation.
The Protestant Reformation was partly this kind of refactoring. Medieval theology had accumulated significant debt—practices poorly connected to biblical foundations, traditions that obscured rather than clarified Scripture. Reformers didn't reject documentation entirely; they demanded better documentation, more directly tied to the source code.
Open Source and Catholicity
Open-source software is developed collaboratively by global communities. Code and documentation improve through diverse contributions from many people and perspectives.
"Catholic" (universal) Christianity works similarly. The faith is developed, preserved, and transmitted by global church through centuries. African theologians, Asian church fathers, European reformers, Latin American liberation theologians—all contribute to the living documentation of Christian truth.
No single person or culture has complete understanding. We need the global, historical church's collective wisdom—the "open source" collaboration of saints across time and space.
Version Control and Development of Doctrine
Code evolves through version control—changes tracked, history preserved, evolution visible. You can see how the project developed from initial commit to current state.
Doctrine develops similarly. The church's understanding of Scripture evolves as new questions arise, new contexts demand application, new heresies require clarification. This isn't adding to Scripture but unpacking its implications.
The Trinity doctrine developed over centuries—not because Scripture is unclear about God, but because explaining how Father, Son, and Spirit relate required careful work. The development is visible in church history, like commits in version control.
When to Rewrite
Sometimes code is so tangled that documentation can't save it. You need to rewrite from scratch, starting with clear specifications and clean architecture.
Theological traditions sometimes need similar dramatic reformation. When accumulated tradition obscures rather than clarifies Scripture, when documentation contradicts code, when debt is too high—reformation is necessary.
But even reformation preserves more than it rejects. Protestant reformers kept creeds, maintained liturgical structure, valued church fathers. They refactored, but didn't start from scratch. Even revolutions preserve more than revolutionaries typically admit.
Practical Application
What does this mean practically?
- Value tradition: It's documentation from centuries of collective wisdom
- Test tradition: Documentation can be wrong; verify against Scripture
- Update understanding: Let tradition develop as understanding deepens
- Document clearly: Explain not just what you believe but why
- Learn history: Understand why traditions exist before rejecting them
- Work collaboratively: Don't interpret alone; engage community
- Refactor carefully: Reform when necessary, but preserve what works
Conclusion
Code without documentation is hard to maintain. Scripture without tradition is hard to interpret. Both the code and the documentation matter. Both Scripture and tradition serve essential functions.
Scripture is authoritative—it's the source code. Tradition is documentation—it explains how generations of believers understood and applied that code. Good documentation serves the code; it doesn't replace or contradict it.
As a programmer, I value both clean code and clear documentation. As a Christian, I value both Scripture and tradition—not as competing authorities, but as complementary resources.
Scripture tells us what God has revealed. Tradition tells us how the church understood and applied that revelation. We need both—just as we need both code and comments, both functions and documentation, both README files and implementation details.
The code is primary. But without documentation, we'd constantly rediscover what previous developers already learned, repeat mistakes they already corrected, miss contexts they carefully preserved.
So I read Scripture. But I also read tradition—the church's living documentation of how to read Scripture well, apply it wisely, and pass it on faithfully.
Because good programmers comment their code. And good Christians learn from tradition.