Debugging your Faith

Bugs Everywhere

Back in February we planned our April Full Stack Faith meetup with the theme “Debugging your Faith”. At the time we did not have COVID-19 in mind… not many did. As developers, we encounter bugs every day, only they're in our code. 

But here we are, in the midst of a massive global debugging effort to bring this virus under control. Of course, the meetup is cancelled. And yes, the irony of a meetup about bugs that is ultimately cancelled by a bug, is not lost on us.

For many, this is a crisis on multiple fronts. It’s a medical crisis for those struggling to breathe. It’s a financial crisis for the newly unemployed, struggling to pay bills, awaiting for the day when work can resume. It’s an emotional crisis for all of us, as we deal with the uncertainty of these times.

Crises have a way of exposing the flaws in our faith. With a little introspection, possibly this worldwide pandemic can inspire us to vaccinate against these kind of bugs. And possibly this could be a silver lining in this all. Truth be told, it's the bugs in our faith that are the most detrimental. 

Bugs in the Code

If there’s one thing I do really well as a developer it’s my uncanny ability to write software bugs. Of course there’s nothing intentional about them, and that’s the problem. Some are byproduct of cut corners due to laziness or the urgency of tight deadlines. Some are a result of ignorance and ineptitude.

Case in point. Once, I discovered a bug that was consuming all the resources of a web server. It lay undetected for months. The server was powerful enough to mask the effects… until it wasn’t. Yes, it was my fault. Yes, I collapsed into a world of embarrassment, self doubt, and imposter syndrome. 

But then I read about this software bug.

One algorithm was supposed to figure out how to land a virtual airplane with minimal force. But the AI soon discovered that if it crashed the plane, the program would register a force so large that it would overwhelm its own memory and count it as a perfect score. So the AI crashed the plane, over and over again, presumably killing all the virtual people on board. - The Atlantic

Now, as a software developer, I don't feel so bad. It is sweet consolation that even top software engineers encounter bugs. As an airline passenger, I’m less consoled.

The takeaway here is that bugs are the byproduct of the weakness of every programmer. You can know all the right methodologies, adhere to the most efficient design patterns and use the right frameworks, and still generate bugs. Lots of bugs.

Whether you are conscious of it or not, you are programming your faith, and over time, the bugs creep in. Jesus himself described the human condition in this way,

"The spirit indeed is willing, but the flesh is weak.” - Matthew 26:41b

That’s why Jesus prefaced these words by saying, “Keep watching” That is to say, "Pay attention!", "Be on the alert!", "Be aware!", "Don’t get complacent!" There is a weakness in every heart that, when ignored, leads to the worst kind of bugs. 

The urgency for this heightened state of alertness is expanded upon with these words of Solomon to his son :

Keep your heart with all vigilance, for from it flow the springs of life. - Proverbs 4:23

The core of your being, the central processing unit, your heart, is where faith flows from, and it must be guarded with great care. Solomon puts it in terms his ancient Middle Eastern audience would understand, a fresh spring of water. It is precious. It is rare. It is only obtained after much seeking. It is easily contaminated when left unprotected.

Each of those points speak very acutely to the faith that flows from your heart. It is precious (2 Peter 1:1), it is rare (Matthew 7:14) and it is obtained through seeking (Jeremiah 29:13). But it is the ease with which your faith is vulnerable to contamination when left unprotected, that we hear the main thrust behind Solomon’s words. Out of this vulnerability, the weakness of our heart, can flow all kinds of bugs if the errors are left unhandled.

Error Handling

When writing software, all failures must be accounted for. As difficult as error handling can be, even more complicated is knowing when an error has actually occurred. At the lowest levels you must trust the input. You must trust the sensors.

Consider the Boeing 737Max for a moment. Fundamentally it has an aerodynamics problem which was ultimately overcome by software. Boeing designed a Maneuvering Characteristics Augmentation System (MCAS) that would compensate for these shortcomings, but only under certain conditions. Unfortunately, the MCAS would only

...take input from just one AoA sensor at a time. That makes MCAS completely unable to cope with a sensor malfunction. It can’t “sanity check” its data against a second sensor or switch to a backup if the original source fails. It just believes whatever data it’s given, even if that data is bad… - The Verge

And while redundancy is a cornerstone of aviation safety, this bug passed numerous rounds of approvals, signatures and stamps. This oversight was catastrophic and cost many lives when Lion Air Flight 610 and Ethiopian Airlines Flight 302 crashed, killing all aboard. Trusting in only one sensor, or a lack of redundancy, was in fact the bug. The software had no way of knowing the data was faulty.

In our faith, the Bible reminds us that the least trustworthy sensor is none other than our own heart.

The heart is deceitful above all things, and desperately sick; who can understand it? - Jeremiah 17:9

Bad Assumptions

Wait, just one minute. Didn’t we just read Solomon's admonition to guard our heart because life flows out of it? Jeremiah seems to be saying the exact opposite.

Herein lies one bad assumption. This is exactly why Jesus calls us to alertness, a serious attention to the details.

Some of the worst software bugs are the byproduct of these wrong assumptions. Whether it’s about the state of an object, the nature of the input, or the conditions of the environment. When the assumptions are wrong, software breaks.

Unexpected syntax. Error.

Unexpected input. Error.

Unexpected conditions. Error.

It’s important to realize that Jeremiah is describing the default state of the heart, Solomon is not. Paul in Romans 3, summarizes the unity of scripture on this matter when he quotes the Psalms :

None is righteous, no, not one; no one understands; no one seeks for God. All have turned aside; together they have become worthless; no one does good, not even one. - Romans 3:10b-11

The default state of the heart is deceitful (Jeremiah 17:9), unrighteous, foolish, lost, godless, worthless, and corrupted (Romans 3:10b-11).

Assuming anything different is a bug that actually leaves many hearts in the default state. The notion that life inherently flows from the heart when left to its own, only serves to leave the heart defenceless and faith non-existent or merely in self. This bad assumption is a bug that even prompts many of the faith to let down their guard, somehow convinced that there is no longer any need to defend the heart or to debug their faith.

No, Solomon and Jeremiah are of one accord. When Solomon describes how to “keep your heart with all vigilance”, he repeatedly references the very thing that gets the heart out of the default state and the sensor that is truly reliable.

An Accurate Sensor

In the default state, “self evaluation” is more akin to “self delusion” than “self enlightenment”. Therefore, there is a desperate need for accurate heart measurements. A redundant fail-safe software debugging routine that runs independently from the main thread as it were, entirely fire-walled from the corrupting influence of the heart, with robust error handling.

Solomon names such a software debugging routine. He calls it “instructions” (4:1), “insights” (4:1), “good precepts” (4:2), “teachings” (4:2), and “wisdom" (4:5). God’s Word is this very source of trustworthy heart measurements. The independent, objective, standard of His Word is the faith debugger of your heart. And it’s effective.

For the word of God is living and active, sharper than any two-edged sword, piercing to the division of soul and of spirit, of joints and of marrow, and discerning the thoughts and intentions of the heart. - Hebrews 4:12

The bugs will creep in. The key is to strategically identify them as quickly as possible, to expose them, and root them out. This is the debugging work of the Word of God.

Unit Testing

A unit is the smallest testable part of any software. It has a few inputs, and an expected output. When the input generates an unexpected output, you’ve exposed a bug. In matters of the faith, God’s Word actively tests the smallest testable parts of your faith. For example, John describes a unit test when he writes :

There is no fear in love. But perfect love drives out fear, because fear has to do with punishment. The one who fears is not made perfect in love. - 1 John 4:18

Plain and simple. If you’re struggling with fear, your faith is buggy. This is not to shame or discourage anyone who is fearful. But an encouragement to “work out your salvation with fear (the right kind of fear) and trembling” parenthesis mine. (Philippians 2:12b) When this unit test fails, it is incumbent upon us, to sound the alarm, and to further debug our heart using the “living”, “active”, “sharp”, “piercing” Word of God.

Similarly, when John says,

Do not love the world or the things in the world. If anyone loves the world, the love of the Father is not in him. - 1 John 2:15

God uses John mightily with these incredibly discreet, and piercing Unit Tests. Simply put, the more we love the world, the more we are missing out on God’s love in us. We are not abiding in His love. (John 15:9-10) We are allowing bugs in our codebase, and we should not be shocked when our joy crashes spectacularly.

We may pass these simple unit tests one day and fail the next. And this is exactly like software development. If the codebase is changing, as it always is, then the Unit Tests must be constantly run, and rerun. Anything less is borne out of pride. Paul warns us of complacency with these words :

Therefore let anyone who thinks that he stands take heed lest he fall. - 1 Corinthians 10:12

It must be said that we are not saved because we pass these Unit Tests, but rather we pass these Unit Tests because we are saved. They serve as evidence that God has changed the state of our heart from the default. And the corollary is that a failure is not indicative that we are not saved, unless it is our position that we must pass every test, in order to be saved. Paul writes to Titus to correct this bad thinking, to eradicate this bug :

He saved us, not because of works done by us in righteousness, but according to his own mercy, by the washing of regeneration and renewal of the Holy Spirit.. Titus 3:5

Object Oriented Faith

Therefore, ultimately, debugging your faith is to constantly debug where your faith is placed. What is the object of your faith?

Today, in overwhelming quantities, we are encouraged to “believe in yourself”, “you do you”, “follow your heart" and “do what’s right for you”. But there’s an absurdity in trusting the sensor that demonstrably fails most often. More-so when it has no redundant error checking. It is misguided and prone to catastrophic failure. This is echoed in the urgency of this verse :

Trust in the LORD with all your heart, and do not lean on your own understanding. - Proverbs 3:5

This is not a suggestion. This is a warning against the bug of self trust. The dangers are real.

Trusting in yourself is the classic “off by one” programming error. Jesus offers himself as the object of your faith, and when you pass up this offer, you’re off by one. The only one that matters.