The Church as Hackerspace: Breaking Computer Code

computer-coding-cat

In college around the year 2001, I took my only computer class. It wasn’t even a college class. It was a class offered by the Association of Computing Machinery (a college social/professional group of computer nerds) that taught the basics of HTML in about 5-6 hour-long classes.

That was it as far as my academic web education. Since that date, I began installing and hosting my own websites, installed a phpbb-based forum and created my own custom theme and plugins, ran websites for clients (including entire Methodist organizations), and finally designed and continue to host this website at HackingChristianity.

How did one non-academic class lead to my ability to understand PHP, CSS, HTML, XHTML, and some javascript? Simple. I broke things. And that same process, I believe, could be a parallel for how faith development will happen in the future of the Church.

Computer Coding

Via Lifehacker, I saw this blog post that outlined exactly how I taught myself all those languages and continue to learn them today: I broke the code and tried to understand why.

Now before you take a proverbial hammer to your favorite website, you should know that you can’t just break anything with reckless abandon and expect to learn something. You have to take a methodical approach and break one thing at a time, then analyze the results of your changes. When breaking things, you should be looking for the relationship between parts to understand their function in the whole.

  1. Delete one line at a time to see if it’s necessary for your goals.
  2. Delete one line at a time to better understand its function. Even if you think you know what a line does, try deleting it anyway to test your assumptions.
  3. Change variables and function arguments to see if you can manipulate them in a way that matches your mental model.
  4. Swap the order of various lines to see if things can be done “out of order” or if there’s some significance to the sequence of operations.

There’s the method. Delete one line at a time and see what changed. Or move lines around and see if the functionality is the same. Or change the variables and see what changes. Inch by inch, one can adapt current code to fit any situation and you learn it in the process.

As you test each line, you’ll start to build a mental model and make corrections to other assumptions you made previously. Soon, the whole picture will start to make sense…Reverse engineering isn’t the only way to learn and it should always be backed by more formal material whenever it’s available. In fact, I would argue that tutorials become more valuable once you have some of the context mapped for yourself. If you learn best by diving into problems head on, breaking stuff is one of the fastest paths to understanding.

Theology

I think people “learn” what they think about God the same way I learned computer coding: by trial and error. 

Few of us apply a systematic theology to the way we think about God. Few of us begin with one of the tenets of systematic theology (starting with God, or Ethics, or Humanity, or some reality) and then build our understanding of God from that central point. No, we create theologies on-the-fly: based on experience, based on bible stories, based on charismatic preachers or formative events, based on tragedies, based on successes, based on girlfriends’ influences, based on ex-husband’s diatribes. We cobble together our theologies and enlightenment is when we make these disparate thoughts make sense for a brief second.

Furthermore, I think one can do theology the same way one can learn coding: by breaking things.

Let’s take what one believes about God: God is omnipotent (can do everything) and God is omniscient (knows everything). What if you struck one of those out: God is omniscient but not omnipotent. What would you end up with? Would you recognize that God? And if you felt more comfortable with that God, you could study theologies that also reduce their conception of God’s power (such as Process Theology). By changing one tenet, you get to be more self-critical and see how the rest of the tenets relate.

In short, “breaking” our pedestrian theologies can help us become more systematic and holistic in our beliefs and understandings of God and our world. So perhaps fellow “hackers” can get something out of applying a systematic approach to their homespun cobbled-together pedestrian theologies. And in doing so, they may discover new ways to think about God or solve age-old problems. In their best forms, they reach out and gather communities of people to challenge and tinker and eliminate doctrines and restore them.

Church as Hackerspace

Perhaps the future of church is a form of hackerspace where creativity is encouraged, doctrines are challenged, heresies are debated and weighted, and spirituality is embodied and tried out.

Perhaps the future of church isn’t found in emotionally-charged and manipulative worship services where reactions are calculated; rather, they are in the experiments, the laboratories, the co-laboratories, where we co-labor together and make meaning, spiritual breakthroughs, and action plans to share our knowledge and our hopes with others. Perhaps theological hacking can be the Fourth Wave of Hackerspaces that take over emptying Sanctuaries and re-purpose neutral locations.

That would be a fascinating future of Church, wouldn’t you say?

Thoughts?

(Photo: “computer cat 01” by Steven Caddy, shared under Creative Commons share on Flickr)
Print Friendly and PDF

Comments

  1. says

    When people start learning about computers, they have a tendency to throw everything they know into their programs, just to show that they can; this usually leads to massive code bloat that does something for everyone but does nothing really well for anyone. (See, e.g., the recent Slashdot discussion of the new health-care Web site.)

    When people get much more experience, they understand what to leave out, and they write simpler and cleaner code that actually gets useful work done.

    I think there’s a theological parallel here, but I’m not quite sure what it is.

    • Kirk VanGilder says

      It’ might be akin to what is often called ‘new convert zeal.’ When someone converts to a new mode of thinking about themselves, or a new mode do doing things, be it a hobby, an identity factor, or religion, often there’s an almost hyper-membership mode. People new to something feel a need to explore and master every facet of it they can and exhibit that mastery or display their loyalty to the generally perceived tenets of their new group. After a time, they become comfortable with being who they are within this new community and recognize they don’t need to be ‘all of _________ for everyone” because the _______ community is big and diverse. This leads to one discovering their niche and being comfortable leaving ‘lines of code’ out (to use Jeremy’s theological model) yet still feeling confident in that they have the essential code to run the program.

      Areas in my own life where I’ve experience new convert zeal would include, ‘accepting Jesus Christ’ (despite having grown up in the church, there was a moment of ‘decision’ or ‘claiming’), call to ministry in the church, entry into Deaf culture and community after having grown up ‘mainstreamed.’

      In each case, I can look back and see that pattern of Discovery, Excitement, Zeal, Trying to Be and Articulate it All, and eventually, Finding my Niche and settling into confident membership in a group.

  2. says

    LOVE this. I remember the days of tinkering with the code (so many hours installing MovableType, customizing templates and plugins) & getting it *just right*, this metaphor fits so well. Thank you!

  3. Paul Anthony Preussler says

    As someone who works as a professional in the IT industry, and is a devout Christian, baptized into the Methodist church, I find this article to be deeply offensive, on several levels.

    Firstly, it is presumptuous for someone who is not a professional, whose computer skills, from his own description, are mundane at best, to attempt to draw an analogy between his own enthusiast-level computing and the work of those who have attained a sufficient level of artistry to be considered “hackers.” The majority of actual coding done even by industry legends such as Bill Joy or Eric Raymond is tedious and exacting; the clever ‘hacks’ reduce the workload, but hackers deplore programs that are ‘hacky’, that is to say, built around trivial shortcuts, almost as much as they detest software bloat. The best computer scientists are those who are able to attain a mathematical grasp on the underlying methods of computation, which can be learned through the study of works such as Donald Knuth’s The Art of Computer Programming, which is a ponderous, intense and demanding read, spread out over several volumes, comparable to works of systematic theology such as Karl Barth’s Church Dogmatics, Kallistos Ware’s The Orthodox Church, and the Summa Theologica of Thomas Aquinas.

    That said, within computing, learning by trial and error does have its place, but only when accompanied by, and in concert with, the great intellectual works of the discipline in question, the canon of computer science, as it were. Without that material, one’s quest for knowledge will be fruitless. You cannot simply sit down at any computer and begin to write your own programs; you must have enough knowledge to setup your development environment, and to understand the different tools and their operation, such as the text editor, the compiler/interpreter, and the debugger and related diagnostic programs. In actually doing this, one will come to understand the reason why trial and error works well in computer science: because with computers, unlike with most fields, empirical knowledge of the results of one’s work is available rapidly, in many cases instantly. This was not always the case; early programmers working with punch cards had to wait hours for the results of their program, which in many cases could only run at great expense; consequently, a mastery of the underlying theory was a prerequisite to actual operation. A minor bug could be catastrophically expensive both in monetary cost and wasted time. Even now, software engineers, that is to say, programmers who are also licensed engineers, who produce software for embedded systems in safety-critical applications in heavily regulated industries such as health care and avionics, must be able to mathematically prove the operation of their work. In recent years, poor software engineering in SCADA systems resulted in the successful implementation of the Stuxnet cyberweapon; an attack on control systems for devices like pacemakers might prove deadly in the years to come, and it is for this reason that the USAF and other armed forces around the world are devoting substantial portions of their budgets to the defense of mission-critical networks.

    Thus, even in computers, where learning by trial and error is easier than in virtually any other profession, due to the rapid availability of hard, factual knowledge, mastery of the canon of intellectual knowledge is essential, especially for safety critical applications, in order to defend against subtle bugs that only manifest themselves in certain edge cases, yet can result in death. This kind of empirical evidence becomes extremely scarce in the soft sciences, like economics and psychology, and disappears altogether in disciplines such as theology. John 1:18 tells us that “No man hath seen God at any time; the only begotten Son, which is in the bosom of the Father, he hath declared him.” Empirical knowledge regarding God is, on a scientific level, unobtainable. Thus, we can conclude the following three points: firstly, trial and error programming is beneficial, but primarily by virtue of the ease by which empirical evidence can be obtained, secondly, for safety-critical applications, deep theoretical knowledge is also imperative, so that programs can be mathematically proven before field deployment, and thirdly, with theology, the kind of empirical data that makes the trial-and-error method used by programmers work is simply unavailable.

    Now, let us, in the spirit of the ‘commenting out one line at a time’ trial and error approach much lauded by the author, suppose for a moment, that empirical knowledge about God enabling trial-and-error theology to work was readily available. Would such be appropriate for ecclesiastical use? Could the church function as a hackerspace? No, for the simple reason that the church is, by nature, a safety-critical environment. The function of the church is firstly, the celebration of the sacraments, chiefly, the Eucharist, secondly, prayer, and thirdly, the spiritual and moral edification of the believers through catechesis and the liturgy (including the Bible readings and the homily). The mission of the church, as John Wesley would have understood it, is the cure of souls. It is to this end that rectors, vicars and curates are appointed in the Church of England, of which John Wesley was a curate, and from which what became the Methodist Episcopal Church was reluctantly separated only as a terrible consequence of the Revolutionary War. This mission, which has as its objectives ensuring the moral and ethical behavior of parishioners, and more importantly, of facilitating their salvation in Christ, is the most safety-critical task conducted anywhere on Earth. Even if God were immanently accessible, and the experience of prayer was akin to interactive, or even batch-mode, computing, the theoretical knowledge required for safety-critical applications would still be expected of clergy. A collegial environment, like that of a hackerspace, might be present in seminaries, in such a world, but not in parish churches.

    Given the lack of empirical data, however, the importance of theoretical knowledge in Christian theology is even more important. There are two sources of data acceptable for use in Christianity, the holy Scriptures and Church Tradition, the former of which is unchanging, and the latter of which progresses only very slowly, to the extent that anyone who attempts to deliberately affect a change in their lifetime more often than not finds themselves ex communicated and branded a heretic (see Arius and Nestorius). John Wesley understood this, which is why he fastidiously adhered to the doctrine of the Church of England, and worked primarily to make the presence of the Church more ubiquitous, a fact that has been, and should be the goal of any Christian evangelist, starting with the Apostles. Perish the thought that the church should cease to be understood as a eucharistic community, as a place and time for the intersection of the human and divine, where one, in the words of the deputy of Vladimir who visited the Hagia Sophia during the service of the divine liturgy, one could not tell whether one is in Heaven or on the Earth, to the mundane, worldly environment of a hackerspace. As delightful as hackerspaces are for those who are professionals or enthusiasts in the world of computers and related emerging technology (such as 3D printers), it would be appalling to see the Christian church reduced to nothing more than a glorified Linux user’s group. Fortunately, it will also not happen, at least not on a large scale, because anyone who attempts it will simply cause a schism, which will increase the patronage of more traditional denominations. It is worth remembering that the United Methodist Church is experiencing a decline in membership in the United States, and an increase in membership in Africa, where the clergy is much more sober and traditional, and meanwhile, increasing numbers of younger Christians are expressing a preference for a more liturgical, solemn Christianity (hence the increase in membership being experienced by some Catholic and Eastern Orthodox churches).

    • says

      Paul, thanks for your substantive post. It is difficult to address all of your points in a single comment, but I did want to reply on a few things.

      1. Hacking is a term that is broader than applicable solely to computer professionals who have incredible mastery over particular systems. With the rise of “life-hacking” and making thoughtful tweaks to your everyday life, hacking has a broader term than merely endeavors by professionals. So while your clear knowledge and expertise in the computer realm is clearly a worthy argument, it is not definitive of the field. Given that the predominant number of life-hackers are not computer professionals, in fact, your experience may be less shared by the field than you might think. I understand the offense that may be felt, but it is not a universal experience of people who consider themselves “hackers.”

      2. The approach suggested a way to bring a systematic approach to a pedestrian theology. Unlike computer programs where we start with a systematic and expand it or rework it, humans do not do that with their understandings of God. Due to the lack of empirical data (which you pointed out) available about God, the necessity of a piecemeal amalgamation of theologies is more rampant. The approach above attempts to reign in the piecemeal approach by applying a systematic approach: changing one thing at a time and see what image of God you end up with. It’s not empirical, it’s not replicable, it won’t turn into a movement, but it can lead to personal discovery.

      3. Finally, I really disagree that the church is an environment dependent on professionals who provide systematic care of the priestly aspects of the church. The entire ethos of the Methodist movement historically is dependent on laity who would hold one another accountable in love, collect the penny tithes, run the church while the professionals were on horseback. It took the church 100 years to give laity the right to vote, yes, but no one would doubt that the laity have much more power in the UMC than in the RCC or the TEC. While this blog celebrates theological education and is critical of the move towards part time pastors who are not religious professionals, they are not the core of the church. Nor can laity mold themselves to the religious professionals because we move them around in our itinerant system. So I would claim that the Methodist system is the closest to a hackerspace of many other denominations, and indeed I celebrate that.

  4. Paul Anthony Preussler says

    In response to your first point regarding life hackers, I would propose that the technological theme this blog has is reflective of the debt owed by so-called “life hackers” to the real hackers, people like Eric S. Raymond, Ken Thompson and Bill Joy. Hacker culture developed as a counter-cultural movement among computer science students at MIT beginning in the late 1960s, and then spread across the embryonic Internet to other network-connected CS departments over the course of the next decade, and became associated with the UNIX operating system, and in the 1980s these hackers entered into the commercial space. The Free Software movement, starting with Richard M. Stallman, continued the development of “Hacker culture”, and from this, open source emerged, and from that community, the first “life hackers” arose. However, for those who actually are hackers, the use of the term “hacker” by someone who is not accepted as a member of the hacker community by other accepted hackers is considered to be indicative of a “lamer”, that is to say, of a mundane individual who lacks the “hacker nature”. Hacker culture is inherently elitist, and the values of hacker culture are probably not compatible with Christianity as such, which is why among hackers such as ESR alternative religions (Wicca, Neo-Paganism, Setianism) and parody religions (The Church of the SubGenius). Life hacking, in that it represents a development of the hacking approach to lifestyles, inherently owes a huge debt to hacker culture, but the real hackers will always view life hackers who are not actual hackers with derision. This also should call into question the desirability of importing any aspects even remotely connected with Hacker culture into Christianity; having worked with hackers, and experienced the soul-crushing effects of modern Geek culture at its worst, I would propose that a better course of action would be to evangelize Christianity into Hacker culture, but this cannot be done in any way that glamorizes or idealizes the values of Hacker culture itself, because these essential values are not compatible with the Christian faith as understood biblically or through church tradition.

    Now, on your second point, first of all, computer programs do not “start with a systematic and expand it or rework it”. Rather, a computer program executes instructions, which may or may not transform input into output, depending on the purpose of the program (in functional programming, all functions that produce side-effects, which ultimately includes all input/output functionality, are viewed as “unclean” and are isolated from the rest of the “pure” program, for example). In any case, the output is immediately available, and this facilitates the iterative development methodology, or to be more blunt, trial-and-error. The primary output of Christian faith however is not available until after death; though we do receive grace in this lifetime, the Christian is also exposed to enormous pain, in many cases far more pain than would be expected of one pursuing a secular existence, as Ignatius of Antioch could attest. In addition, we cannot deny that other religions are equally capable of promulgating morality or generating a sense of spiritual fulfillment in this life. Thus, if we are to be true to the Christian faith as received by John Wesley, any kind of output-driven theology, such as that resting on personal revelation, should be seen as dangerous, and possibly leading to soul-destroying delusion. The Eastern Orthodox Church, into which it is probable that John Wesley was secretly ordained a bishop in 1763, in particular stresses the extreme danger of prelest, or spiritual delusion, and their aversion to it has been fruitful, in that the devastating schisms and spiritual abuses (such as the sale of indulgences) that have torn apart Western Christianity since 1054 have not occurred in the East.

    This takes us to your third point. Prior to its merger with the Evangelical United Brethren, which was also a superb church that probably would have been better off remaining on its own, the Methodist Episcopal Church was a bastion of theological and ecclesiological stability. There were occasional tensions, sometimes even dramatic, but nothing on the scale of the internal strife in the Church of England between the Low Church and Anglo Catholic factions, the fractious and permanent disintegration of the Baptist communion in North America, or the feuds and schisms in the various North American Lutheran synods. The 1962 Methodist Episcopal Book of Worship contains the rubrics for John Wesley’s original Sunday Service, and those for 1962 Methodist worship services, and the lack of variation between the old and the new is striking; a minister in that era could have switched back and forth between the two without attracting much attention. While it is certainly true that from the beginning, the Methodist movement actively depended on the laity in a manner that far exceeded what was seen in many other contemporary denominations, this lay involvement did not entail a communal participation in the process of theological development. Rather, what facilitated the active lay ministry which characterized the original Methodist Associations in England and the Colonies (the latter of which were forced to assume the role of parish churches after the Church of England stopped appointing clergy for the United States in 1783) was facilitated through the theological consensus that existed throughout. The essential Christian faith, as the Church of England understood it, was uniformly and consistently taught by the Methodists, who in England did not patronize non-conforming meeting houses, but were rather directed by Wesley to receive the Sacraments from Anglican clergy during normal Sunday services. Granted, there was some leeway in the Latitudinarian C of E in the 18th century, which allowed Wesley and George Whitefield to famously “Agree to disagree” on the question of Armininianism vs. Calvinism, but on the essential doctrines, as enumerated by the Articles of Religion and the Nicene Creed, there was complete consensus. This consensus allowed laity to evangelize effectively, as their task was to simply proclaim the doctrines that they had been taught; the kind of dogmatic experimentation you suggest did not occur, and had it occurred, it would certainly have been immediately suppressed, with the approval of Wesley himself.

    I am not calling for the restriction of Methodist ministry to seminary-educated, ordained clergy, since having an M.Div and an ordination does not guarantee the transmission of orthodox Christian doctrine (as the recent experience of the Episcopal Church USA demonstrates). Rather, I am calling for Methodist laity, and most especially Methodist Clergy, to understand their role not as being “life-hackers” but rather as the guardians of sacred tradition. The historic faith we have been entrusted with, which is manifested in Holy Scripture, the Articles of Religion, the theological determinations of the Ecumenical Councils, the Nicene and Apostolic Creeds, and the liturgy (both the Rubrics, which originate in the Anglican liturgy, albeit with some simplification by Wesley’s hand, and the Hymnals; Methodism has benefited from a particularly rich hymnography worthy of Ephrem the Syrian), is a priceless treasure, and should not be trivialized; neither should it be disassembled and reassembled according to the Hacker ethic as if it were a glorified bash script. The laity are a particularly important part of maintaining this church tradition, even laymen who do not serve as lay ministers (who are now regrettably referred to via the demeaning moniker of “lay servant”); if anything is responsible for the relative preservation of orthodoxy within Methodism compared to the other mainline denominations, it is the involvement of the laity, particularly those in Africa, who act as a stabilizing counterweight to the disruptive elements that dominate some parts of the American connexion.

    Finally, I can assure you, as someone who is not frequently at hackerspaces, that the only part of a Methodist church that approximates one might be the Sunday School classroom, albeit not in a theological way. In an actual hackerspace, those present are generally concerned with making something, and the experience is not unlike that of Sunday school students in drawing theologically themed pictures or engaging in other crafts projects, however, unfortunately, the hackerspace is often at times a very adult world far divorced from the brightness and altruism of the Sunday school classroom. For an adult however in pursuit of the intersection of humanity and divinity available through worship, neither environment is likely to bring a sense of spiritual fullness. Of course, the immanent experience of the divine is only half of the equation, as I pointed out before; other religions can do this as well, and so can heretical branches of Christianity (I have no doubt that members of the Ecclesia Gnostica benefit from enormous spiritual fulfillment). This is why the preservation of doctrinal integrity is vital; we cannot help but do a terrible disservice, perhaps the greatest disservice possible, to the laity, by neglecting the traditional Christian faith, since it is not merely their life, but their mortal soul that is at stake. A pastor holds the most safety-critical profession, as a software engineer can, through negligence or incompetence, only kill you in the present, but, according to the traditional understanding of the Christian faith, an incompetent, negligent or malicious pastor can lead you to eternal damnation. This last bit, not unlike John 6:53-58, is a difficult pill to swallow; for those unable to face it, the Unitarian Universalist Church beckons (perhaps in a manner not entirely unlike that of an open sepulchre). The Syriac Orthodox sing a rather nice hymn in their variant of the Divine Liturgy of St. James the Just, that concludes with “Behold, there springs up different teachings from all parts. Blessed is He who begins and ends in God’s teaching”. I have no doubt that John Wesley would agree with it.

  5. Paul Anthony Preussler says

    By the way, I should add that the lay involvement in Methodism, and conciliar nature of Eastern Orthodoxy, act as barriers to dangerous, rapid change which can cause schism. The Roman pontiff can, with the stroke of a pen, effect sweeping changes to Roman Catholic doctrine, which can lead to disastrous results; the liturgical innovation following Vatican II gave us the SSPX, which has successfully turned religious intolerance into a glamorous luxury brand. Thus, any changes, even relatively minor changes, run the potential for schism; in hacking, changes occur so frequently that most serious projects (even those related to “Life Hacking”) involve the use of change management systems of some sort such as Git. When one considers the enormous impact an ill-advised or enforced change can have on the faithful, by creating dissension or schisms, and beyond that, the potential impact on the spiritual health and future of the parishioners, the thought of introducing that level of dynamism into the Ecclesiastical sphere should be enough to terrify anyone. A Church that attempted to becoming a hackerspace would instantly lose at least half of its elderly parishioners, and would also alienate the numerous younger Christians who actively embrace liturgy and reject the open-plan Calvary Chapel style of worship (even you yourself show some inclination in this direction, as your recent post on church architecture demonstrates); the remaining parishioners would find themselves in a state of spiritual flux, and would eventually become desensitized to change itself. Given that, I would estimate that within decades, the church would most likely cease to be Christian; this happened to the Universalists and it can happen in the Methodist church if we compromise dogmatic stability.

Leave a Reply

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

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>