[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.

[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.

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.

[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.

[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