I work in the I.T. industry as an integration consultant. I also do a spot of computer programming and web development in my spare time, when the mood takes me. Sadly doing this stuff as a full-time job means that the passion becomes a chore, and so I rarely spend the time to bring my own ideas to fruition, but that's also because I have too many ideas. I see the world through software engineer's eyes. Everything is a potential new website, or the next killer-app.
The following is a collection of my thoughts about technology and the I.T. industry. I hope visitors who are not computer experts will also find some of this interesting, particularly friends, relatives, and people I've met, who have misconceptions about my work.
I hate the word 'geek'
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.
It's a people thing
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'.
of my job is the biggest people
factor. 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.
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.
Phew you made it to the end. I think I'm going to split these up into separate pages (probably with a wiki
content management system) at some point. I am also hoping to get around to adding some less philosophical, more techy articles/tip & tricks/tools downloads and details of some of my projects .
24th Mar 2005