For about two weeks, ending about two weeks ago, we had a full house of current employees at the SynthaSite offices in Cape Town - which has allowed everyone to get to know everyone else both at work and at play.  Over the past two weeks and continuing for another week or so, people have been heading back to the US office or heading to work from there for the known future.

The time together was great and necessary, and the time apart is necessary also, but it's hard to not want to see my new and old friends at the office.  The offices feel too quiet (although we've got new friends starting next week).

It is early days yet, but I know from previous experience how distance can allow one to treat people unfairly - it is easier to disappoint and easier to pretend to forget and easier to believe that the other is being stupid or lazy when you don't see each other regularly.  Yes, even geeks.

I'm quite interested in the challenge of making this not happen, and I'm hoping to see how our experiments in project management and communication and structure turn out.

I identified tools, process and people as our main strengths that will help us get through this new period, and then realised they were also our greatest challenges.  It's amazing how much your outlook can affect how you feel about a prospect like this.  If you start out, like I did, with "We've always been good with tools, but...", it leaves you feeling like you're entering a big unknown without much help.  But if you say "This might mean having to retool somewhat, but we've learned a lot about getting tools right", it makes you feel up for the fight.

I'll try write up my observations as they happen - although this recent three week break wasn't for lack of things to write but more for lack of the energy to write.  (I'll try catch up, but no promises...)

This past week at SynthaSite has been the first with the full newly-expanded international team together in the Cape Town office. This has been an opportunity to get to know the new hires and for everyone to come together with their ideas and come up with goals, plans, and specifications. Which meant a week with at least one meeting going on at any one time.

A big potential challenge to new hires, especially in management and other senior positions, is balancing their ability to contribute new things to your existing team but not getting swept away with them and hurting the common thread in your team. I must admit that I was a little worried about the decisions being made in meetings I wasn't a part of. This is a bad habit I've picked up over the years, and despite all indicators to the contrary and belief in those involved in the meetings, I couldn't entirely shake it.

On Thursday, the outcomes from the various meetings over the past few days were presented to the whole team. The most striking part of the meeting to me was how those who weren't in the earlier meetings were able to accurately predict the long-term and short-term goals and features and markets and so forth that were presented. The next most striking was how flexible and accepting those who'd spent hours in meetings to come up with these outcomes were of additions and removals from what they presented.

That was a perfect precursor to our reward for the week's work and a celebration of meeting a few internal targets in the last month — a boat trip out from the Cape Town waterfront on Friday afternoon.

Such a trip does have the potential to be a disaster — making a bunch of people wet and cold, forcing them to maintain their balance and their stomach, and otherwise messing with people isn't the best setting if there are issues between your people or if there's nothing binding them already. We did have new hires, after all.

But our new hires are much like the rest of us. No suits or fancy clothes when we're all office-bound. Shoes are optional. But when it comes to work, serious. More experienced than most of us, and older than most of us, but with the same youthful excitement and wonder for the space we're in and what we're doing. They're also just nice people — I've enjoyed watching every possible combination of new and old employee having multiple one-on-one conversations over the past week.

So, no disaster.

The boat trip itself was a lot of fun for me, despite getting absolutely soaked and nearly falling overboard a few times. I guess one has to do it to understand how that can be enjoyable, since I can't think of much to say in explanation. We ended up cutting the trip a bit short to avoid the setting sun and the ensuing cold and to rather have a warm supper in a warm restaurant. The review and exchange of photographs meant many laughs all around, and the shared adventure meant ample topic for discussion.

Greg Wilson has been posting interesting things about SIGCSE'08, the conference of the Computer Science Education special interest group of the ACM.

The most interesting of the many many posts is one on the struggles of new graduates, relating a presentation given by Andrew Begel who researched what new graduates got up to when they start their jobs as software developers.

I haven't had especiallymuch experience in terms of identifying and working with new graduates - generally the people I've worked well with and hired already had quite a bit of experience before we met.  But I love the idea of helping someone navigate that early part of their career.

There are two classes of mistakes that happen. 

• The first is that the new graduates need to identify those people that they can confidently interact with and learn the unwritten rules of the environment from, as well as bounce their own ideas off of to get feedback. 
• The second is where the  environment puts new graduates into situations where they can't rely on their existing skills.

As noted, new grads generally get put onto existing projects which have their own politics and problems - usually that the project is late, is over budget, has been poorly managed, has been poorly documented, and, often, has been poorly developed by people that no longer are on the project (and, often, no longer at the company).  Not exactly the smooth introduction to the rewarding career as a software developer...

While they may know the basics of version control, issue management, and so forth, they often have to blindly fight through many unwritten rules that apply to this company and this project.  Each person they interact with is going to require different things from them and also hold information that they might require - they're unlikely to have been taught the soft skills necessary to firstly determine clearly what everyone wants from them, and to communicate what they will do and what they need from others.

I'm tending towards thinking that new grads and those new to the sort of environment you're in (say, worked in industry but not academia, or worked in small company in-house development but not large-scale financial services bespoke work) need a "big brother" assigned to them formally to teach them the ropes and through which any feedback on their performance is handled.

This way the new grad has a single person telling them the good and the bad, in a constructive and trusted manner.  The new grad knows who to ask for help when they need it - whether it's where something lives or how best to interact with the various personalities in the team.

This still leaves the problem of how to identify and train this "big brother" - but that's a problem to be pondered another time.

One of the interesting upcoming challenges at SynthaSite is the migration of parts of the company to San Francisco, while leaving what is currently the bulk of (and, interestingly, the newest additions to) the company behind.

But most of those challenges are around "soft" issues like effective communication and retention of culture, and while I hope to be able to figure out important lessons around that in future, now I mostly want to express my surprise at how little the technology - hardware, software, and network - stands in the way of this move.

When the move was first discussed (admittedly only days after I arrived), I was told I'd probably need to go over to San Francisco for a few weeks to help the rest of the team set up.  And, well, that sounded about right.  As a company that develops software as one of its main functions, and as a company that needs accurate business information for business development, "customers" (ie, people who sign up for free to create their own web sites), and "sales leads" (ie, people who we want to sign up for free to create their own web sites), and as a company that has particular needs in terms of informing and satisfying investors, we need a lot of tools.

Tools for project management, issue management, support, team collaboration, revision control, building, testing, deploying, scheduling, mail, company information and documentation, and plain old file sharing.  And that's just the stuff I use on a daily basis.  Business also has and needs tools.

However, it seems that that estimate of a few weeks was way off.  Being able to work effectively from an office in San Francisco and being able to work effectively from your home in Cape Town and being able to work effectively from wherever you find yourself aren't particularly different. 

Because we've had people who've had to travel a lot, and because we have people who would rather work from home and actually see their kids (whether human or canine) every once in a while, we're almost entirely ready for this change - almost all of our tools are already not in our Cape Town office.

So, while I might like a chance to see the new offices and catch a conference (The Python community conference, PyCon, is in Chicago roughly around the time we'll be setting up offices, after all), there's not much I need beyond a IP-over-KVM system and one (or, at a stretch, two) servers for things that need to be in the office (like a file and backup server), and I can do the whole thing from Cape Town.

This situation is just a fortuitous coincidence - the attitude towards tools at SynthaSite has always seemed refreshing and enlightened.  If it's needed, get it.  If it can be externally managed, do that.  I get the sense that the few tools that aren't externally managed are being eyed carefully every once in a while for potential replacement or a move to a managed solution (much like what we did with our support system).

(Of course, to those from outside South Africa, this may come across as absurd or just obvious.  Having been stuck with poor connectivity in the past, it's never seemed reasonable to rely on external, especially international, services.  And still being stuck with pretty poor connectivity, we can't reasonably host tools in South Africa for our international team mates.)

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.

Since the beginning of the year, I've been trying to distill some lessons from some of my failures on KnowledgeTree.  Part of this process has been doing a lot of reading about development - to make sure that I'm not seriously out of step with my underlying beliefs, and to see how I can improve on what I've done before.  Most of this reading, strangely enough, about project management.

I've reread the staples on the subject - The Mythical Man Month and Peopleware - with a deeper understanding and finding greater resonance in this reading - I assume due to increased experience.  And I've also read some more recent texts; the latest is Scott Berkun's The Art of Project Management, which Brad recommended.

This isn't a review of the book, but I feel I must say that this book is probably the most succinct instruction book on how to get a team to deliver a project, no matter what technologies they use or what development methodologies or business processes exist.

I like how Berkun starts by defining his use of "project manager" as being "whoever is involved in project leadership and management activity", and offers that some people might want to translate it as "person thinking about the project at large".

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.

This person doesn't have to be a project manager or the "lead" developer.  It could be a designer, for example, who feels excited by the prospect of delivering something worthwhile to the users of the project.  This person instills this excitement and/or caring, in some small way, to the rest of the team, and provides a degree of reward (it feels nice to make someone happy in addition to just doing your job).

Excitement and attachment, though, have their downside.  If the de facto leader is restricted from providing such leadership (even if it is only a perceived restriction) by the de jure management (for example, a project or line manager), problems start to appear that are hard to diagnose.  Things that "just happened" stop "just happening".  It becomes harder to make decisions or reach concensus about the project.  Things that were decided are forgotten, arguments about previous decisions start up again, and so forth.  Mostly, morale goes down.

My current experiment is trying to understand who holds the de facto leadership power in situations, and to understand my own role in things in terms of non-granted (ie, earned instead of granted) power - both in the past and going forward.  Even if I'm not right about defining the "project leader", this exercise has had some interesting results so far. 

Our so-far-only Google Summer of Code-r Charl van Niekerk noticed The WebAfrica API, which also has an official announcement on their web site, which starts:

We are proud to announce the immediate availability of our newest offering: The Web Africa API. This affords developers and advanced users the ability to directly, safely and quickly automate access to the various services and facilities we provide.

I'm growing a little tired by how the "industry" complains about lack of skills.  Now, they're saying software graduates are lazy.

I think the "industry" has a few problems.  Frankly, it's boring.  And, well, it's wrong-headed.  Why does "the industry" always look for a quantity of software graduates?  I've seen job adverts for "10 Junior PHP programmers", for example.  It's not unusual for a large number of people with similar, low-end, skills being asked for.  At the same time, there's a massive gap between that low experience level and the early-career experience level.

My first job was great.  I was well-paid, well-treated, and was surrounded by intelligent people.  Three rather decent jobs after that, I wasn't even earning the inflation-adjusted amount I was earning in my first job.  And, yet, somehow, a few months after that meant a difference of 40% or so in the salaries of the types of positions I was being asked to apply for.

I can only imagine it's as irritating for other people, working their way up between the fifteen billion other graduates that compete for the sorts of jobs you're able to apply to with your experience.  You're at least 20 times more effective than the average of those fifteen billion people, and somehow you're being extortionate for asking for 10-30% more salary.  And you need that salary, since, being interested in the field, you want to buy books, be online, and so forth.

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.

The worst reason I see for hiring more junior people is that more senior people - people with more love for the field - tend to move jobs, which is a lot worse than if you only have one or two of the ten people churning at a time.  But, frankly, look at the way you treat the more senior people, and you'll quickly find why they leave - because they're not given the things they need to perform.

Unless you're grossly underpaying your senior staff, they're likely to stay if they're treated well.   Sure, that may mean forking out more so that the development area is properly lit.  Or that the environment has enough air flow.  That the temperature is managed.  That there are enough plug points.  That there are two LCD monitors on their desks.  Heck, offices for every, or every two or three, developers, so that they're not constantly surrounded by noisy colleagues who sing along to music playing on their earphones, or are making sales calls, or who just talk to themselves loudly or discuss the cricket or how to make money fast with property with other members of the staff.  But, you'll find, they're worth it.  They're worth more than five other people, and don't cost five times as much.  And they're there and if you treat them well, they'll stay there.  And they know what they're doing already!  Less time wasted on training!

Now, people will say that I'm being elitist - that I'm not thinking about ways for junior people to join the industry.  Well, firstly, boo hoo!  Why should we care about all of the artificially high number of people who go into an industry for the wrong reason and into an industry that doesn't actually need them?  We should care about those that are in it for the right reason, and those that would be in it if given the opportunity.

With less chaff, there will be less competition for those that are in it for the jobs available.  Those that would be in it if given the opportunity are not a problem that is solved by having tons of low-experience jobs.  That requires work before they even decide what job they want to go into - they need to know that they're interested and/or suitable in it by then.

Of course, this does leave a lot of people who've been through all these courses and so forth without something to do.  Maybe we can buy all of them a series of books by W. Richard Stevens, Frederick Brooks, and Donald Knuth, and see who floats.  It'll be cheaper than the fly-by-night or utterly useless "programming course" they've been on and will go on again when they're conned into thinking it'll get them a well-paying job.