The Curse of Information Addiction

RSS is Rotting My Brain

I’ve been thinking lately about the detrimental effects that I’m
suffering as a result of information overload. Over the last few months, the
number of blog feeds I follow in Google Reader has been steadily
creeping up, not to mention people I follow on Twitter and FriendFeed.
Most notable has been the effect on my concentration span – I now seem
completely incapable of focussing on anything for more than a few
minutes before I suddenly find myself back on the Google Reader tab
looking at what’s new. It’s an obsession – constantly craving that new
titbit of information to feed my addiction. As Seth Godin
recently said, “The internet is almost full”: not physically, but the
demands on our attention and our ability to take it all in are
dangerously overstretched.

The symptoms are very similar to
those suffered by TV addicts. A whole generation of couch potatoes is
widely criticised for having the attention span of goldfish, constantly
hopping from one sound bite to another as they surf the channels in
search of the next fix. I enjoy the fact that where I live in London we
don’t own a television – instead I watch DVD boxsets of specific shows
like “The West Wing” and “House“.
It’s proven itself to be a much healthier model than just plonking
myself down in front of whatever happens to be on the telly at that
moment: I can proactively choose what to follow, and the fact that
there’s a finite amount of material available allows me to make
informed decisions about how I’m going to pace myself.

A Better Way?

Some blogs really lend themselves to being read in a “DVD Boxset” manner. A favourite of mine is “Joel on Software“.
I arrived quite late in the day when Joel had already been writing for
several years, but because he tends to post a smaller number of higher
quality articles rather than blogging daily, it was still quite
practical to read through his entire back catalogue from start to
finish. Just like with my DVD boxsets, I’ve now done the same for a
number of bloggers of similar style, such as Rands In Repose and Paul Graham. The other thing that these three all have in common – another by-product of their writing style – is that they’ve all produced books
by collecting together the best of their blog posts on certain themes,
making them even more analogous to the television show’s DVD boxset.
Now that I’ve begun to notice the mind-rotting effects of constanty
flitting between different RSS feeds, I’m beginning to wish that I’d
simply bought these books rather than reading online.

The reason
that I find the appeal of Google Reader experience so enduring is that
at heart I’m a busybody. I like to know what’s going on in the world –
what’s new and exciting, what people are thinking and saying. New
version of WordPress just released – great! Google Chrome out of beta –
fantastic! Crummy Wifi at  the LeWeb conference – too bad! It feels
like too great a cost to stop following these news sources – to be like
everybody else and find out three months later when an article finally
makes it to BBC news. But I’m convinced that something has to change:
as Paul commands in 2 Thessalonians 3:11-12, busybodies who are idle when they should be working need to sort themselves out and get on with it!

Drastic Measures

The result of all this thinking is that I’ve decided to change my blog reading habbits for good.

  • I’m
    going to narrow down the list of blogs I read regularly to the ones
    that are of a consistenly high standard and which I really benefit from
    reading.
  • I’m going to favour a weekly or biweekly session of
    sustained reading of those blogs, rather than feeling the need to read
    posts the minute they’re published.
  • I’m going to put a premium
    on bloggers who collate the best of what they read online for you so
    that you don’t have to – feeds like Robert Scoble’s Shared Items or Justin Taylor’s Christian blog “Between Two Worlds“.
  • Related to that, I’m going to carry on my habbit of reading high quality aggregation sites like Hacker News once daily and let other people do the obsessive RSS reading on my behalf.

My
hope and prayer is that however painful it might feel in the short
term, over the long term I’ll really benefit from this change of
attitude and begin to see an improvement in my ability to focus on the
job at hand.

Things to ponder:
  • what habbits of yours are adversely affecting your concentration?
  • are there other ways to get some of the same benefits with less of a detrimental effect upon your work?
  • do you think the blogs you read genuinely offer value that makes them worth following daily?
  • do
    you find the blog posts you really enjoy reading often end up appearing
    on another site that you visit anyway, making it less important to read
    the blog directly?

I’m a Christian Software Developer

After running my blog in it’s current form for just over six months now, I’ve decided to slightly tweak the formula. I’ve been finding the tagline of “Christian Software Development” somewhat restrictive in terms of what it inspired me to write about, and my trusty Google Analytics stats have suggested that it would be perfectly sensible to relabel geero.net as the site of a “Christian software developer” instead. As a Christian who also happens to be a software developer, I hope to be able to bring to bear a Christian worldview on issues that I find interesting, and which other software developers, Christian or not, are also likely to be interested in – which is pretty much what I’ve been doing already but less intentionally.

What this means practically remains to be seen, but I have a number of potential blog posts brewing at the moment and hope to write them up over the next few weeks and months. Stay tuned!

The Idolatry of Brand Names

As I was standing outside the Apple store on Regents Street waiting for my friend to finish his shift there, I couldn’t help but notice the looks of reverence and awe on the faces of those who passed by. There seemed to be a widespread recognition by all who gazed across the threshold that this was hallowed ground – one of the sacred sites of the Western world which rivals any ancient temple. Us sophisticated modern people look down our noses at the naivety of the ancient world who trembled before their pantheon of gods – we’re far too educated for such superstition! And yet it began to dawn on me that maybe we’re not so different after all. They look rather different and we call them by different names – could it be that our Mount Olympus is occupied by the imposing brand names of large corporations? The gods and goddesses Apple, Microsoft, Sony, Nike, Pixar, Google? Just as the gods of old dominated every aspect of life for those who worshipped them, from agriculture to childbearing, so too the modern brand name deities exert their influence over all walks of life, from what we buy to where we work. Below are three big similarities that I thought of – perhaps you can think of more!



Image by strangeaeons

1. They give us a sense of belonging

When talking about his new book “Tribes“, marketing guru Seth Godin said this:

“Harley Davidson and Apple are titanic brands for the very same reason. They sell a chance to join a group that matters”

If you go to a web community conference like BarCamp or the Google Developer Day, you can’t help but notice that 90% of the people there seem to have a MacBook on their laps. The message is loud and clear: “if you were really a part of our club, you’d have one too.” It’s the same thing that causes school kids everywhere to spend such large proportions of their income on brand name clothes – worshipping the right branding gods shows that you’re a member of the tribe.

2. They cast a large shadow

Brands are held in awe – consumers flock to them, competitors fear them, employees find security under their wings; brands stand immovable and unshakeable, at least they like to think they do. I’ve long known my own idolatrous heart has been drawn to big brand companies when looking for work because of the prestige that working for one seems to convey. Buying your DVD player from Sony somehow feels safer than buying some unknown brand – you feel confident in the quality of your purchase, whether or not that’s well-founded. As the saying goes, “nobody ever got fired for buying IBM.”

3. They own their part of the world

Just like the idols of the ancient world were restricted in their field of influence, so it is with modern brand names. Where Demeter was in control of your crops succeeding or failing, so Microsoft dominates your office productivity; where Poseidon ruled the seas, so Google rules the world of the internet. To guarantee success across the board, the ancient pagans were forced to offer sacrifices to as many different gods as possible to make sure they covered their bases. After all, what if the one god you missed out ended up being the very one you ended up needing a favour from? Equally, it is not sufficient for the modern man to wear the right clothes if he does not not also own the right television or have the right job with a sufficiently well-recognised City firm.

The pressures of idolatry facing us today really aren’t that different from those faced by the Israelites back in the Old Testament. They were eager to avoid standing out from the nations around them, for example when they begged Samuel to appoint for them a king, “that we also may be like all the nations”; they feared that limiting their worship to just one God, the Lord, might incur the disfavour of another to their detriment; they often sought to make alliances with other, more powerful nations by worshipping their gods.

The antidote: worship the all-powerful Creator

The Bible’s antidote to their idolatry was to show how ridiculous it was in the face of God’s amazing bigness:

“Hear the word that the Lord speaks to you…: Their idols are like scarecrows in a cucumber field, and they cannot speak; they have to be carried, for their cannot walk. Do not be afraid of them, for they cannot do evil, neither is it in them to do good… they are all the work of skilled men. But the Lord is the true God; he is the living God and the everlasting King. At his wrath the earth quakes, and the nations cannot endure his indignation… It is he who made the earth by his power, who established the world by his wisdom, and by his understanding stretched out the heavens. When he utters his voice, there is a tumult of waters in the heavens, and he makes the mist rise from the ends of the earth. He makes lightning for the rain, and he brings forth the wind from his storehouses.”

Whereas their false gods were limited in their sphere of influence, the Lord made the whole world and has ultimate power and authority over every inch of it. At the end of the day, our modern brands are but the creation of human hands, who were themselves made by the one, true God. Our fear is often really just the fear of men – how foolish it looks when confronted with the almighty God?

So let us not fear the false gods of this age, but respond like the Thessalonians: who “turned to God from idols to serve the living and true God” – the one who made the earth by his power.

Friend Feed and Comments

Some of you may have noticed how utterly useless the “comments” area on this blog was – if you’ve noticed it at all! Well, today I finally got around to hooking my blog up with FriendFeed, an excellent service from a bunch of ex-Googlers. You’ll need an account with them to comment, but you really ought to have one of those anyway.

If I wasn’t so lazy, I might find the time to allow you to post comments without leaving my blog, but for now you’ll have to go to FriendFeed itself in order to actually post the comment, which will then show up at the bottom of the post itself.

The Wordle of God

romans8.JPG

I’ve had one of those rare weekends of having pretty much nothing to do whatsoever – praise the Lord for a very welcome break! It gave me a chance to do a bit of coding just for fun, and after discovering a brilliant website called Wordle I decided to make a mashup with Bible Gateway. The result: The Wordle of God. Whilst it’s basically just a lot of fun, I think it also has potential as a really useful tool for getting an overall feel for a Bible passage and what the dominant themes are.

 

Geero’s Recommendations – June 2008

Back at the start of May I left Trinity Mirror, where I’d been working for two and a half years as a web developer, and joined Framestore, a film company specialising in computer generated movies. It’s been a great experience that’s given me some helpful insight on my character and a fresh perspective on my time at the Mirror. The down side is I’m working a five day week and longer hours, hence why I’ve not succeeded in blogging much lately.

In the absence of something more profound to post, I thought it would be a fun little exercise to post a bit about the books, websites and places I’ve been enjoying over the last few weeks. For the uninitiated, my life is essentially one big routine, so this is a bit of a reflection of how I spend my days!

Morning Commute

I live in the East End of London and work near Tottenham Court Road in the West, so I basically have two choices for how to get there each morning:

  1. Central Line from Mile End to Tottenham Court Road – this is definitely the quickest route to work, taking about half an hour for me door to door. The downside is that the Central Line is absolutely rammed at half eight in the morning, such that you’ll probably have to wait for several trains to pass, and then once you do squeeze on you may not always have much room to get a book out and read it
  2. District Line to Embankment and then Northern Line to Tottenham Court Road – ah, much nicer! You can probably get a seat for much of the journey, making reading much easier. Shame it takes more like 45 minutes, though.

As for what I read: the morning is my time for reading a good Christian book to help my hard heart to meditate on God’s character. At the moment I’m reading the excellent Knowing God by Jim Packer – it’s one of those books I’d recommend every Christian to make a habit of reading regularly. I last read it about five or six years ago, and am finding it every bit as edifying the second time around.

My general criteria for my morning book is that the author should write in points short enough to read in their entirety before reaching your destination, but ideally with a bit of time left over to chew on what you’ve read and take it in properly.

Before Starting Work

I use a del.icio.us tag to neatly organise all of the websites I like to check before I get down to work. Currently on my list are:

  1. Twitter – it doesn’t take a minute to update your status once a day, and keep your Facebook friends up to date on the latest goings on in your life
  2. Various comics – at the moment I love reading Pearls Before Swine and F Minus
  3. Remember the Milk – I’ve only just discovered this fantastic website, but it’s great for helping overcome that sometimes overwhelming feeling that you’ve got so much personal admin to do and no chance of remembering all of it
  4. Google Mail – I resisted for ages, but having gotten the Google Mail bug I now use this exclusively for all my mail, forsaking my previous approach of downloading all of my mail onto my main computer on a regular basis and only having unread messages available through webmail.

Lunch Time

I have a number of options for lunch, depending on the weather and my mood.

  1. Russell Square Gardens – a bit of a walk from my office, but a beautiful little spot to sit and eat your lunch, read a book or have a quick pray
  2. The Covent Garden Talks – every Thursday lunchtime a bunch of Christians meet together on Endell Street to hear the Bible explained in way that’s really accessible to non-Christians. It’s a great resource to invite colleagues to, and to equip us to server God in the workplace.
  3. Google Reader – my ‘sit-at-my-desk’ lunch option is to go on Google Reader. I follow quite a lot of blogs, mostly programming ones. My current favourite is Jeff Atwood’s Coding Horror.

Banana Time

My whole family has a weird tendency to get the jitters just before dinner if we don’t get some sugar in us, so I make a point of eating one of the bananas my company freely provide us with at around 4.45pm. It makes a nice opportunity for a little break, where I often visit Hacker News for some thought provoking discussions.

Commute Home

The Central Line is much quieter at the time I go home, so I virtually always use it. In the evenings I tend to go for a secular book, and have just finished an excellent book called Dreaming in Code by Scott Rosenberg. It’s a very well written discussion of what makes software so incredibly hard to write, following the story of OSAF, the creators of the Chandler Project. I shall probably post some more at some point about some of the idea it’s given me for how to move forward with my Bible-teaching computer games project.

Evenings

Recently I’ve found my evenings to be pretty busy. I’m involved in a church called St. Helen’s, Bishopsgate, where I help to lead a student Bible study group. This year we’ve been doing a Bible Overview, which has been absolutely fantastic. I’m a bit sad to part with my lovely group now that they’ll all off for the summer :(

If you’re ever in the City area on a Sunday night, do come along to our 6pm service!

Summary

Well there you have it – my life in a nutshell!

Lessons Learnt From the First Job I Ever Quit

What I learnt about myself from my time at Trinity Mirror

On 4th September 2005, in God’s great sovereign
plan, I started work as a software engineer in the Digital IT department of the
Trinity Mirror newspaper group,
working on their online titles. It was a surprising move, in some ways: my
passion has always been for computer graphics and games development, and it’s
fair to say that web development had only ever been a sideline for me up until
that point. My priority at the time, however, was to get a reasonable job that
would enable me to still have a life outside of work so that I could get
involved in a church where I’d be
built up and equipped to serve Jesus in the long term, and Trinity Mirror
seemed like it would offer that. In the event, it exceeded my expectations in
every way, and any doubts I may have had quickly vanished. As a green young
developer with little experience of the realities of programming in a real-world
team it was a privilege to work with the very talented group of developers they
had working for them, and I shall be forever grateful for the masses I learnt
there about how to make great software, working on sites like Adzooks.co.uk and the rebranded Liverpool Echo and similar regional
newspaper sites. They taught me the joys of agile methodologies like Extreme Programming and Scrum; they taught
me the importance of actually talking to your customers and not just assuming
that you know that they want or even that they know what they want; they
taught me how (and how not) to write maintainable code (or at least why it
matters!); they certainly taught me the utterly incomprehensible choice of a
language that is Coldfusion;
but above all they instilled in me a deep routed desire to avoid the cheap and
easy hacks and implement the right solution in the right way.

So what changed?

For various reasons I’ve been getting increasingly itchy
feet for some months now, wanting to move on from Trinity Mirror. Whilst it’s
not appropriate to go into the details here of exactly why, I’d like to share
with you the following lessons that I’ve learnt about myself through the perspective
of my growing discontent:

  1. I’m a sinner. My colleagues will
    have had no problems identifying my many flaws, although I suspect they
    might think nothing of that which I consider most serious: my lack of
    thankfulness to God. It’s a testament to the depths of human depravity
    that when there were so many absolutely awesome things about this job I
    still managed to grumble my way through my last few months.
  2. Building something people want is way
    more interesting than exposing them to more advertising
    . Paul Graham
    is always going on about the fact that the best way to make wealth is to
    build something people want
    , but I’ve discovered through experience
    that it’s also the most satisfying kind of work I’ve ever done. I’ve only
    really just worked out why it was that working on Adzooks.co.uk was consistently the
    most interesting and enjoyable aspect of my job, and it’s this: when
    working on Adzooks, we were focussed on giving end users a more useful and
    more satisfying experience, often without any clear means of monetising
    it. The less satisfying projects were the exact reverse. There are some incredibly boring ways to
    make money
    out there, and also some awesome products with no strategy for making money whatsoever
    – but they’ll find a way some day. If I didn’t already, I certainly know
    now which of those I’d rather do for a living.
  3. I work best when my productivity
    levels are easily seen
    (for better or for worse). This is really a
    corollary of number 1 – I’m a sinner, who is both lazy and proud, and my
    behaviour in the face of changing circumstances has revealed that ugly
    truth. The loss of a great manager who was always aware of what I was up
    to and gave frequent feedback; a growing team where the contributions of
    individuals is harder to spot; a form of Scrum where the perception is
    that as long as you deliver what you committed to at the start of a
    fortnight there’ll be no questions asked – all of these things slowly
    began to sever the connection between how hard I worked and my standing
    within the team. The standard set for me is to “obey in everything those
    who are your earthly masters, not by way of eye-service, as
    people-pleasers, but with sincerity of heart, fearing the Lord” (Colossians
    3:22
    ), and yet instead people-pleasing seems to so often be the
    driving motivation, with sincerity of heart barely getting a look in. It’s
    easy to work hard when people will praise you for it; it’s far, far harder
    to keep pressing on when the hope of the Lord Jesus’ commendation is the
    only motivation on offer. On judgement day I shall have no defence but to
    plead the blood of Jesus who died to defeat such sin – and praise God for
    such a hope! For one day, by his grace, this sinful nature of mine will
    be overcome, and I shall be free to serve him perfectly as I long to
    do. In the mean time, give me small teams! Give me feedback! Give me high
    visibility of my productivity.

Finally, do I have any parting words for my co-workers?

  1. A huge “thank you” for everything.
    You’ve been great. It’s been marvellous fun. We’ve drunk a lot of tea.
  2. Be the change you want to see in the
    codebase
    . Don’t just grumble about the state of legacy code, get on
    and refactor it. Live the dream! Make things just a little bit better
    every day, placing your mark on the world. Be a garlic
    programmer
    .
  3. Never be content with mediocrity.
    You’re all smart, talented people. Yes, even you. Don’t settle for things
    the way they are – always be looking for ways to make things better. Read
    everything and anything you can get your hands on – you’ve got some great
    books on that shelf of yours! Question everything – why did that break? What could I have done differently to
    prevent it? What am I going to
    do differently to prevent it happening again? How will this change I’m
    about to make affect how hard this code is for other people to maintain?
  4. Make plans for eternity. Jesus may
    seem like a humorous joke to you at the moment, but one day you will die,
    and on that day you will meet him as your judge. “Of this God has given
    assurance to all men by raising him from the dead.” (Acts
    17:31
    ) I know it seems unlikely, but if it’s true then it’s so
    profound that it changes everything
    – isn’t that worth spending a few hours of your life to at least look into
    it?

Farewell, Trinity Mirror!

Tips for taking over someone else’s code

I’ve been dying for some time now to write a post explaining some of the changes I’ve been making to Blender’s DirectX exporter. In some senses it’s nothing particularly exciting, but it’s been a great learning experience for me, and it’s unearthed some little nuggets of goodness that I just can’t help but share.

The Importance of Feedback

I’ve been developing an engine to make 3D Point & Click adventure games for a few years now, and I have to admit that for much of that time I’ve been in a state of denial about how hard it would be to get content out of my 3D modelling package, Blender, and into my game. I’d only ever used pre-existing .X files for all my testing (good old Tiny.x!) and since Blender ships with a Python script for exporting DirectX files I wrongly assumed it be trivial to start creating my own when the need arose.

exporter_20080404.jpg

However, when I eventually tried it, it seemed to fail every time. The author was great at replying to my emails, and he was always able to diagnose some obvious flaw in the way my mesh was configured that was causing the exporter to stumble – “you’ve got a negative scaling factor”, “your armature isn’t parented to the mesh properly”, “you’re using envelopes instead of vertex groups for skinning”, and so it went on. These things were obvious to the author, since he knew exactly how the exporter worked and what assumptions it made, but to someone like me who’d never delved into the source code, all I knew was that my mesh wasn’t working properly and that I wasn’t being given any feedback to help diagnose the problem.

There’s a lesson in there: never let your software fail silently. If your user has ticked the “export animations” button, there’s a good chance that they think their mesh contains some animations. So why not check that you agree? If their mesh doesn’t contain any vertex groups that match bone names, and your code is built on the assumption that there are, it probably wouldn’t hurt to tell them.

The Mystery of Someone Else’s Code

Eventually I realised that I couldn’t rely on the author debugging my meshes for me forever, and that I was going to have to get my hands dirty to figure out why my mesh wasn’t working. I very quickly discovered what people have been telling me for years: it’s far, far harder to read code than it is to write it. I wasn’t helped by the fact that I’d never written a line of Python before in my life, nor did I have any knowledge of the Blender API. To be honest, I really rather enjoyed the challenge of figuring out this mysterious piece of code. Here are some of the tricks I used in my siege upon the citadel of mystery:

  • Treat every line of code other than the one you’re actually interested in as a black box that you don’t need to understand. This was helped by the fact that the exporter was nicely broken up into lots of beautifully short functions, so to begin with I could ignore all of them except the entry point. I’ve seen plenty of people give up and go home because they wanted to understand a complex system in its entirety, and the challenge was just too great. Gradually, over time, strongholds began to fall as I captured functions into my empire of understanding
  • Rewrite the code where necessary so that it documents itself. Many of the functions and variable names were either unenlightening or plain misleading. Here’s an example: the exporter gives the user two buttons, “Export All”, and “Export Selected”; which of those buttons do you think the ‘SelectObjs’ method belongs to? Well, for some unfathomable reason, that’s the function that exports all objects. Rename it! I’m a strong believer in having plenty of comments, but I’m an even bigger advocate of the idea that the code itself is the best explanation of what the code does (it’s certainly the easiest to keep up to date!) so it should be made as readable as possible by using sensible function and variable names. Got an argument called ‘obj’ which is always a ‘Mesh’ object? Rather than adding a comment to the code, why not rename it to ‘mesh_obj’ so that it comments itself? Conversely, if you have a variable called ‘mesh_obj’, make sure it doesn’t sometimes contain an ‘Armature’ object!
  • Liberal use of debug output – whilst you’re in the process of understanding some code, don’t be afraid to make it output all manner of superfluous debug information to help you get a feel for what values your variables hold at different points. Similarly, it’s helpful to explicitly document what assumptions you think the code is making about the contents of its variables (in C++ I’ve started to use ‘assert’ for this a lot more than I used to). Sometimes I’ve even used this in cases where you think it can’t possibly be necessary, and unearthed some really obscure bugs – for instance, if you’re convinced (and relying upon the fact) that two expressions are equivalent (e.g. you think that parent_matrix * my_matrix = combined_matrix) then by outputting the two expressions you can get a very helpful clue when you realise that they’re actually different.

Making it your own

Having started to understand the code a bit better, I gained the confidence to start making some improvements of my own. Here are some of my favourites:

  • ‘Why’ not ‘how’ – the original version of the code contained a good dozen instances of this line: name.replace(".", "").replace(" ", "_"), to deal with the fact that object names inside a .X file can’t have dots or spaces in them. Now, in some ways this seems harmless enough, but I wanted to factor it out into a method call anyway, just because I’ve got a strong dislike for ‘copy and paste’ coding. I could have named the method, “remove_dots_and_spaces” (a ‘how it does it’ name), but I’ve come to realise that a semantically descriptive name is much more useful, so I called it “make_x_compatible_name” (a ‘why it does it’ name). By doing that, it got the creative juices flowing, and I started thinking about what else might cause a name to break your .X file, and came across an example where using a reserved word (e.g. ‘string’ or ‘integer’) as a name caused it to break. Having a method factored out made it trivial to add some code to check for reserved words, and the change then immediately applied everywhere that method was used. Fantastic!
  • Pythonesque-ness – I can’t say for sure, but one got the impression reading this code that, like myself, the original author wasn’t a native Python speaker. I had great fun and learnt all sorts of neat things by rewriting things to be as Pythonesque as possible. I think so far my favourite Python feature is list comprehensions – the ability to generate new lists based upon old lists in a single line of code, a sort of combination of map and filter all in one neat piece of syntactic sugar. In my view, rewriting the code to be more ‘natural’ Python makes it a lot more compact and readable – it allows the intent to show through more clearly without being distracted by the means.
  • More robust error handling – I’ve added a great deal of code to the exporter that spots problems with how your mesh is configured and reports back to you. Hopefully that means it will be a lot more useful for real life work by real life people. One of my goals was to fix anything within the exporter that would require ‘fiddling around’ by the artist, since code in the exporter only needs to be written once whereas there are a lot of 3D assets to be made, and the exporter needs to be run again and again.

You can find my version of the exporter here. If you do experience any problems with it, please report back and send me your .blend file so that I can continue to improve its error detection and feedback.

Yesterday’s Priority is Today’s Procrastination

I’ve begun to notice a recurrent phenomenon lately that is totally killing forward momentum on my Bible-teaching computer games project, namely this: What was a genuine top priority yesterday turns out to be a complete waste of time today. When I dropped down to a four day working week last September in order to devote
more time to my game, I spent the first day drawing up a list of my top priorities. It wasn’t hard: there was a clear show-stopping feature that had been holding up substantial development for about six months. The stupid thing was that once I got down to it, I was able to bash out an implementation in a single weekend – opening the floodgates for all sorts of exciting progress that was dependent on that feature. Why oh why had I spent the last six months circling around the real issue, tinkering with code that simply didn’t matter
in the grand scheme of things?

“Never again,” I told myself. From now on, let’s always pick the most important feature and prioritise that. Yet barely a few weeks had gone by when I found myself in the exact same situation, frittering away my time on an annoying piece of code that actually wasn’t all that important, whilst the real meat left untouched in some other part of the system. So I asked myself how it had happened. Where was the bug in my process? What it came down to is this: my granularity of features was too large. Sure, the most important thing that needs doing today is the Doodad Whatyajibbet, but is it really true that every single line of code I’m writing under the Whatyajibbet umbrella is really equally important? The answer, in my case, was a resounding no. Yesterday, the Doodad Whatyajibbet was my critical path, but now that 70% of it has been implemented, it’s the FlimFlam MegaDoowhat that’s standing in the way of real progress. Getting this wrong is a disaster for motivation in the long run, because you get into situations like mine were you’ve spent six months faffing and essentially have nothing to show for it. What’s more, my days at home when I get to focus on my game are a precious resource that I really don’t want to be wasting – good stewardship of this amazing gift God’s given me demands that I use them wisely.

This is one of the things that agile methodologies like Scrum really help you with, if you do them well. You break your projects down into the smallest work units that make sense on their own, and then each sprint you pick the user stories that are going to give you the biggest return on
investment.

So here’s my battle plan moving forward:

  • Each day, pick the smallest work unit that’s standing in the way of progress
  • Implement as little as you can to see the benefits you’re after
  • Deprioritise mercilessly the things that won’t move me towards my goal

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.

And Now For Something Completely Different

You’re going to start seeing a few changes here at Geero.net over the next few months. I’ve decided to redesign the site, and put more of an emphasis on content related to being a Christian programmer, and also programming Christian software in particular.

If there are broken links or you can’t find the content you’re looking for, please bear with me. I have tried to make sure as many of my external links as possible still work, but I may well have missed a few.

Thoughts of a Christian Software Developer