A tech manifesto from 2007

I’ve just been tidying some old content on this website, which I’d written just over 10 years ago now. Back then I wrote a kind of tech manifesto, or at least a collection of various broad thoughts of tech and the IT industry I was working in at the time. I haven’t worked as an enterprise integration consultant since 2009, and some of it is out-of-date in various other ways. Some of it feels like it’s noticeably coming from my naive younger self.

  • I hate the word “geek”. I don’t really hate the word of course, and that’s not the point I was trying to make. I stand by the idea that we should always work to close the separation between “geeks” and “normal people”. The march of technological progress does this for us of course. If I think back to 2007, the internet was actually a lot less mainstream. Fewer people with broadband at home (including me!). Fewer people required to use the internet or even computers as part of their work. It used to be that “geeks” were people who knew how to use computers and were super savvy with the internet. Nowadays that’s everyone. My 2 year old son is already getting the hang of it! Nowadays I see an interesting push to get more people from more diverse backgrounds to learn to code.

  • It’s a people thing was a piece complaining that clients should discuss high level requirements rather than skipping ahead to designing a solution. This is an accepted anti-waterfall principle rolled into “agile” these days. Perhaps it goes without saying, …except it’s still a common mistake. I recall a few occasions since writing that, when I’ve worked on projects which jumped to discussing a technical solution before getting a high level view of problems we were solving.

    I also talked about user interface design. I think I had a bit of a bee in my bonnet about the project I was on at the time, but I do remember leaving that particular project with great satisfaction at having implemented some of the UI ideas despite initially having them shot down. Since then there has been a couple of times where I’ve found myself surprised by colleagues’ failure to see obvious UI improvements. It makes me wonder whether user interface design is a talent I’ve not really appreciated within myself. Maybe I should do more of that kind of work.

  • With IT project politics, I was talking in general terms, but really I was bearing my soul about some frustrations with my consulting job. Some of the assignments with Green Hat Consulting involved parachuting into a pretty hostile environment. When I quit that industry and went to work in a more fresh funky start-up I left the politics behind on the whole, but of course you never really escape that kind of thing completely. I guess the golden rule I still have to remind myself of would be: work with people you like (and if you don’t, leave, because life’s too short)

  • Maintainable Software. Maybe I had a fairly simplistic view of what makes good software back then, but I think I was just glossing over the details. Obviously there’s a whole universe of coding best practices which make code maintainable, beyond “comments and meaningful variable names”. In fact comments are bad …sometimes. I think keeping up with recommendations and knowing which wisdom to follow and which to discard may be the real skill. Being an “opinionated coder”, and taking pride in your craft. In any case, I’m sure I was correct in saying that most developers consider their own code to be good code. …and I still didn’t learn to drive!

    I was also ranting about documentation. Again I think this was a bee I had my bonnet related a particular request to document a particular project at the time. But it remains a reasonable point, that documentation can be seen as an afterthought; a project delivery box to tick. I quite like documentation. The interesting challenge of trying to distill the most important hand-over information for a project, without making something which is just too long for anyone to bother reading. Also mechanisms to help ensure docs are kept up-to-date e.g. keeping docs close to the code or part of the code. I like that github have establish a nice convention of supplying a README.md file for each repo.

On the whole my “tech manifesto” of a decade ago wasn’t too bad, but a lot’s happened in 10 years, and some of these thoughts were starting to feel quite old. So I decided today that they belong in the blog archive.

But what would I write about if I were to pick some points to make about tech and the IT industry in 2017? (Not sure we even call it the “IT industry” so much these days). I don’t think I would try. Clearly such things are destined to go out of date. A single page of thoughts also feels incomplete, but maybe I should add some more deep thinking to the blog category ‘technology’