Our first SynthaSite new version deployment of the new year went live yesterday.  The most visible feature is our integration with Picnik, a cool Flash image editor/enhancer, so people can manage their images through the web instead of on their own machine with The Gimp or Photoshop or whatever.

We also added a toolbar to the widgets, to allow for commonly accessed functionality on a widget to be more easily found and used.  I think we made the right move with this one... 

Other features include being able to publish under your own domain but hosted on our site (you've always been able to download your site and host it yourself), being able to save copies of pages, and auto-saving.  We've got better about publically visible release notes too, with known issues in the release and workarounds.  Oh, we also redid the web site a bit, and I much prefer the new style.

It's been a learning process - which is to say that things didn't go perfectly smoothly.  But with our improving QA process in place, we managed to avoid all but one or two problems from being discovered in the deployment-to-live phase.

Improving process in a software team is hard - you can't change too many things at a time, and you can't change the same thing over and over.  You have to avoid trying to optimise something when it's good enough, and effort would be better spent elsewhere... or if the effort will cause churn and instability, hurting the confidence in the process.

We had our first bigger-team iteration planning session today.  I'd only been at two of these at SynthaSite so far, and I feel it was a much smoother process than the previous two.  As you can see on the picture of the iteration planning board, there's a lot of stuff planned for the next three weeks.

(My column, of course, is the longest.  And, well, filled with little things to help make everyone's lives more streamlined and pain-free.) 

I'm a bit late this month with my monthly calendar of Geek events.  Can't really get much more later and still be in the month...

Anyway, Frugal Fennel is the next GeekDinner, tomorrow (31 January), at Sloppy Sams along Somerset Road in Green Point, Cape Town.

We're already sort-of full, but if you put yourself on the reserve list, then when the occasional bunch of people remember that it's their spouse's birthday and pull out, you have dibs on replacing them.

It feels like ages since the last GeekDinner - probably the combination of having lots of holiday time and lots of hard work at both work and on StarCamp.  Can't wait to relax, see my friends, and hopefully make some new ones. 

Every time I come home, I put my wallet, keys, and cellphone at a particular location.  Whenever I'm leaving the house, or otherwise need one of them, I know exactly where they are.  The number of frantic searches for keys people who don't do something like this go through is scary, considering how easy it is.

Similarly, every time I work on code, I use version control, and commit working code regularly.  Like the wallet and keys above, looking around for code that you can't find (possibly because there are many copies of the code about) is such an obvious loss that changing your behaviour seems warranted.  If you don't realise it's a loss, hopefully you'll learn when you waste your time a few times doing something else.

You can't be a good developer or systems administrator or, I imagine, a bunch of other roles if you aren't confident.  When you've got version control you can be confident you can go on a tangent and mess the whole thing up and return back to a working state easily enough.  The value of unit tests is often said to lie from the confidence you derive from knowing that mistakes you make while changing code will most often be caught by the tests.

Part of the work I'm doing at SynthaSite is building confidence around the development process.  Each developer has a virtual machine on their system that matches the exact operating system and software configuration as in live.  They use a slightly streamlined deployment process, but they can be quite confident that whatever they develop that works on that virtual machine will work on live.

Just in case, we have another virtual machine that is an almost 100% mirror of the live environment.  Instead of the streamlined process, it has a full deployment process.  The build comes from a continuous integration server with a known configuration - nothing strange depending on which developer built it on which machine.  It has a recent copy of the live environment's variable data - databases, file resources, and so forth.

And, once that's done, you're almost certain that when you deploy the sofware to live that it'll just work.

Pride comes before a fall, though.  Today it went wrong.  I broke live.

The one consolation is that it's because I wasn't following the process exactly.  I tried to be clever.  I should've realised that trying to be clever is a sure-fire sign of the imminent performance of a stupid act.  I suppose one has to be reminded of it every once in a while.

Hopefully a very long while.

Your trust in your colleagues, business partners, or friends is going to allow you to be confident too.  If you know that you've got a safety net - that you can fail and those people will help you out and stand by you - then you can try pretty astounding things.  That's probably going to take a while to rebuild fully, but it's nice that the reaction to the problem was mostly constructive.

One of the worst things you can do to someone is to hold them to a standard that is unrealistic.  People react in two ways.  Some, perhaps most, won't feel up to the task after failure, lowering their confidence in themselves.  Others will lose their confidence in, and respect for, you, since they are confident in their estimation of how big a mistake they've made.

I guess this is why it's important to keep the latter group engaged with their work.  If they're excited by something, proud of it, invested in it, then they're going to regulate themselves well.  They'll consider it a bigger mistake, and will try to avoid doing so in the future.  If they're bored with what they're doing, tired of it, or just don't feel connected to it, then they won't feel all that bad about it, and they're not going to try as hard to avoid making that mistake again.  They're not going to come down on themselves much.  And, just like before, they'll wonder why you're overreacting - except that you and those not in such a lurch will consider it entirely reasonable.

When your colleagues or friends trust and respect you, you just need to apply a subtle amount of disappointment.  If they don't, you can either build those up in the long term with little improvements initially fairly spread out or make things much worse in the medium term in exchange for a few months of not-all-that-much improved performance and reliability.

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

I don't think I have enjoyed working as much as I have in the last two and a bit months at SynthaSite.

That's quite a statement.  I'm a bit surprised that I'm willing to say that.

I'm not sure of how much of that enjoyment is due to changes in me, but I know it's at least a non-trivial contribution.  Being burnt out last year after over two years of hectic overcommitment to KnowledgeTree and the emotional rollercoaster that entailed has meant many lessons have been learned.  Even though I'm not fully recovered, I think I've learned how to enjoy working again, and this started to be seen last year at CareerJunction.

StarCamp and the GeekDinners also have at least a non-trivial role to play - I'm not only enjoying work a lot more, but I'm also generally enjoying life more.  I'm very upbeat about Cape Town as a venue for technology innovation, and I'm enjoying meeting new friends, and interacting with my existing ones more.

It's strange - the work that I've been doing recently at SynthaSite would probably have driven me mad before.  I've been moving from a systems administration base eight years ago towards full-time developer/architect/lead positions at Independent Online, KnowledgeTree, and CareerJunction, but suddenly I'm doing what I'm sure I would've thought fairly lowly sysadmin tasks last year, and I've got no minions to boss around.

I've been thinking a lot about reward/response in the last 18 months (I'm sure I drove Brad, Bryn and Shaun crazy during this period).  I think a lot of the reason I'm enjoying working at the moment is that it has an obvious impact.  A large portion of the work I've been doing has been around process improvement - ways to make the lives of everyone in the company better.  It's easy to feel good about your work when your colleagues thank you for making their lives easier.

The work dynamic at SynthaSite reminds me a lot of the early days of KnowledgeTree as a serious project at Jam Warehouse.  Whether you are "management", have a title like "CTO" or "VP Engineering", or are just a lowly untitled employee, your comment is not only respected but expected.  I don't think I appreciated that feeling at KnowledgeTree enough, but having known it then, I can recognise and appreciate it now.

It's also nice to be surrounded by other people who are enjoying themselves - whatever their motivations for that might be.  Certainly, being in line to make some money if things go well is probably high on some of their lists.  For others, just the excitement of being on the start-up ride.  Perhaps it's the perks.  Or maybe just being part of a well-oiled machine.

Anyway, I think this bodes well for 2008, and hopefully some of you will be inspired to try enjoy working again, whatever that might require doing.