Code your Ministry until you can Program it


…one thing does irritate me: the persistent misuse of the word “programming” when the author means coding. Programming is creating the logic, coding is translating that logic into code. Many students come into class able to code, but almost none come in able to program–that is, create the logic. They think sitting down & making spaghetti code is programming.

Tom Fordham

In a now-deleted (but still in my feedreader) post, Jonah Bitautas includes the above quote when discussing the difference between programmers and coders. Programmers are those that take the idea and make the plans for the house, whereas coders are the ones who consult the plans and put up the sheetrock, paint, lay tile, and finish the work to perfection.

I think this articulation is helpful when describing clergy at the early years of their ministries. While there are a number of visionary pastors who likely were programmers at the onset, the reality is that I think many pastors are coders who become programmers, not the other way around.

When I was appointed to my first church, a wise retired pastor gave me a framework for what he experienced ministry to look like:

  • Year 1: I would do what the previous pastor had done, with incremental variations.
  • Year 2: I wold undo some of the things the previous pastor had done and put my own ministries into place.
  • Year 3-5: I would become effective in ministry and sometime in these three years, I will be moved to restart this process in a new church.

In other words, I would spend my first year coding (working within another’s framework) and would transition to programming (building my own framework) when I got to my 3rd-5th years.

I would say it matches my experience, but I would add a second element: these stages become shorter and shorter at each new church.

  • I began my first parish as a coder, trying to get into the rhythm of preaching weekly (and leading the Eucharist weekly). I learned the lines of code and, using the framework of the pastor before me, I made my own code within the framework given to me. I didn’t do many variations during my three years while trying to get the hang of everything at once.
  • I went to my second parish and about half the first year I was a coder, but right before Christmas the pastoral staff hit into some serious programming modes and got our lay leadership to start some seriously awesome programs, helped guide the church through a capital campaign and building project. We laid the groundwork for a childrens/youth ministry that would still be rockin’ two pastors after I left.
  • And a funny thing happened in my third parish: the coding section was only about 2 months. I arrived right as the congregation was completing a Strategic Plan for the next three years, so they were already doing the programming and invited me to join them. When the Plan was finalized two months into my first year, there was no coding to be done: it was programming the five points or bust!

I would say this is likely the experience of many pastors. And in churches with connectional polity like the United Methodist Church (meaning they assign their clergy to parishes), pastors are given the opportunity to switch from coding to programming much quicker than if they stayed at their first parish a long time.

One word of warning: The key error message is switching from coding to programming too quickly. I moved from the South (the land of Big Shiny Churches) to the Northwest (the land of Small/Medium Churches). One of the concerns that was expressed to me early on was “be sure to not wear your Bible Belt until you’ve tried on our belts first.” In other words, the methods and priorities of the Bible Belt that I grew up in may not apply directly to the Northwest. Jonah Bitautas makes the similar point at the end of his coding:programming post:

Whatever method you use as a programmer, it should always be consciously chosen for the individual solution. There are no boxed formulas, patterns, ideologies, etc. that will be the be all, end all of programming.

Finally, this metaphor seems to be like the advice given to John Wesley: “Preach faith until you have it.” In the 21st century, perhaps it is better written “Code your ministry until you can program it.” Do the acts of faith and ministry until you can see the logic and discipleship process that define how you interface with the Spirit. Do the spiritual practices until they become part of your logic, workflow, and you can replicate the practices with others. Then program that faith, expand beyond yourself to see how it interfaces with the rest of reality (seeking justice, loving kindness, acts of mercy towards your neighbor) and your spiritual life and life of ministry will be effective indeed.

Code your ministry until you can program it.


Print Friendly and PDF


  1. says

    Keen insights here. As a second career UM pastor in his third full-time year in the same church, I recognize the pattern you describe, especially since my first career was in IT.

    I think it’s important for pastors to be conscious of this kind of pattern instead of a vague consciousness of the “honeymoon” stage, the “getting to know people” stage, and then the “settled in” stage. Those “stages” and terminology are pastor-centric. The pattern you describe here is more church (as a system)-centric. I’d like to think pastors and parishioners can become more self-aware of our development and (changing) roles of working together as we move along in ministry together. Self-awareness and talking openly about our (changing) roles lead to healthier ways of “programming” the church than unconscious reliance on some pattern that may have existed for decades.

    It would be a great thing, when a new pastor is appointed, for the UMC to have some kind of positive framework for local church leadership to work through with the new pastor to openly discuss expectations, established patterns, and mutually agreed upon methods to alter expectations and patterns to suit the direction of ministry in which the local church wants to go.

  2. Rev. Mark Whitley says

    To my way of thinking, coding/programming is just one metaphor. There are others. Coming out of a 26-year career in health care, I long ago realized my primary metaphors as an itinerating clergy person were diagnose/treat or diagnose/heal.

    A former contractor turned pastor might use measure/build.

    Regardless of the metaphor, at its root these are all just ways of saying analyze/solve, study/act, serve/lead, or maybe the simplest of all, be/do.

    As I am discovering, and in not all together pain-free ways, the metaphor is not nearly as important as is the wisdom needed to know when and how and with whom to begin making the shift from the code-diagnose-measure-analyze-study-serve-be side to the program-treat-build-solve-act-lead-do side.

    What I can say with some certainty is that after this first go at being a senior pastor I expect to have more wisdom and patience whenever my second go at being a senior pastor comes along!

    I gave a ten minute mea culpa to my church on Sunday for my lack of wisdom and patience this first time at this whole church leading gig.

    Neither seminary nor our extended candidacy process prepared me adequately for the realities of actual and effective church leadership.

    Not like leading in situ does.

    Only time will tell whether I truly measure up as an effective church leader, meanwhile, the jury remains deadlocked!

    I just don’t want to be the kind of pastor who is more defined by “doing no harm” than by “doing all the good you can and staying in love with God.”

    I hope to be the latter rather than the former.

    May it be so.

  3. says

    I appreciate Mark’s comment which broadens the view. As a former missionary, I followed a similar path when stepping into the pastorate, however in my mind I was listening to the (local church) culture, engaging the culture, & changing the culture.

    Thanks for your post Jeremy.

  4. says

    Hipmunk differentiates from the run-of-the-mill flight
    search applications by predicting how painful your traveling
    might be. But here we need to understand that though Google do not reject
    your apps, it’s not easy to make apps in Android SDK and just launch it,
    and same applies to Android Game Development. Perform smashing serves and shots to take out your opponents in this teensy sports simulation.

Leave a Reply

Your email address will not be published. Required fields are marked *