Software development is one of the newest and fastest growing forms of work, with no sign of that growth slowing down. As a generation of Christians enter this field, I want to help them – and all of us – to think theologically about how this role fits within God’s purposes in the world and what it means to be a software developer as a Christian. Here are seven principles that can serve as a theological foundation for software development.

1. Creation Mandate

When God created humanity He created us in His image and commanded us to “fill the earth and subdue it.” God rules over His creation, and we engage with the world as sub-creators (fill it) and vice-rulers (subdue it). J. R. R. Tolkien said that it is as if the single white light of God is refracted through each of us into a myriad other colors in our many “sub-creations.” This perspective requires that we view the Christian life through a wide-angle lens. It is not only pastors and missionaries who do God’s work in the world but also those who build and develop, extending God’s creation in obedience to His creation mandate.

Every morning my wife and I recite something we call the Children’s Creed with our daughter. One line in the creed says that God “made my hands to build, create, and help others.” This is the foundation for all of a Christian software developer’s work. The biblical worldview sees most actions as morally neutral in and of themselves, placing the emphasis on the motivations behind them. Is it right to speak? It depends on the words, the context, and our motivations. Is it right to give money? Again it depends on the context and our motivations. Similarly software development is not good or bad in and of itself, but our motivations for doing software development are extremely important. A key first step is to view software development as an extension of God’s work in creation, performed in obedience to our command to “fill the earth and subdue it.” This perspective frames everything that follows.

2. Bringing Order to Chaos

One of the first truths that the Bible teaches about God is that God is a God of order. An ancient creation story known as the Enuma Elish presents creation as an accidental event where one god viciously rips another god in two, and the blood of the defeated god rains down to create the world as we know it. By contrast, the Bible presents God as following a clear and orderly plan of creation – step by step, day by day. God’s creation is creation ex nihilo (creating something out of nothing) turning the chaos of nothingness into an orderly something. When creation falls apart into chaotic evil, God sends a flood to wipe out His creation and start anew (software developers call this a ground-up rewrite!). God gives Israel the Law, and He gives the Church orderly guidelines on church government, mission, ministry, and worship. The Bible teaches that behind the apparent whirlwind of events throughout human history, God is providentially working all things for good and for a single purpose, like a chess master planning and ordering each move. God is a God of order.

A significant amount of time spent in software development involves bringing order to chaos. To begin with, software development may be the closest that humans can come to creation ex nihilo. In the beginning of a project there is nothing but an idea. No raw materials to be formed or reworked—merely the chaotic nothingness of an idea. Then the developer creates something out of the nothingness. But every developer who has worked on a mature project, often referred to as “legacy code,” knows that chaos creeps into code, and the developer must continually “refactor” existing code, reworking it to fit with new requirements or updated conventions. The Boy Scouts have a well-known rule that you should always leave a campsite cleaner than you found it. In the book Clean Code Robert Martin says that developers should follow the Boy Scouts rule, always leaving the code cleaner than they found it. This is a wise principle for any developer, but for Christians specifically this flows from the very nature of our God who brings order from chaos. Clean code and good software architecture reflect the God in whose image we are made.

3. Beauty

On April 15, 2019 the world watched in horror as the Notre-Dame cathedral burned. I remember sitting with my eyes fixed on the screen, feeling an overwhelming sense of loss for a building I had never seen and had never really cared about before. Why did I and so many others experience such sadness over the cathedral fire? Because human beings are made in the image of the God who embodies and appreciates beauty, and we are deeply affected by beauty. One of our deepest longings is “to gaze upon the beauty of the Lord” (Ps 27:4). But even earthly beauties strike us at our core—the Grand Canyon, the Taj Mahal, Pachelbel’s Canon in D, the ceiling of the Sistine Chapel. Ancient philosophers spoke of the three “transcendentals” of Truth, Goodness, and Beauty. Each of these is perfectly embodied by God, and each is of the utmost importance to us. But of the three it is beauty that affects us most deeply. We simply are not moved by something that is true or good in quite the same way that we are moved by something that is beautiful.

For software developers this has important implications for the centrality of good UI/UX design. An app that is true (functions reliably) and morally good but is not beautiful will not capture or engage its audience as it could. More importantly there seems to be an intrinsic deficiency with this sort of app. When the Lord created the universe He designed the Pinwheel Galaxy, the Medusa Nebula, and the rings of Saturn. When He created the earth He crafted the Swiss Alps, the Grand Canyon, the Redwood tree, and the colors of a sunset. When He arranged for the construction of the tabernacle He called the skilled craftsman Bezalel and filled him “with knowledge and all craftsmanship to devise artistic designs” (Exod 31:1-5). Beautiful design is intrinsic to the Lord’s creations, and we should seek to the best of our ability to incorporate it into ours as well.

4. Writing Fallen Code

The fourth principle may seem obvious, but it is crucial that we admit and embrace it: we write fallen code. The Fall corrupted everything, including our ability to write code and the very code that we write. If you are a software developer, take a moment to imagine what it would be like to write perfect code in a perfect world. We would never have bugs. We would never write tests. We would never request code reviews. Just type it and ship it and forget about it. But this is not the world we live in. When people ask what I do for a living, I often like to joke that I make software bugs. That’s the reality of being a software developer. There are a lot of bugs out there, and some of them are yours.

Since we write fallen code, this means that we must have code reviews. If we know from the outset that our code is going to contain bugs, why would we send it straight to our users without having another developer review it first? Code reviews are necessary in a fallen world. So are unit tests. We write fallen code now, and we will write fallen code in the future. Unit tests provide some means of correcting the errors within our current code and preventing against errors in future code. Still some errors will make it to the user, as every software developer knows all too well. Admittedly many app developers find a sort of dark amusement in reading some of the more colorful negative reviews of the apps we work on. Although we take these reports seriously and seek to correct them, we also have to approach them with a humor and humility that admits our own imperfections. One of my favorite reviews I’ve seen is for a Bible app that I worked on which referred to the developers as the “daughter of Satan!” While this may be a bit extreme, we do write fallen code. Admit it, embrace it, and toil against it by whatever means possible.

5. Love Your Neighbor

In Dan Doriani’s excellent book Work he shares a story of an interior designer who loves most of her work with the exception of one aspect. She says that she does that part of her job not because she enjoys it but because her clients need her to do it, and so she does it as a means of loving her neighbor. When I read that story I immediately closed the book and wrote a note on an index card that sits on my desk to this day – “Love your neighbor: fix some bugs.” I love almost every aspect of software development, but I do not enjoy the process of finding and fixing bugs. I joke with my coworkers that I get paid to fix bugs – everything else I would do for free! But as a Christian I have a more important reason to fix bugs. The people who use the apps that I work on are negatively affected by bugs in those apps, and so fixing these bugs is a tangible way for me to love my neighbor as myself. I hate bugs in the apps I use too. Shouldn’t I do unto others as I would have them do unto me?

I know many software developers who find bug fixing to be the most enjoyable aspect of their work. But there is almost certainly some aspect of software development that every developer finds less enjoyable than others. Maybe it is meeting accessibility standards for those with visual or other impairments. Maybe it is optimization to make sure your app doesn’t drain a user’s battery. Maybe it is writing detailed documentation around an API endpoint. Maybe it is a significant amount of refactoring needed to deliver quality features in the future. Maybe it is creating acceptance tests. Maybe it is polishing off a screen design, or doing the user research required to really improve UX (user experience). Whatever the specific aspect may be for you, the parable of the Good Samaritan teaches that we are called to a higher standard. Everyone is our neighbor, and we are called to help even at significant inconvenience to ourselves. So if you are a software developer, love your neighbor and fix some bugs.

6. My Brother’s Keeper

In Genesis 4 when God asks Cain where his brother Abel is, Abel responds, “Am I my brother’s keeper?” Although the reply is sarcastic the question is a valuable one, and the biblical response is, “Yes.” Old Testament Law required anyone building a house to build a short wall called a parapet around the perimeter of the roof to prevent neighbors from falling off and injuring themselves (Deut 22:8). The New Testament says that although we are free to eat meat from pagan temples, we should not do so if it causes our brother to stumble (1 Cor 8). An extension of the command to “love your neighbor as yourself” is to actively seek to avoid harming your neighbor in any way.

John Dyer makes an important point in From the Garden to the City that applies this principle to the work of software developers. He notes that when we use technology it is not only the content that forms us but the technology itself. I have come to refer to this as the “Twitter Effect” after an example that Dyer provides. He contrasts two Twitter users, one whose feed is filled with theologically rich content and another whose feed is filled with moral trash. We all know that the different content will form these users in different ways. But after months of using Twitter extensively, both users may find that they have a shorter attention span, that they are more attracted to provocative headlines than to thought-provoking content, and that they have developed “restless thumb syndrome,” constantly scrolling in moments of boredom. Although the content has shaped the users differently, the technology itself has shaped them in the same way.

As a software developer this is an important and sobering realization. Even if I am developing a Bible app – the highest possible content – I still have to ask how the technology itself is affecting the people who use it. What parapets do I need to build within my app? How might some proposed feature cause a user to stumble? As an example, suppose I am developing a prayer app and am considering adding a “prayer streak” feature to track how many days in a row the user has prayed. This could be a great incentive to nudge people to pray daily. But it could also subtly turn prayer into a sort of game where the user prays daily for the same reason she plays Candy Crush daily. If this happens then my prayer app could actually be harmful to her relationship with the Lord. As a developer I have a moral obligation to consider these weighty implications of the products I develop. James writes that not many of us should become teachers since teachers will be judged by a higher standard (James 3:1). Ultimately this is not about teaching per se but about influence. And software developers have a tremendous amount of influence on people through the technologies we develop. We should not take this responsibility lightly.

7. Glorify God

“What is the chief end of man? Man’s chief end is to glorify God, and to enjoy Him forever.” Software developers have many goals. We aim to create beautiful, useful software that makes a positive contribution to the lives of the people who use it. We aim to develop exciting new features that our users aren’t even aware they wanted until they see them. We aim to make our software efficient, stable, and easy to work with. But as Christian software developers our overarching goal — our “chief end” — is to glorify and enjoy God. This is not something that we do in addition to software development but through software development. Our work is one of the many avenues by which we glorify God.

One practical way to keep this front of mind is to bathe your software development in prayer. Facing ambiguous design decisions? Complex architectural choices? Hiring decisions? Roadmap planning? Debugging difficulties? “If any of you lacks wisdom, let him ask God, who gives generously to all without reproach, and it will be given him” (James 1:5). Refuse to buy into the world’s lie that you are enough. Remind yourself daily that “we have this treasure in jars of clay, to show that the surpassing power belongs to God and not to us” (2 Cor 4:7). Christian software developers, admit your dependence on the Lord, and write your code to the glory of God.