Lessons from 2007

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