Recursion and Other Computer Science Terms that Apply to Life

By Dr. Tresia Eaves
October 15, 2026

Before the Bots Came

We knew decades ago that Artificial Intelligence (AI) would be here to help us. As a brand-new Computer Science freshman at Baylor University, in the late 80s, recursion was a term that I learned early on. Even the Computer Science department was brand new in Baylor. Originally, it was a department in the College of Engineering as no one quite knew where to put it. Because of this, we got more of the Computer Engineering curriculum thrown in for good measure. I was grateful for this, although, admittedly, it took several years for me to appreciate this fact as I began to understand I knew more about the hardware functionality of computers than most computer scientists. It was also a great thing because the software would change rapidly over the next few decades, but the hardware would move slower…at first.

I remember a book we read as seniors called “Decline and Fall of the American Programmer” by Edward Yourdon, 1992, as he explored the impacts of off-shoring (he called this the “onset of off-shore software factories” where labor was cheaper and the skills were equitable to American workers, tools that will reuse and restructure their own code (this could have been his premonition of AI), and the economic impacts of these changes to the American market. I was pretty concerned about my career aspirations considering this read but turns out, I would get to enjoy a long and storied career before the bots came for my job.

Recursion: Remember Your Roots

We could stand to use “recursion” more in our own lives. Calling on ourselves through self-reflection to learn from the lessons of the past. I’ve learned some lessons the hard way but others, I’ve been able to learn by recursion or learning from the mistakes I’ve seen others make. Recursion could also be used to describe remembering your roots. One of my greatest mentors could see some headiness starting to get the best of me in the middle of my career. He reminded me gently by saying, “Don’t get caught up in your own marketing.” That really stuck with me. It was a way to say hey, remember where you come from and don’t get a big head. I often saw people around me getting promoted and making lots of money who suddenly thought they were their own marketing. I also saw what happened next and it usually involved them thinking they were above the laws or everyone else and this usually preceded a painful, humiliating fall from grace.

LIFO: Last In, First Out

Another helpful computer science term: last in, first out, or LIFO. In computer science, this term refers to a data structure where the last bit of data is the first taken out of a database. It increases speed as it is much easier to pull out the last item put in rather than reviewing a bazillion records to find that special one you want. Guess what? This applies to life too – who is usually the first to go in a layoff? LIFO. What is the first activity you give up when you have found you are overloaded? LIFO.

Garbage Collection: Clear the Clutter

Garbage collection is another concept worth borrowing from the programmer’s toolkit. In computing, garbage collection is the automatic process of reclaiming memory that is no longer in use, so a system does not bog down and eventually crash under its own clutter. We need the same discipline in our personal and professional lives. Grudges, outdated assumptions, toxic relationships, and commitments that no longer serve a purpose are the “memory leaks” of our mental operating system. Without periodic garbage collection a deliberate pause to release what is no longer needed we slow down, we get sluggish, and eventually we crash. The healthiest people and organizations I have known are the ones who routinely clean house, whether that’s old projects, limiting beliefs, or relationships that have run their course.

Technical Debt: Pay Now or Pay Later

Technical debt is a term coined to describe the implied cost of additional rework caused by choosing an easy, limited solution now instead of a better approach that would take longer. Every quick fix you ship today is a loan against your future self, and like any loan, it accrues interest. I have watched entire engineering teams grind to a halt because nobody wanted to pay down the debt until it was crushing. Life works the same way. Skipping the hard conversation, procrastinating on the difficult decision, or taking the shortcut in a relationship all rack up a kind of personal technical debt. Eventually, the interest payments in stress, broken trust, or missed opportunity come due, usually at the worst possible time. The best engineers I worked with built in time to refactor; the best people I have known build in time for honest reflection and course correction for the same reason.

Fault Tolerance: Built to Bend

Fault tolerance describes a system’s ability to continue operating properly even when one or more of its components fail. Well-designed systems do not assume perfection; they assume failure is inevitable and build in redundancy, graceful degradation, and recovery paths. I think the most resilient people I have worked with and mentored operate the same way. They do not expect flawless execution from themselves or others. They build backup plans, they expect setbacks, and when something breaks a deal falls through, a key employee leaves, a plan goes sideways they have already architected a way to keep moving instead of grinding to a halt. Brittle systems, like brittle people, shatter under the first real pressure. Fault-tolerant one’s bend and keep running.

Race Conditions: Who Owns What?

Race conditions occur when two or more processes try to access or change shared data at the same time, and the outcome depends on the unpredictable timing of events, often producing bugs that are maddening to track down. I have seen the human version of this in teams and families alike: two people (or departments) racing toward the same decision without properly communicating, each assuming they have sole control, and the result is confusion, duplicated effort, or outright conflict. The lesson from computer science is the same lesson for life — build in proper synchronization. Communicate clearly about who owns what, when, and how, or you will end up with the organizational equivalent of corrupted data: mixed signals, stepped-on toes, and decisions nobody actually agreed to.

The Halting Problem: Not Everything Has an End Date

Finally, there is the halting problem, Alan Turing’s famous proof that no general algorithm can determine, for every possible program and input, whether that program will ever finish running or continue forever. It is a humbling reminder that not every process in life has a guaranteed, knowable endpoint. We want certainty about when a difficult season will end, when a project will wrap up, when grief will subside, but some things simply cannot be computed in advance. The maturity, I think, is in accepting that uncertainty rather than endlessly looping on the question of “when will this be over,” and instead focusing on the next right instruction in the program.

Built in Our Own Image

Looking back at thirty-plus years in this field, I am struck by how much the vocabulary built to describe machines turned out to describe us just as well. Maybe that’s because we built those machines in our own image: logical, fallible, prone to breaking down, but also capable of being debugged, refactored, and improved with each pass. The bots may be coming for plenty of jobs now in ways Yourdon only glimpsed back in 1992, but the deeper lessons recursion, LIFO, garbage collection, technical debt, fault tolerance, and the rest taught me are not going anywhere. If anything, they are more relevant now than when I first encountered them as a wide-eyed freshman in a brand-new department nobody knew quite what to do with.