I hate the word “geek”

[I wrote this approximately 2007. I originally had this as one of my thoughts about tech on my main harrywood.co.uk ‘tech’ section. Now demoting it to the blog archive]

In a world of ‘geeks’ and ‘normal people’, I never want to be thought of as a geek. It reduces my chances of getting laid. But this is not the only reason I hate the word. I hate the separation that the word implies. I can’t deny that this separation exists, but really there shouldn’t be ‘geeks’ and ‘normal people’. We should all learn to live and work with technology together. If some people are learning slower than others, or getting left behind, then we should pick them up and help them along. That’s my ideology, and I try reflect this in the way I work.

But it doesn’t surprise me that some technologists embrace the word ‘geek’, and actually wear the label proudly. As someone who has taken the time to learn a lot about computers, I know it is possible to develop a superiority complex; to see yourself in an ivory tower, or a member of an elite club. I think many I.T. people fall into this mindset, and take it too far. They just love to type gobbledygook unix commands, or work on files full of unintelligible code, so that if anyone should look over their shoulder, they would have no idea what the guy is doing, and would have to conclude that this guy is smart. I’ll admit to getting a little buzz from this myself on occasions, but I try to be motivated by the opposite desire, to help make technology less of a barrier, less mysterious, less geeky.

Whitewater Kayaking

[This was originally a top level harrywood.co.uk website section, written approximately 2007. Moved to the blog archive]

Middle Cheakamus, British Columbia

Whitewater kayaking is a big hobby of mine. I have been kayaking fairly regularly for the past five years. This is thanks to the good people at Imperial College Canoe Club who lent me the necessary equipment, taught me the necessary skills, drove me to the necessary rivers, and fed me the necessary beer/chilli fuel. It always impresses me that this group of people can collectively organise the club and the trips, coping with complex logistics and unforseen circumstances, maintaining a culture of sensible attitudes towards whitewater saftey, and at the same time have a whole lot of fun.

I’ve also been whitewater kayaking with Kanu Club Limmat while I was working in Switzlerland. I went along to the local club in Baden, not really knowing what to expect. Happily I met a friendly bunch of Swiss kayakers. They were older than me, with big moustaches and families and such things. I had a lot of fun with them though. We did some hardcore alpine whitewater on a couple of weekend trips, and what’s more, it turned out the local river Limmat had some interesting playspots, including a wave which can get very big. I took a trashing on it, during my final run, and returned to London in shame.

Maintainable Software

[I wrote this approximately 2007. I originally had this as one of my thoughts about tech on my main harrywood.co.uk ‘tech’ section. Now demoting it to the blog archive]

The key to creating maintainable software, is to write clear code, with comments and meaningful variable names. Not exactly the most earth shattering statement I know. But here’s a couple of interesting things I’ve noticed…

Ask any programmer if they write comments and choose meaningful variables names, they will nod earnestly, and agree wholeheartedly that this is important. But if all programmers are so good at creating maintainable code, where is all this unmaintainable code coming from? The problem is, it’s like asking a guy if he is a good driver. 90% of motorists consider themselves to be above average driving ability. The truth is many programmers see code maintainability (commenting etc) as a secondary task, to be addressed after creating the code, if they have time, rather than seeing it as a basic inbuilt part of the coding process. As for me, I always write maintainable code. You can trust me on this, because I can’t drive 🙂

Another big problem is project managers. They all read their project management books which say that a well run I.T. project has ‘technical documentation’ as one of the final deliverables. This becomes a priority, usually after the coding is done (we all know it should start as design documents written beforehand), but some project managers fail to realise the following. The purpose of delivering technical documentation is to make the system more maintainable, helping future developers. But under the umbrella of system maintainability, you really must start with basic code maintainability. If you pester your developers to jump through the document hoop, you may be asking them to describe spaghetti, which is difficult and time-consuming. If you ask them to ensure the code is maintainable first (conduct peer reviews), the result is code which the developers feel confident with, perhaps even proud of, and the documentation process becomes much less of a chore. But more importantly… You can deliver all the documentation you like, but if the code is spaghetti, any future developers are completely screwed!

It’s not just about future developers though. If code is not maintainable, then the programmers themselves will not understand their own spaghetti after a while. It only takes a week or so to build an unmanageable heap of spaghetti code. After that, any new features being heaped on top, will take longer and longer to develop, and will be more and more buggy. The same symptoms arise if a constant stream of change requests leads to a bad architectural structure. Either way, for any complex project, it is essential that code is kept tidy and well commented, and as I explained before, many programmers do not do this. If a manager doesn’t want to get their fingers dirty checking the code, they they should put a peer review process in place i.e. ask the developers to check each other’s code.

Games – Keep it simple

Computer games are fun, but since I’ve been working with computers I no longer find the time to be a keen gaming enthusiast.

These days I find my self gravitating towards ‘retro gaming‘ (playing old classic games), for three reasons:

  • While the new games are impressive, the modern big budget games industry is surely evil.
  • I can’t actually play the newest games at the moment, because I’ve not got a high spec PC or console
  • I find there’s something beautiful about the simplicity of older games.

Nostalgia is another reason. I wasted several years of my life playing on my BBC micro. But I think nostalgia is overrated. Even in a modern context, we should recognise the advantages of keeping games simple.

For years people have been making and re-making simple old style games. Increasing CPU power has made the programming challenge easier and easier, but also further and further from the state-of-the-art where the money is. These programmers were marginalised as geeky hobbyists, but I’m happy to see simple old-style games moving back into the mainstream, as some new technological frontiers have appeared in the past few years.

Web developers are paid to attract people to their website, with every trick they can devise. This includes attracting ‘casual gamers’, hence the new market for simple games which run on a web browser. Applet and Flash games are all over the web, and while these have a slightly perculiar (and not particularly retro) graphical feel, they often offer the same kind of simple entertainment fix that I love. As a java programmer I’m more tempted to try and make an applet game than a flash game, although the flash games seem to be better on the whole. I particularly like the unique and innovative SaltaCol.

An even newer technological frontier is mobile device games. Mobile phone games in particular, must be kept simple, for all the same reasons that the original old games were i.e. CPU and memory limitations. I have only tried a few of these, but I’m hoping technologies like J2ME will open up the market to many more small companies and amateur game developers, offering downloads of their funky little retro style games. (I’m tempted to try making a midlet myself). To fuel this fire the mobile manufacturers should really start java-enabling all mobiles as standard. Sadly it looks like the same story as WAP. Corporate greed is killing a technology which should really be free. In meantime this frontier is racing forwards. PDAs are already as fast as PCs, and capable of running quake (3D game), so the mobile retro gaming revolution may not last very long.

IT project politics

[I wrote this approximately 2007. I originally had this as one of my thoughts about tech on my main harrywood.co.uk ‘tech’ section. Now demoting it to the blog archive]

Previously I mentioned some people factors in my IT job, but project politics is probably the biggest. Working as an I.T. consultant seems to involve surviving a barrage or awkward political situations. Particularly when forming new working relationships at the beginning of a project, there seems to be a whole lot of sucking up to people, passing the buck, fending off criticism, criticising, bad-mouthing, and back-stabbing. It’s all part of the job, and it’s a game I have to play, but I must admit I’m not very good at it. I much prefer the situation later on in a project, when everyone has got to know each other, and people have judged each other on merit rather than just hot air. But even after working with people for over a year, the politics doesn’t let up. I still have to carefully judge when to push my ideas, when to put my foot down, and when to stay quiet. Obviously these are social skills which apply to all walks of life, but those who don’t know about the I.T. industry may not realise that my computer job heavily involves all of these ‘people skills’.

Everyone has their strengths and weaknesses

It’s the kind of thing your mother tells you, but I sometimes have to remind myself. It’s tempting to pre-judge I.T. people (their knowledge, experience, and abilities) based on first impressions.

Some people are very good at portraying themselves as brilliant I.T. experts. They will speak with an air of confidence, on a wide range of technology topics, and I form an impression that there is nothing they don’t know, and no skill they haven’t mastered. I start to compare myself, and to bow to them as an authority. Only after some time working with them, or after being left to work with their code, do I realise that they’re not so perfect. Nobody is. It’s one thing to talk the talk, but can they walk the walk?

Conversely, people sometimes slip up, make buggy code, or demonstrate surprising ignorance of some aspect of I.T., causing me to conclude that they are useless. In my more cynical moods I feel like the industry is flooded with useless people. Somehow they blag their way into I.T. jobs, when they haven’t really got what it takes. These people then drag down the standards of software, and push up the costs of I.T. projects, while the competent people struggle to compensate. This is true, except that increasingly I’ve come to recognise that everyone really does have strengths and weaknesses. Nobody is truly useless, it’s just that some people manage to hide their strengths. I.T. skills can never be all that black and white. To be a good team player you can’t just write off your co-workers as useless. You have to try to find their strengths.

One way I’ve come to this realisation is by looking at the situation in reverse. I consider myself to be far from useless, but I think there have been occasions when I’ve given a bad first impression, and people have far too quickly decided I am useless. Usually it’s possible to rectify this over time, by letting my strengths shine through …but who is at fault here? If I tried to make a good first impression, but just got unlucky, then my new team-mates are making a big mistake if they immediately write me off.

Clearly it is preferable to be the other type of person; to give the impression that I am better than I really am. This is smart way to go. But I am too honest for that (or not good enough at bullshitting), so I will probably continue to try to find a middle ground, to present a truthful first impression.


[This was originally a top level harrywood.co.uk website section, written approximately 2007. Moved to the blog archive]

Wikis are a great thing. Maybe I am not the first person you’ve heard raving about them, so I’ll try not to harp on about them in general terms, but for those who don’t know…

What is a wiki?

A wiki is a website where the text is freely editable by everyone on the internet. Through a process of community contributions the content keeps getting bigger and better. The editing system is simplified so that writing text, and linking between pages, requires no technical skill at all (a kind of CMS)


The prime example is wikipedia.org, a free online encyclopedia. This site is so popular that unfortunately it tends to slow down to a crawl when america wakes up in the afternoon. But go there in the morning look up the definition of some obscure word, or a random historical event. You will be impressed. Look at the ‘recent changes‘ and you can see the wiki is being edited by hundreds of people simultaneously (all these changes have taken place in the last minute or so!).

Here is a list of my contibutions to wikipedia.

A wiki is an ideal way to arrive at a community consensus on definitions of things, and so an encyclopedia site is the ideal application of wiki technology, and wikipedia is the daddy of all encyclopedias, but there are many other wikis around the web. Mostly they are trying to define things on a particular subject, and not doing a very good job of keeping up with the superior wikipedia definitions, but some of them attempt to build up different non-encyclopedic styles of information.


As a keen kayaker, I soon stumbled upon “kayak wiki”

Compared with wikipedia this gets extremely low traffic. Myself and Michael Daly (the guy hosting it) are pretty much the only people editing it at the moment. I think its a project with great potential, especially the “kayaking places” section, which I instigated. This could evolve into a giant free online kayaking guidebook. Building any kind of online community is a bit of a ‘chicken and egg’/’critical mass’ type problem, but some day soon kayakwiki will take off! [Update: Some time since 2007 Kayakwiki went completely offline. I think it got sp@mmed to oblivion]

WikiTravel WikiVoyage.org

If you like travelling, or if you just want to share your knowledge of a local area WikiVoyage.org is the wiki for you. It also has language phrasebooks. Like wikipedia, it seems to be very big and professional, with clearly defined goals, but unlike wikipedia you’ll quickly find areas where there’s scope for you to leave your mark, i.e. lots more travel guide information still to be added. There’s also some very interesting ideas in the map-making subproject. Here’s my contributions to WikiVoyage.org

[Update: Previously I linked “WikiTravel”. This still exists but the community moved to “WikiVoyage” under wikimedia’s wing (better)]


OpenStreetMap is a project which I understand the value of, due to my involvement in wikivoyage and wikipedia. These days publishing a map on a website is easy. You use google maps (or possibly the new Ordnance Survey offerings) but once you go beyond the flexibilities offered by the google API, or step outside the realm of straightforward web map display, you hit a very nasty issue of copyright. All of google’s maps are licenced from mapping agencies (such as Ordnance Survey in the UK). The underlying information is all heavily protected by copyright, and there is no easy way around this.

OpenStreetMap is project to provide open content maps. The only way to provide them, is build them from scratch. Without using any existing copyrighted maps, people like me are going out and surveying the streets using GPS receivers. It’s a brute force solution to the copyright problem, which will seem ridiculous until you follow through the reasoning.

Some enthusiasm for the project is fed by the wiki community, who aim to conquer these final frontiers of free and open information, but the project is wiki related for another reason, in that the map editing process of the project is itself modelled on wiki principles. Everyone can get involved in contributing to the map, and correcting each other’s edits.

A third wiki aspect to this project (and actually this has been my main area of contribution) is the OpenStreetMap wiki. A conventional MediaWiki installation used for describing the project, documenting the software, and coordinating mapping activity.

Wiki sp@m and chongqed.org

Everyone knows what email sp@m is. Well wiki sp@m is worse. The community carefully builds up some informative articles, and then along comes a wiki sp@mmer, and dumps a load of advertising links on the page, often completely destroying the text that was there before. It’s not permanent damage, because any change can be reverted, but it’s pretty annoying, and slightly depressing, that such inconsiderate people exist in the world. [Update: Originally I linked chongqed.org here, since they were finding interesting ways of fighting this menace. Sadly they are no more]

Wiki Obsession

As you can see I’ve been on a journey across several wiki projects, but actually you’ll find me getting involved in wiki communities all over the internet. I’ve become a little bit wiki obsessed. I think they appeal to my psychology because I get a buzz from collaboration and I am perhaps more altruistic than avarage. I am willing to chip in a little effort in the name of building something great. I’m also quite pedantic/perfectionistic when it comes to text (documents, websites etc) I sometimes find myself editing technical documents I’m working with, even when I know I can’t save my changes. If only all information was as freely editable as a wiki!

It’s a people thing

[I wrote this approximately 2007. I originally had this as one of my thoughts about tech on my main harrywood.co.uk ‘tech’ section. Now demoting it to the blog archive]

My job (and the kind of I.T. work I’m interested in) is actually all about understanding people. It’s really not about computers at all.

This is particularly true at the moment, because I’m working with ‘workflow’ software, which involves placing manual processing steps (people power) into the system architecture.

I am often involved in piecing together system requirements. Theoretically this should take place at the beginning of a project, but in practice it is an on-going process. It means building up an understanding of how people are going to work with the system, and what the stakeholders really want the system to do for them. Often a customer will tell me how they think system should be built, and I have to struggle to reverse-extrapolate the high level requirements (what the people really want). Sometimes I gently try to make this point. My experience as a software engineer equips me to make technical design decisions, i.e decide how a system should be built, but before I can do this, I need to know what the system should achieve, and how we want the people to fit in.

User interface design is a fascinating challenge. It’s such a subtle art form. You know when it’s done badly, and you know when it’s done well, but you can’t quite put your finger on it. When I try to justify a particular U.I. design, my arguments often end up seeming petty and insignificant. That’s because there is no right and wrong answers, only ‘good design’ and ‘not so good design’. It’s really all about empathy; Putting yourself in the position of people who have never seen this interface before. It’s also about striking balances. Laying things out so that it all just sits together elegantly. It’s …art.

Recently it’s come to my attention that many people are hopeless at it. This leaves me with an even greater challenge. Without having any any solid arguments, I should persuade these people that their ideas are bad. …but often I give up, and just implement the ‘not so good design’.

But probably the biggest “people” factor of my job is the project politics