Since April 2003, I've maintained this web log as a mixed-bag of posts about technology, about work, about my travels, about politics, and about books, movies, games, and other forms of entertainment.

Since just over a week ago, all my technology thoughts will be appearing on my new technology web log, TechGeneral.

Likely topics on TechGeneral are:

• open source (or Free Software, if you prefer),
• scalability,
• security,
• the Python programming language,
• technology events I'm interested in and/or attend,
• becoming a better developer,
• finding/hiring developers and other technology workers, and
• motivating and getting the most out of them.

I'll continue to maintain this web log, focusing on other topics:

• books, games, movies, and other entertainment,
• events I'm interested in or attend,
• travel inside and outside of Cape Town,
• experiences with people and organisations,
• random opinions on topics such as politics, and
• that blogging about blogging thing.

I've realised that the people who read my technology posts (predominantly outside of South Africa) probably don't care much about the other stuff.  The people who read my other stuff (predominantly inside South Africa) probably don't care all that much about the technology stuff either.

I hope this split helps improve the subjective signal to noise ratio for those who follow what I have to say.

[ The equivalent posting on TechGeneral is the first one, Welcome to TechGeneral. ]

Despite recovering from burn-out and malaria from previous years, 2007 turned out rather well.  I suspect I learned a lot more in 2007 than I have since the skipping lectures in university to hack on things all day.  And, finally, I get what this "experience" thing is about - it takes a while to have a few lessons sink in.

One big lesson, which I learned early on in the year, is how so much in the software development process needs to be about keeping everyone honest.

The programming stage introduces a level of honesty not enforced in earlier stages.  No longer can one hand-wave over how to achieve something, and there's nobody lower down the chain to delegate decisions to.

The most detrimental mistakes in the programming stage of a project are those that stem from ambiguity in the specification of the work to be done.  This is made even worse if the developers are not given the overarching vision and operating parameters of the project - so that they have a better than average chance to realise when an ambiguity actually arises - it'll just feel wrong.

If you've not managed to be honest in your previous stages in the development process, the programming stage is the most morbid phase for everyone.  For those involved in the earlier stages of a project, all they hear is that they've not done their job correctly.  (But, more realistically, I imagine they just think they have bad programmers.  It's amazing how easy it is to just blame it on the programmers for not "realising the vision" or not "knowing how to overcome technical difficulties" or just "being crybabies".)

For all employees, assuming you've not screwed up and not hired people who are good at their job or at least who are enthusiastic about doing their job well, you should practise small government.  Let the default position be that your employees should do their job with a minimum of overhead, with intervention only when justified.

If you want to make someone happy, make it possible for them to do their job the way they want to do them - for a lot of people, that means doing it properly.  Take them seriously when they talk.  If they complain about the light levels where they work, don't simply lament the situation - do something about it.  If they express disinterest in something, try find a way for them to avoid it.  If they think a particular book would be useful, buy it.  Be the facilitator of their success, the filter of outside forces, and the deliverer of praise.  Sure, you can't accommodate your employees every time, but make sure they think that you're doing what you can to avoid the company making their life difficult.

I contemplated what success is, especially in terms of technology within business.  Basically:

Success can't be measured only by what you have achieved - the resources, the accolades, and the good will.  More important than those, it should be measured also by what you can achieve from this point on.

I also became a lot more elitist, and decided that the IT industry in South Africa (and I'm sure elsewhere) are the major cause of the problems finding good IT staff - because they hire by quantity, not by quality.

The reason there are fifteen billion other graduates is because the companies are asking for quantity of staff, not quality of them.  People see lots of jobs open, and so decide to go "into IT".  Those people who go "into IT" because of the available jobs are just not worth as much as those actually interested in the particular subject.  10 low-experience programmers earning R5k a month (take home) aren't nearly as valuable as 2 higher-experience programmers earning R25k a month (take home), and the 10 low-experience programmers also cost more because they use more desk space, more parking bays, and so forth.

That's bad enough, of course, but now they're calling IT graduates lazy, because the average IT graduate probably is lazy, because the average IT graduate is in the wrong field.  If you want someone who isn't lazy, don't ask for 10 graduates - ask for 2 higher-experience people.

After a bit of a break, I started thinking more about project roles, and about some of the things I've got wrong in previous projects, and about non-granted and granted power in projects.

To me, it seems the project leader is the person who lives the project - the one who has the clearest idea of what the vision of the project is (and probably the goals), and who keeps this in mind in approaching every decision that is made.  The leader is the person who cares the most about the project, and who seems to make the most cogent arguments about the project as a whole ("Which feature should we drop?", "How do we best fulfil the spec in this case?", and so forth), and to whom these questions tend to become asked of first.

The last third of the year was dominated by thoughts of StarCamp.  Growing the pool has become a passion of mine - because I think there's a tipping point around the corner for South Africa and especially Cape Town in terms of technology innovation, and it needs a bit of help to come sooner.  It needs for people who are interested in technology innovation to know of each other, so that they can team up, and so that they can be counted.

Growing the pool is making new connections, bringing new people into the community, providing new people to learn from and new opportunities for work or play.  It isn't necessarily about bringing new people into the field (but it is a by-product) so much as it is about making everyone in the field more aware of each other.

...

Nobody is going to put on fancy conferences like SXSW, LugRadio Live, OSCON, Emerging Technology Conference, or Ubuntu Live, for us in South Africa until we show that there are enough people for such a thing.  And who wants somebody else's formula anyway? 

That theme continued when I thought on what made BarCamp Cape Town in 2006 so special, and realised why it needed to be a meeting of minds from all around technology innovation - not just geeks, but all the other people who need to be interested in the field and involved for stuff to happen.

One things that struck me about BarCamp Cape Town was the breadth of those who came - anything from hard-core C programmers through the Python/Ruby fanboys to more run-of-the-mill PHP programmers to those who couldn't program at all as well.  Those who work in marketing to those interested in it to those who find the entire field a bit distasteful.  Businessowners to wannabe-entrepreneurs to those who'd just like to code and have pizza slid under the door every evening.  It was a place to meet new people in your area of interest - existing groups weren't really growing the pool, and also a place for inter-pool connections to be formed.

Can't wait to see how 2008 unfolds... 

Return visitors may notice a slight difference today.  For the first time ever, I'm running a web site theme that someone else created.  While it's obviously better than my attempts, that's not why it's here (and who knows how long it'll stay).  I'm testing out the theme support in Gibe, my web log engine, which ended up not being particularly hard to do at all, thanks to the way TurboGears' expose decorator works, and a simple decorator of my own.

Over the weekend, the hard drive in the server most of my life is on died.  Well, about 1% of the data on the system is readable.  Amazingly, it's pretty much the most important 1%.

I have somewhat up-to-date backups (I was once a middling-good sysadmin, after all).  Backups that I haven't restored from, mostly because I've come to realise that I just don't care about that content anymore.  It's rather freeing, actually.

The hosting company I lease the server from replaced the drive and reinstalled on that drive (Goodbye Debian stale, Hello Ubuntu Dapper Drake with LTS).

The things that I thought I'd miss that I've found I haven't is my email.  Oh, I'll grab a copy of my aliases file for the people I want to keep in contact with, but the exact emails aren't all that important.  And, anyway, I'd already moved my mail life over to Google Mail (I'll write something up about Google Apps For Your Domain someday).

I recovered my 4.0.24 MySQL tables for gibe (the blogging engine for TurboGears I'm working on and this runs on), and for engal (the photo gallery for TurboGears I wrote).  I installed 4.0.24 (not a simple task via package management with Dapper, so I resorted to a custom install), discovered only the "visit" tables were broken, exported, and installed on package-managed MySQL 5 (on my way to PostgreSQL, of course).

I recovered my SVN repository from the disk itself, which contains my web site and all the code for gibe and engal.  The static resource content (mostly images of Dante linked to from my posts) was also all fine.

/etc was toast (Input/Output error if you tried to change working directory to it), which meant my exim and name server configuration and zones weren't recoverable from the drive.  But since I'd moved to Google Mail, everything was simplified, and I added back the backup MXs I run for friends.  The name server configuration was basically duplicated on another server, and that was about five minutes of work.

The backups are still useful - they're the "archive" of stuff I once thought was interesting.  I'll eventually get it whittled down to what I care about, and get it down locally (which may not make sense if you don't realise how bad Internet connectivity in South Africa is), and archive it here.

And, of course, if I never had the backups, I would almost certainly have not been lucky enough to be able to recover without using them.

(And, of course, this post will almost certainly cause people to notice that everything isn't perfectly put back together - but then, I'm counting on that so that I can find out about it... )