Repentance and Refactoring

Nothing to be proud of

I had a disturbing realisation the other day when I was asked to put together a code sample for a job application – I can’t think of a single piece of code I’ve written that I’m actually proud of. In fact, even ‘proud of’ is probably setting the bar a bit high – I can’t really think of many things I’ve written that I wouldn’t be ashamed of showing to a potential employer.

Now that, in itself, doesn’t actually worry me too much. In the context of applying for a job, I could talk at length about what’s wrong with how I’ve coded things and how I’d do it differently were I to start again – that kind of stuff actually makes for quite a good interview. I suspect that a large part of the reason I have so little code to be proud of at this stage in my professional development is simply that most of the things I’m programming I’m doing for the very first time – the first compiler you write, for instance, is bound to be a hopeless mess, because it’s often only in the coding of it that you figure out what on earth you’re doing. What’s more, as I learn the right way to code these things, my tolerance for ugly code diminishes – I often find myself flinching at little idioms I used to use with such abandon. It’s even been said that the very thing that distinguishes amateur coders from professionals is realising that everything you write sucks!

So the existence of shameful code doesn’t cause me to despair. Of more interest to me, and what this article is all about, is this: given my past experiences, why am I always so confident that my next piece of code will be different? What is it that means I’m always so blind to the probability that what I’m working on right now will prove to be equally ropey once I reach the end of it? It seems to me that it’s in the nature of computer programming that everything you ever write makes you learn something new. The result is that you’re constantly raising your standards and never completely happy with your previous coding efforts. Yet my heart seems to be several steps behind my head in realising this.

Refactoring your technical debt

In most programming projects, this constant growth means that you’re always left with something of a technical debt: pieces of code that could do with some attention to make them easier to understand, easier to test, easier to modify, and so on. It’s that piece of code in your most recent project that you know wasn’t quite “clean” enough for your liking, but which you didn’t have the time or energy to sort out at the time. You can usually get away with ignoring your technical debt in the short term – generally it doesn’t actually mean anything is broken, functionally speaking – but the cruft tends to accumulate and if you don’t give those areas of the code the attention they need, eventually it can lead to real problems.

People who are blindly optimistic about their abilities, like I seem to be, are likely to be content with the classic Waterfall Model of software development. This is the approach that assumes everything will go exactly according to plan – that everything will be perfectly designed in all its fullness, then perfectly implemented with no architectural flaws whatsoever, before being released to perfectly happy customers who are receiving everything they hoped for. Thankfully, most people these days seem to be realising that pretending this works doesn’t actually get you anywhere. Instead they’re embracing agile methodologies like Extreme Programming which are built upon an explicit acceptance of our human weaknesses – imperfectly knowledge, imperfect requirements, imperfect decisions – an assumption that happens to synthesise very happily with a Christian worldview that is only too aware of our sinful nature. One of their key tenets is the idea of Constant Refactoring. If you haven’t come across the term before, “Refactoring” describes the process of modifying the internal structure of your code and tidying up interfaces and so on, but without changing the observable behaviour. It’s about paying off your technical debt, little by little, until you have a code base you can be proud of. Agile methodologies embrace refactoring, because they know you’ll need to do it – they know you won’t be satisfied with the way you coded it the first time around, or even the second or the third. Of course, refactoring has to go hand in hand with repentance – a commitment to turn from your evil ways as a cowboy coder and start putting into practice all that you’re learning. Refactoring without repentance is a pointless exercise, since the chances are you’re just replacing one technical debt with another.

Refactoring the Christian life

But if it’s in the nature of computer programming that constant growth means you’re never completely happy with your previous coding efforts, how much more is this true of the Christian life? How often do you find yourself cruising along, thinking everything’s fine spiritually, only to look back on the last few weeks and notice some massive area of ungodliness that you’d overlooked: maybe some action of yours that really hurt someone without you even realising it, or maybe some persistent behaviour that you later realise has been a dreadful witness to your non-Christian friends. It’s part and parcel of the Christian life, for as Jim Packer says in “A Passion For Holiness“, growing up as a Christian is really all about growing down – that as we grow we “end up seeing ourselves as less – less nice, less able, less wise, less good, less strong, less steady, less committed, less of a piece – than ever we thought we were. We stop kidding ourselves that we are persons of great importance to the world and to God. We settle for being insignificant and dispensable”.

As God sanctifies us and conforms us bit by bit to the image of his son, we find our consciences flinching at things that previously never bothered us. Our tolerance for sin in our lives should always be less than it used to be – so long as it continues to be greater than God’s. As in programming, repentance is a way of life for the Christian, not something that you do once when you first decide to follow Jesus. The difference, however, lies in how we must deal with our past failings. For whereas bad programming leaves us with a technical debt that I can solve myself with a bit of refactoring, bad living leads to a spiritual debt that nothing short of death can pay for. Writing bad code has no legal ramifications
– although I’ve previously argued that there is a Christian imperative to write the best code we can out of love for our co-workers and our employers, I’ve not broken any laws by writing bad code. I don’t face a jail sentence or a hefty fine. But bad living, on the other hand, is a legal matter. Rejecting God’s rightful rule over my life and choosing my own path is tantamount to treason, and carries a penalty that I have no hope of paying myself. It takes the death of Jesus in my place as a substitute to set me free. For a proud programmer like me, becoming a Christian is an act of the utmost humility, as you admit to God that you are unable to offer anything towards your salvation, and that only the death of his son Jesus can pay off your debt. As Romans 6:23 puts it, “the wages of sin of death, but the free gift of God is
eternal life in Christ Jesus our Lord”.

Thank God for the ultimate software architect, the Lord Jesus, who refactors my ugly past, pays off my spiritual debt and cleans up the rope in my life so that I can get on with daily repentance as I seek to follow in his footsteps.

Programming Under the Lordship of Christ

Yet another coding blog?

When I relaunched geero.net a month or so ago, I did it under the slightly ambiguous subtitle of “Christian software development”. It’s true that I planned to talk about software which is explicitly Christian, particularly centring around my Bible-teaching computer games, but it is also my intention to talk about issues that affect Christians who are involved in software development, both professionally and as a hobby. But there are loads of brilliant programming resources out there written by people far smarter than me. So why does the internet need yet another coding blog, and why would I be arrogant enough to think that I can contribute anything unique? In fact, isn’t it a bit weird to a have a blog devoted to Christian software development in the first place? Isn’t being a programmer completely orthogonal to being a Christian?

Whilst the connection may not seem apparent at first glance, I think that being a Christian actually has quite a significant impact upon your computer programming. The Bible says that Jesus is interested in the everyday details of our lives, including our coding – and not just what we code, either, but the nitty gritty of how we code it. If he is the source of all our gifts and abilities, then it makes sense that he would be concerned with how we use those gifts, and it brings him glory when we use them well. To paraphrase Colossians 3:17, “whatever you do, in word or code, do everything in the name of the Lord Jesus, giving thanks to God the Father through him.”

One of the big themes of the New Testament is Jesus as King- the ruler of everyone and everything. As Abraham Kuyper once famously said, “There is not a square inch in the whole domain of our human existence over which Christ, who is Sovereign over all, does not cry: ‘Mine!'”. Nothing is outside of his rule, including our work and our coding. So what will it look like for us to bring our programming under the Lordship of Christ? It seems to me that there’s plenty of space for a blog that helps us think that through – I know I’ll certainly benefit from writing it!

Conduct in the Workplace

It seems obvious, but first and foremost, Christian programmers are Christians. That means that 99% of living under the lordship of Christ is exactly the same as if we were lawyers or secretaries or school teachers or acrobats. We’re called to be salt and light in the world, being a good witness to those around us, graciously speaking of Jesus when we can and commending him with our lives and our work. When speaking to slaves performing the most menial of tasks, Paul writes this:

“Whatever you do, work heartily, as for the Lord and not for men, knowing that from the Lord you will receive the inheritance as your reward. You are serving the Lord Christ” (Colossians 3:23-24)

It can be tremendously encouraging to know that Jesus cares about our work! Whether we’re professional programmers doing it for a living, or just a hobbyist hacking something together in our spare time, we’re to imagine Jesus as our real boss, calling the shots. We’re to work heartily,
putting all of our effort into it, and not just when our manager is looking over our shoulder (“not by way of eye-service as people pleasers”).

This is an area where I constantly find myself falling short. It’s so easy to slack off and start browsing the net when nobody’s looking, or to start grumbling if we seem to be going through a phase full of bugfixing and maintenance instead of any exciting new development. But this can be a terrible witness – especially since grumbling is like gangrene and is so quick to spread amongst a team, with disastrous effects on morale (incidentally, if you do find yourself wading through a month full of boring bug fixes, it may be an indicator that the code you wrote last month was a load of old rope – bear it in mind!)

Writing Quality Code

As a general rule, programming under the Lordship of Christ is going to mean doing the best job we can. Even when you’re programming for fun, it still glorifies God when you make good use of the gifts he’s given you, honing your skills. When you’re doing it professionally, however, it’s absolutely vital to your witness to be writing good code. Bad code is a headache for everybody who has to maintain it, so you can really serve your colleagues by writing code that’s easy for them to understand and change, with
good comments and unit tests, and so on. Even if you’re on a team of one, you can still show consideration for the poor soul who’ll have to maintain your code once you’re gone!

But as in most fields, quality doesn’t just happen by accident. So how do we learn how to write good code? Firstly, I’d say that if you’re not in the habit of reading programming blogs (in your lunch hour, of course!) then I’d highly recommend adding a few to your favourite RSS reader. Some of my
favourites are the Daily Worse Than Failure, and the joel reddit. These kinds of things can be great for exposing you to ideas that you wouldn’t have thought of on your own, and for keeping on top of the latest trends. Secondly, nothing beats getting your hands dirty for learning how to code better. The most valuable experiences
for me have been when I’ve had to maintain some truly awful code left behind by my predecessors – it really teaches you the pain that you can cause through sloppy coding practices!

The Problem of Proud Programmers

I want to close by addressing one sin that I think programmers are probably particularly prone to, and that is pride. We all know the stereotype of the computer
programmer, and great people skills aren’t part of it. But I wonder if part of the reason the stereotype is so often accurate is because of the kind of people who are attracted to computers. Other people are so inherently unpredictable, which some people find really hard to cope with, and computers can provide real
solace for them. I find it much easier talking to my computer, where I can tell exactly how it’s going to respond to a given input. But I wonder if this means that programmers are especially likely to slip into pride. We’re used to exercising complete dominion over our CPU, bending it wherever our will determines – we are like gods among men! Except we’re not – Jesus is the king, and programming under his lordship being quick to acknowledge that. It’s why the Bible devotes so much space to the issue of pride, since it’s a particularly nasty form of idolatry that sets us up as rivals to the Lord Jesus. Yet it’s not a topic that you’ll find covered in many other programming blogs. There are certainly writers like Jerry Weinberg who talk about the practical benefits of “egoless programming“, but I think there’s a massive spiritual dimension to pride that means there’s real benefit to be had from a programmers’ blog from a Christian perspective.

Programming under the Lordship of Christ won’t always be easy, but he’s promised to give us grace enough for each day as it comes, so let’s keep going in his strength as we spur one another on to love and good works.