Category Archives: coding for christ

coding for christ

My Undigital Sabbath

I’ve been increasingly aware recently that I’m fast becoming a serious information addict – constantly refreshing tech news sites and Facebook and whatever else it is in search of a nugget of news to give me the next brief high. Tim Challies talks about this in his great new book “The Next Story“, quoting an interview with a psychiatrist called Dr. Edward Hallowell about so-called Attention Deficit Trait:

“It’s a condition induced by modern life, in which you’ve become so busy attending to so many inputs and outputs that you become increasingly distracted, irritable, impulsive, restless, and over the long term, underachieving.”

All this has had a knock-on effect for my relationship with God as well – without doubt I find it harder to concentrate on anything for very long these days, which includes Bible reading and prayer. Deciding I could ignore the problem no longer, this weekend I decided to have a kind of digital detox – I thought I’d try going internet & laptop free for 24 hours from sundown on Saturday night, possibly with the intention of making this a weekly experience.

It turned out to be a really valuable time. It was at once easier than I expected and harder than I expected. Easier than expected, because I certainly didn’t feel I was missing out on anything important – certainly nothing that couldn’t wait until Sunday evening. But harder than I expected, because with nothing else planned instead I found myself really bored. I find reading anything for more than about a chapter pretty hard these days, so that didn’t pass much of the time. I went for a jog, which was certainly a good thing, but again, didn’t exactly take long.

I ended up being so bored that I cleaned the bathroom – something long overdue. There’s probably an important lesson there. How often do I end up using Google Reader as a way to put off doing the jobs I ought to be doing instead?

So will I repeat the exercise next weekend? Almost certainly. I might relax the requirements a little and allow the laptop, but with wi-fi turned off – there were several moments where I thought it would be good to use the time to write something, which wasn’t very practical without the laptop. But overall it felt like a really positive experience, and definitely was good for my spiritual health.

coding for christ

Lessons Learnt From My iPhone Development Sprint

Intro

What with Easter and a certain wedding here in the UK we’ve had a lot of Bank Holidays lately, so I had the opportunity to escape to my parents’ home in the Gloucestershire countryside for about 10 days. I decided I wanted to make the most of the time to develop an iPhone app that I’ve been thinking about recently. Last night at 11pm I submitted a binary of that app to Apple for approval – it’s called “PrayerMate” and it’s designed to help you organise your prayer life. In this post I want to write up some of my experiences and what I’ve learnt from it all.

Before I go any further, I should explain that I have a very poor track record of actually shipping anything. It’s taken me many years to catch on to the huge chasm that exists between “knowing Objective-C” and “raking in the profits from a successful app that is actually available for purchase on the app store and that people enjoy using and want to recommend to their friends”. You’d have thought it would be obvious that those two things are not the same, and yet I think a lot of us probably fall into the trap of thinking that “I theoretically know what would be involved in making something” is conceptually identical to having actually gone ahead and done it.

Recognising this about myself up front, I realised I was going to have to take special measures to make sure that this didn’t end up as yet another half-baked piece of code festering on my hard drive because finishing it off proved too much like hard work. Which leads to my first point: planning

The Planning Stage

Long before the holiday began I tried to plan out what I would and wouldn’t do during those 10 days. The product I had in mind was really well suited to a short development sprint, since the Minimum Viable Product was extremely simple, yet the scope for adding extra features over the long haul is vast. I made myself a list of all of the features I could think of, and was absolutely ruthless about what would make the cut for version 1.0. And I mean ruthless – initially I hadn’t even planned to allow people to delete prayer points once they’d added them to the database. This paid off in spades later in the development process, when it quickly became apparent that even the simplest feature has acres of hidden complexity lurking beneath the surface. Admittedly I ended up adding one or two of those features that I initially rejected later on, once I felt confident that they wouldn’t make shipwreck of the whole enterprise, and that whilst perhaps not essential they were nonetheless pretty important.

Having made my list of features, it broke down nicely into about four key areas, so I made myself a schedule for how I would use the 10 days. It worked out like so:

Thursday 21st (travelling): UI Design
Friday 22nd (Good Friday): Basic navigation
Saturday 23rd: Manage categories
Sunday 24th (Easter): DAY OFF
Monday 25th: Manage subjects
Tuesday 26th: Prayer mode
Wednesday 27th: In-app payment upgrade
Thursday 28th: Testing, bug-fixing
Friday 29th (Royal Wedding): Icon design, screenshots, writing blurb

I made sure I knew which days were going to be taken up with other stuff like Royal Wedding celebrations and so on, and deliberately scheduled a lighter workload for them. You’ll also notice I planned to have a full day off on Easter Sunday, the benefits of which I’ll talk about later on.

With hindsight, making this schedule was probably one of the most important factors in my success. I’ve spoken previously of the crippling effect of uncertainty in my life, and having this schedule meant that I always knew what I was supposed to be working on at any given point in time. It helped that it was more or less realistic – the first few days I finished nice and early and was then able to take the evening off to spend time with my parents, and one or two days I was still coding away at 10:30pm trying to get something finished when I’d much rather have been heading to bed – but by and large I was able to stick to that schedule right until the end, and it was a huge help.

Clearing the Stones

I deliberately didn’t start on the project in earnest before heading to my parents’, but for the week or so leading up to it I did try to clear the ground a bit so that I could get off to a running start. I knew that I wanted to base the project off one of the samples that Apple provides, so I made sure that was compiling and running properly on my iPod Touch. Perhaps that all sounds a bit meaningless and insignificant, but it had been a significant mental barrier to my starting earlier – I’d formerly tried to get that particular sample running and had broken it with some changes I’d made and didn’t really understand why it wasn’t working properly. I wan’t to make sure my first day of my sprint wasn’t going to be wasted faffing about stuff that I didn’t really care about.

Designing the User Interface

Again, because of the crippling effect of uncertainty, I knew that an important first step was going to be to mock up the user interface. If I didn’t know what I was supposed to be coding then there was no way on earth I was going to succeed in getting on with it. So whilst I was on the train from London Paddington to Kemble I fired up Balsamiq Mockups on my MacBook and worked out what the workflow was going to be. Nothing very fancy or very complicated – but I would have spent the rest of the week floundering if I hadn’t done this first.

iPhoneUI.png

Coding a Fake App

Over the next few days I then had to get on with the coding. The first day I created all of my view controllers, populating all of the tables with hardcoded data and allowing the user to navigate between it all. This worked out really well over the rest of the week – it meant that it felt like a working app right from the start, and every little bit of code I added could be seen in action as soon as it was written. It was basically a case of eliminating friction later in the week – there was none of the hassle, however small, of creating new classes and so on, because it was all there ready and waiting on day one.

Where Would I Be Without Stack Overflow?

I have to say, I would have been utterly lost without Stack Overflow. I must have used it about half a dozen times a day – it seemed like every time I Googled a problem I was having, somebody had already asked a question about it on Stack Overflow and there was already a bunch of awesome answers explaining how to solve the problem. In a few rare cases where a question didn’t already exist, I got some excellent answers promptly. Kudos to Jeff Atwood and the rest of the team involved in developing such an awesome site and community – in my experience it really works.

The Value of a Day Off

As I mentioned previously, I planned right from the start to have a complete day off on Easter Sunday, and get away from the computer as far as possible. Partly that’s because I think that’s the way God’s designed us – he set the pattern of working hard for six days and then having a day off himself, and who are we to work harder than God? But my experience bears out the wisdom of that. Quite apart from feeling more refreshed off the back of it, it meant that by Monday morning I was chomping at the bit to get back to work – I literally couldn’t wait to get on with it. Speaking for myself, if I work flat out without a break I’m rarely doing my best work, and usually end up wasting so much time that I would have been better off taking a day off anyway, so I don’t think you lose anything by trying to be a hero.

In a similar vein, I also made a point of going for a walk for about an hour every afternoon. I got through a lot of 5by5 podcasts during the week! The one day I failed to do that, my eyes were throbbing by the end of the day and I seriously regretted it. I should have listened to my mother – there’s no substitute for eating well and getting good exercise!

The “It’s Mostly Done Phase”

I found that by far and away the hardest phase of development was that penultimate day I scheduled in – “testing and bug-fixing”. I quickly realised that this is were 90% of my failed projects come to die. The product feels finished, although admittedly I had a list of about a dozen little niggles that needed fixing before I could launch. And, of course, being me, there was about a dozen other little niggles that I kind of knew about but hadn’t bothered to write down on my list.

This is where the schedule really broke down. Suddenly I was back in the land of uncertainty – which of those things should I tackle next? How am I going to solve that really hard-sounding one? Aghgh! It only makes matters worse that so many of them seem quite simple – all the more reason not to bother tackling them, since “I can always do that later, it’ll only take a minute”.

In the end I just had to bite the bullet, choose the hardest problem and crack on with it. I often find that once you actually start on something, it’s not nearly as bad as you think. Beginning is often the most difficult step.

Kicking It Out The Door

Once the holiday was over, I put the app to bed for a week whilst I got on with real life. I did show it to a few friends during that time and got a bit of user feedback, but I didn’t do any coding at all. I decided that if I was going to get this thing finished, I just needed to set myself a deadline and say that I was going to submit it to Apple no matter how many little niggles remained unfixed. Yesterday was clear in my diary, so I decided I’d just have to get as much done as I could and then live with the consequences for the rest. That turns out to be a really helpful motivator!

Even so, it amazed me how much courage it seemed to take to go ahead and submit the app. “How can I be sure if I’ve done enough testing?” “What if they find some really obvious bug right off the bat?” Well, you know what – it’s free to submit it, and you can always resubmit it later if they find something! It was a tremendous relief to finally get the thing submitted (even if it did require a complete reinstall of Xcode to overcome an annoying Java error – thanks again Stack Overflow!) and now I just have to work frantically on all of the marketing material whilst I wait to hear the result.

Conclusion

Overall, I’m so glad I decided to get on and make PrayerMate. I feel like I learnt loads about myself and why I find things hard and what I can do to help myself. And hopefully I’ve made a useful app that people will get some genuine benefit from as well. Here are my top five lessons:

  1. Clarify what you’re supposed to be doing at any given moment as much as possible
  2. Never believe the lie that something is “almost finished” until it is actually finished
  3. A very simple app that is finished is a lot more useful to people than a “fully featured” app that isn’t available for purchase
  4. Know when to stop working as well as when to get on with it
  5. You can get an awful lot done without the commitments on your time of “normal life”!

Be sure to watch out for PrayerMate in an App Store near you in the coming weeks!

coding for christ

How to Install PythonMagick on Mac OS X

I’ve been having a bit of a headache trying to install PythonMagick (the Python bindings for ImageMagick) on Mac OS X Snow Leopard, so having eventually had a modicum of success I thought I’d post my adventures here.

Problems Building From Source

But first, let me outline the problems I was having. Initially I tried building ImageMagick from source. That meant first downloading and installing Boost, which again I tried doing from source (1.46.1). When it became time to install the Boost::Python module, I tried following the instructions in the documentation: 

$ cd libs/python/example/quickstart/
$ bjam toolset=darwin --verbose-test test

However, I’d find it would get so far and then just hang – I left it for about 24 hours with no progress. If I hit Ctrl-C and then tried again, it just sits there saying this: 

...patience...
...patience...
...found 1603 targets...
...updating 8 targets...

Problems Using MacPorts

Since I couldn’t get very far that route, I decided to try the MacPorts approach, which makes installing these kinds of things very straightforward.

Again, first I had to try and install Boost, with the Python module enabled: 

$ sudo port install boost +python26

So far, so good! That installed the package “boost @1.46.1_0+python26”. Next was to install ImageMagick: 

$ sudo port install ImageMagick

Again, nice and smooth! That installed “ImageMagick @6.6.8-1_0+q16”. Now came the hard part: building PythonMagick. I used v0.9.3 since that seemed the latest version compatible with Python 2.x. The first step is to configure it. Reading around it became clear that I needed to specify the MacPorts include and library directories, like so: 

$ ./configure --prefix=/opt/local CPPFLAGS=-I/opt/local/include LDFLAGS=-L/opt/local/lib

But no matter what I tried, I kept getting the message “checking whether the Boost::Python library is available… no”. Eventually I figured out that you can get more information by reading the config.log file. I was getting all sorts of error messages like this: 

configure:14953: checking whether the Boost::Python library is available
configure:14983: g++ -c -g -O2 -I/opt/local/include conftest.cpp >&5
In file included from /opt/local/include/boost/python/detail/prefix.hpp:13,
from /opt/local/include/boost/python/module.hpp:8,
from conftest.cpp:23:
/opt/local/include/boost/python/detail/wrap_python.hpp:50:23: error: pyconfig.h: No such file or directory
/opt/local/include/boost/python/detail/wrap_python.hpp:75:24: error: patchlevel.h: No such file or directory
/opt/local/include/boost/python/detail/wrap_python.hpp:78:2: error: #error Python 2.2 or higher is required for this version of Boost.Python.
/opt/local/include/boost/python/detail/wrap_python.hpp:142:21: error: Python.h: No such file or directory

These pyconfig.h and Python.h files and so on are usually installed with the Python development package, but supposedly MacPorts just installs everything all together under /opt/local/include/python2.6, so I wondered what was going on. But somebody put me on to a good way to find out where MacPorts has put stuff: 

$ port contents python26 | grep pyconfig.h

That revealed that the include files were being installed in /opt/local/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6. So let’s try the configure again with that new information: 

$ ./configure --prefix=/opt/local CPPFLAGS="-I/opt/local/include -I/opt/local/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6" LDFLAGS=-L/opt/local/lib

Success! All seems to have worked this time – it picked up Boost::Python and no more errors showed up (I have secretly skipped a step where I installed the MacPorts python_select package to make sure that it was definitely using Python 2.6, but hopefully you can figure that one out on your own).

Building PythonMagick

But alas, not so easy. Next I had to actually compile the thing. And of course, it failed: 

$ make
_Image.cpp: In function 'void Export_pyste_src_Image()':
_Image.cpp:89: error: address of overloaded function with no contextual type information
_Image.cpp:90: error: address of overloaded function with no contextual type information
_Image.cpp:97: error: address of overloaded function with no contextual type information
_Image.cpp:114: error: address of overloaded function with no contextual type information
... and many more such errors ...

It would seem that the ImageMagick API has changed a little, but thankfully the PythonMagick guys have patched that in the latest version. So I had to download PythonMagick 0.9.5 and copy the following files from it into the ‘pythonmagick_src’ directory of 0.9.3:

  • _Image.cpp
  • _DrawableDashArray.cpp
  • _DrawableMiterLimit.cpp
  • _DrawableViewbox.cpp
  • _Geometry.cpp

Installing PythonMagick

With that done, it then compiled quite nicely. So I run ‘sudo make install’, but then when I actually try and load it into Python, I get this error: 

>>> import PythonMagick
Traceback (most recent call last):
File "", line 1, in 
File "PythonMagick/__init__.py", line 1, in 
import _PythonMagick
ImportError: No module named _PythonMagick

Hmm… So close! Yet so far away. Okay, well maybe I should just try adding the path where the module is installed to my Python path: 

>>> import sys
>>> sys.path.append('/opt/local/lib/python2.6/site-packages')
>>> import PythonMagick
Fatal Python error: Interpreter not initialized (version mismatch?)
Abort trap

D’oh! Well, a quick look at the crash log revealed that it was now trying to use the version of the Boost libraries that I’d manually installed from source from ‘/usr/local/lib’ (rather than the MacPorts version in /opt/local/lib) so I deleted the unwanted versions and tried again. Then I got this error: 

>>> import PythonMagick
Traceback (most recent call last):
File "", line 1, in 
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/PythonMagick/__init__.py", line 1, in 
import _PythonMagick
ImportError: dlopen(/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/PythonMagick/_PythonMagick.so, 2): Library not loaded: libboost_python.dylib
Referenced from: /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/PythonMagick/_PythonMagick.so
Reason: image not found

Well that one’s obvious: I needed to add the MacPorts directory to my library path: 

$ export LD_LIBRARY_PATH=/opt/local/lib
$ export DYLD_LIBRARY_PATH=/opt/local/lib

That gets me a little further: 

>>> import PythonMagick
Traceback (most recent call last):
File "", line 1, in 
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/PythonMagick/__init__.py", line 1, in 
import _PythonMagick
ImportError: dlopen(/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/PythonMagick/_PythonMagick.so, 2): Symbol not found: __cg_jpeg_resync_to_restart
Referenced from: /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/ImageIO
Expected in: /opt/local/lib/libjpeg.8.dylib
in /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/ImageIO

A bit of searching on Google eventually turned up this page that involves an egregious hack relying on case-insensitivity in Mac OS X: 

sudo ln -sf
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib /opt/local/lib/libpng.dylib
sudo ln -sf
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libTIFF.dylib /opt/local/lib/libtiff.dylib
sudo ln -sf
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libJPEG.dylib /opt/local/lib/libjpeg.dylib

Still…. it seems to work, and I can now import PythonMagick into Python! Now I just need to test it.

coding for christ

Humility in the Search for God

N.B.: This is a follow-up post to Why Programmers find it hard to be Christians.

Last week’s post on Programmers and Christianity generated quite a lot of debate, both here on the blog and over on Hacker News. Obviously when you write a post like that and post it to a secular programming forum, you expect a good deal of disagreement and healthy discussion. But even so, I still found myself surprised at how dismissive many of the commenters were. The most common response to the post is exemplified by this comment:

Why do programmers find it hard to be Christians? “Simple answer: it becomes increasingly difficult to ignore reason and logic when you spend most of your time using it”

disagreement.jpg

In other words, you have to dispense with logic and reason to be a Christian, and that’s not in a programmer’s nature. Many people resorted to a kind of ad hominem retort: the very fact that I’m a Christian seemed to disqualify me from being worthy of their attention, because it inherently demonstrated a poor grasp of how logic works (in fairness to Hacker News, the quality of the debate over there was much higher than on my blog itself, but some of the same attitude was still evident).

Ultimately, I think that kind of attitude is arrogant – it assumes that we know it all already and that there might not be another side to the argument that we hadn’t considered. But had I stopped and thought for a moment, I shouldn’t have been surprised at that response at all. And I don’t just mean because this is the internet! Jesus himself taught that this is exactly how the world works:

“Jesus rejoiced in the Holy Spirit and said, ‘I thank you, Father, Lord of heaven and earth, that you have hidden these things from the wise and understanding and revealed them to little children; yes, Father, for such was your gracious will.'” (Luke 10:21)

According to Jesus, to have too high an opinion of ourselves – to think of ourselves as being “wise and understanding” – is a serious barrier to seeing clearly. If God does exist, then he isn’t there as some kind of logical equation that we can just figure out if only we put enough thought into it. Jesus says that it requires revelation for people to come to know God – the fact that he isn’t visible to the naked eye means that he is impervious to even the greatest systems thinker on the planet. We can only know as much about him as he has chosen to reveal to us.

I imagine that many programmers reading this right now will be utterly riled by such a claim. It seems so convenient! But take a deep breath and think for a moment. Be humble enough to admit that you might not have all the answers. It has to be this way, doesn’t it? Jesus rejoices in the fact that it takes revelation to know God. It’s a great leveller that means we’re all on equal footing before God – nobody can claim to have figured it out by their superior intellect. And it means that we’re not reduced to mere guesswork – hoping that we’ve not made any errors in our deductive reasoning and ended up with a completely false view of who God is.

None of this is to say that Christianity is irrational or based on mere superstitious belief. As far as I’m aware, it’s the one religion in the world rooted in falsifiable, historical events – the life, crucifixion and resurrection of Jesus. Present the dead body of Jesus and we can all pack our bags and go home. But reason alone can only take us so far, and unless we acknowledge that fact and seek God with an attitude of humility like a helpless child, then Jesus says we will never be able to know God for ourselves.

coding for christ, Featured Posts

Why Programmers Find It So Hard To Be Christians

Say anything related to Christianity in an online community of programmers and you’ll quickly discover how unwelcome you are. Partly this is due to the influence of secularism – there’s an implicit understanding that Christianity has absolutely nothing to do with programming and therefore you’re simply way off topic (a subject I intend to come back to on this blog). But is there something more going on? Is there something about the programming mindset that makes us especially resistant to organised religion in general, or evangelical Christianity in particular?

Faith and the Fear of Inconsistency

Michael Lopps has a brilliant summary of nerds as essentially being “systems thinkers” – we love to analyse complex systems and figure out all the rules that make it work, what’s going on underneath the surface to produce the behaviour we observe on the outside. We feel safe in the world by constructing these mental models to explain things, and when they deviate from our expectations – when something breaks one of our rules – that’s when the nerd rage kicks in and we start to panic, as though our safety net is beginning to unravel. Nerds love consistency, because where consistency exists there can be understanding, and where understanding exists there is security.

But so often faith is presented as the enemy of consistency. Programmers absolutely hate it if you ever say “I don’t have all the answers to this theological conundrum but I trust that God is good and so I’m content to believe his word on it” because it allows God to have a “get out of jail free” card that lets him bend the rules of the system whenever he pleases. If there is a supernatural world out there – a world where divine beings exist who we cannot see and therefore cannot understand, and where dead people come back from the grave – then that’s a world which defies all my mental models and lacks the consistency I crave. It’s a world I cannot control, and therefore can never feel entirely safe in.

Not Invented Here Syndrome and Organised Religion

Our ability to grok an overview of a complex system also tends to produce a certain amount of smugness in your average programmer. We like to think we’ve arrived at a level of understanding inaccessible to lesser mortals, and although we’re eminently open to argument if someone wishes to present new data we hadn’t factored into our models, the idea of buying wholesale into somebody else’s model doesn’t sit easily. Partly that’s because half the fun is in the challenge of working it out for yourself, but also because the effort involved in fully understanding their solution often seems like more work than just figuring it out for yourself. It’s classic Not Invented Here Syndrome. I believe that’s why it’s easier either to dismiss organised religion as unnecessary or deride it as being motivated by factors less worthy than the pure quest for truth. We come up with further models to explain away why people believe things that to us seem so obviously false – “it helps them feel superior to others”, and so on.

But as any seasoned developer will tell you, starting again from scratch is rarely the wisest course of action. God is the ultimate geek, the systems thinker extraordinaire, and so if he’s provided documentation for why the world is at it is then the competitive advantage will be with those who pay attention to it. But more than that, he’s invited us to hang out with him at the launch party – and I, for one, don’t intend to miss the opportunity.

coding for christ

Jonathan Edwards on Procrastination

A Summary of “The Sin and Folly of Depending on Future Time” by Jonathan Edwards

I’ve been doing a lot of thinking lately on the theme of procrastination and how hard it is not to waste the precious time we’ve been given. A friend of mine put me on to a very helpful essay by Jonathan Edwards, the latter day Puritan who lived during the 18th Century. The essay is absolute gold dust and well worth a read first-hand, but for many of us accomplished procrastinators, it’s simply too long! It’s also in somewhat antiquated English which doesn’t make it all that easy to read if you’re not used to the style. So I thought it would be helpful to write a little summary of the essay in simple English – I hope fans of Edwards won’t find this too offensive!

Though it’s of value to all people, whether religious or not, the essay is essentially a sermon on Proverbs 27:1:

“Do not boast about tomorrow, for you do not know what a day may bring.”

Even if you’re not normally a fan of the Bible, I think there’s some real wisdom in here that bears a moment of consideration – so do keep reading.

Three quick words of explanation:

  • The verse starts with basic principle: “Don’t boast about tomorrow” – don’t rely upon there being a tomorrow; don’t act as though you own the future, as though you’re sure it exists and that you have control over what you can do with it
  • It ends with a reason: “You don’t know what it will bring” – anything could happen: you might die, you might get sick, the London Underground might be shut down by a snow storm, rendering your plans moot.
  • Edwards offers a caveat: in saying “don’t rely upon there being a tomorrow”, he doesn’t mean “rely upon there not being a tomorrow” – if you knew that today was your last day on Earth for certain, you’d neglect lots of responsibilities that are really important to take seriously (like paying off your mortgage), and perhaps do some things that aren’t the highest priority (like choosing the hymns for your funeral)

What It Means to Follow the Principle

To put this into practice (“Don’t boast about tomorrow”) will involve two things:

  1. Don’t rely upon certain things happening tomorrow, and put things off until they do – “I’ll finish off this essay during that free slot tomorrow”, “I’ll wait until my student loan comes through and then do X Y Z…”, “I’ll survive until the Christmas holidays and then get my morning Bible reading back on track” – who knows if the situation will really be as you expect by that time, and if you’ll still be inclined to do those things when that time comes around
  2. Don’t rely upon having a tomorrow at all – life is a mist, and who knows if you’ll still be here?

Some Examples

Here are some examples of what it would look like to rely upon future time:

  1. You might be obsessed with ‘things’ as though your happiness depended upon them – if only I have that relationship, that gadget, that job, then I’d be fulfilled. Of course we’re to enjoy stuff where possible, but we must hold them lightly as fleeting gifts from a good God, who himself is the only lasting source of fulfilment and happiness. Those other things might be gone by tomorrow, and can never bring lasting joy.
  2. You might be proud of your circumstances, your possessions or your good looks – but you ain’t gonna be able to keep them!
  3. You might envy other people for how easy life seems for them or how much people admire and respect them – but their situation might be changed by tomorrow, so isn’t worth craving.
  4. You might merrily continue a way of life that you need to be rescued from – presumably because you imagine you can be rescued another time?
  5. You might fail to do something that must be done before you die – this is the classic “I’ll repent on my deathbed” fallacy
  6. You might do stuff today which is going to need undoing – perhaps you’re busy defrauding someone on the hope that you can make restitution later?

Why We Shouldn’t Rely on Future Time

The reason why it’s daft to rely on future time is simple: we have absolutely no grounds whatsoever for relying on that future time existing. God hasn’t promised that we’ll live to see tomorrow, and nor can we rely on it. As much as modern medicine may have lulled us into a false sense of security, people still get sick and die suddenly, even at a young age. Accidents happen. There’s simply no reason to presume that we’ll still be here tomorrow.

Some Tests

Edwards offers the following tests for whether we might be relying on tomorrow:

  1. Do you set your heart on ‘things’ more than you would if you knew this was your last day?
  2. Wouldn’t you stick your nose in other people’s business less if you knew that you were going to have to give an account of your own affairs tonight? Wouldn’t you be a little more concerned about how things are going in your own life?
  3. Wouldn’t you be less obsessed with rivalries between the various clans you support and oppose? What does it matter whether iOS is better than Android or Arsenal is better than Chelsea if there might be no tomorrow? Even the most fierce rivalries will be ended by death: dead men are entirely at peace as they lie side by side in the cemetary
  4. Do you ever do things, coming up with arguments to convince yourself that there’s nothing wrong with them, that you’d never dare to do if you knew you were facing judgement tonight?
  5. Do you do stuff on the assumption that you’ll repent afterwards?
  6. Do you fail to make the most of today as though it might be your very last opportunity?
  7. Do you base your security for eternity on less-than-certain foundations? Have you ever really looked into Jesus’ claims firsthand before deciding there’s no hell? If God were to ask you “Why should I let you into heaven?”, is the answer you’d give certainly going to be enough to get you in?

If you answered ‘yes’ to any of these things, it’s probably a sign that you’re relying upon there being a tomorrow.

How to Spend Every Day

So how should we live our lives? Well, the massive advantage of not being told exactly how long we’ve got left is that it enables us to live every day as though it could be our last – that we should be ready for the end to come. You could be dead by this time tomorrow – you’ve no reason at all to rely upon it being otherwise. As you’re about to open that Facebook tab or check your email one last time, remember that it might be the last thing that you ever do.

Here are two motivations to stop relying on future time:

  1. If you really lived as though today might be your last, imagine how much more peace and security you would feel (and genuinely possess), both about your life and your death. No more feelings of guilt about the things you haven’t done, no more danger of meeting God unprepared.
  2. How much unnecessary stress is caused by our procrastination, and how many souls are needlessly condemned to eternal judgement because people keep putting off the inevitable and relying upon future time. Consider the five foolish virgins in Jesus’ parable: when the bridegroom showed up they were surprised, and found unprepared, having no oil in their lamps. And while they were at the shops to buy more, the five who were ready went in with him to the marriage; and the door was shut against them, and they came afterwards crying in vain, “Lord, Lord, open to us.”
coding for christ

Balsamiq FTW!

I’m really behind the times here, but in the last few weeks I’ve been playing around with a great little product called Balsamiq Mockups. It’s dead simple, and allows you to quickly and easily create… well… mockups, be that for your user interfaces or your web pages or whatever it is that needs designing. I’m currently using this to sketch out what kind of content we want on the new Proclamation Trust website before we let some designers work on the look and feel. Doing mockups like this is a great way to help everybody on the team understand what I’m up to and to give their input, even the totally non-technical ones.

Balsamiq comes with a great big palette of common UI elements, and then you just drag and drop them as you want. It all has a pleasing hand-draw feel to it, which helps remind everybody that this is just a mockup, not the real thing (you just know how managers love to assume you’re nearly finished once they see an authentic-looking UI screenshot!)

balsamiq.jpg

Best of all, the team at Balsamiq are mad about customer service: they respond to support requests quick as a flash and are obscenely generous!

You can try it for free online, and if you haven’t yet taken it for a spin then I highly recommend you do!


coding for christ

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?
coding for christ

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!

coding for christ

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.

coding for christ

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.

 
coding for christ

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!

coding for christ

Tips for taking over someone else’s code

1 Comment

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.

coding for christ

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
coding for christ

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.

coding for christ, Featured Posts

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.