Life Technology

Like A Simile

We use similes and metaphors quite frequently, particularly in software. Everything is so figurative and you spend all day coming up with names for things that are “like” real world objects. Of course, that’s not counting those things which are not like anything else other than what they are in software. This is not about them. And this figurative language we carry over into customer engagements too, explaining to our dear customer why the original quote does not hold since they subsequently added the kitchen sink and “tinted windows” 🙂 Not to mention explaining why that takes an extra ‘x’ weeks.
During one such session, it suddenly dawned on me halfway through the metaphor, that the client started extending the metaphor and the proceeded to re-apply it back to the software project, taking it too literally, and ended up explaining to me how software works based on the metaphor at hand. Doh! And all i was trying to do was help educate and understand…

I think IT, in general, has come under heavy pressure to talk the language of the client- and indeed, we are encouraged to keep getting better at this. Make it more accessible so that they understand… Why?

I don’t understand that thing my dentist uses to fill a tooth; nor do i care about the gadget the plumber used to seal the pipes with; and yay for the structural engineer who … well, i really don’t know what he did. But i still use and pay for their services. Did they go to great lengths to explain the intricacies of their tasks? Nope. Did it matter. Not really. I engaged them- they told me how much and how long- i paid, they did it. Moving right along.

I think the more we “passively force” non-programmers to understand what we’re doing, the more confusion we sow. Particularly when the metaphor we use is so accessible, we have no idea how their experiences, assumptions and understandings will impact on the point we’re trying to convey.

As programmers, we owe it to ourselves to forge the language (jargon) we have created, not with the purposes of creating a divide, but so that we can just get on with the job, efficiently. Without the extra fluff. Of course, that’s not to say don’t make an effort to help a client understand, if they want to understand on technical terms. Dumbing it down doesn’t really help, except maybe in polite social discussions 😉

Jessie, aka Beanie

the miracle of growing is something else! watching Jessie grow is just, well, yeah.. wow. i could wax a compendium of lyrics and still not get close. just everything about discovery: from being fascinated by your own feet to the discovery of laughter and expression. quite something else actually. so far removed from the rat-race yet so accessible. we find we can happily spend the entire day just “playing” and engaging… ah man! what a blessing!

Latest snapshots


Software is Hard

You may have heard it before, and if you haven’t, you need to understand that. Besides all the technology and implementation caveats, competing frameworks and myriad and variety of business rules within the same vertical, there’s also the challenge of finding competent resources.

Coding is the easy part. Almost anyone can do it, given enough time with a “Learn _INSERT_LANGUAGE_ in 24Hrs” and a off-the-shelf PC. Even better, do a condensed one year course and come out the other side “qualified” and even better, command a “qualified” salary. What ludicrosity!

Now that’s not to say one year condensed courses and self-taught programmers are to be frowned upon. Some of the better programmers i have worked are self-taught. What you’re not, as a self-taught, or one year crash course graduate, is qualified. Far from it. And then even 4 years into your career, and some candidates reckon they’ve seen it all: they’re intermediate, looking for a senior post (along with the salary). Inconceivable.

Yet, this is what seems to be the status quo in South Africa right now (or at least, that is, in Cape Town). There is a massive demand for C# programmers (in particular) and the demand has outstripped the supply so greatly that the market is flowing with inexperienced skills demanding (and sometimes getting) the outrageous salary demands they’re placing. And the only reason they’re getting it, imho, is that whoever’s hiring them a) are not concerned with quality b) haven’t a clue what they’re doing or c) are really doing so well financially they can afford the risk. And maybe have a secret to mitigating that i don’t know about…

Of course the greater danger is the software that is out there. And then the pervading negative experience in bespoke software that continues because a bunch of “senior” programmers couldn’t get it right.. Go figure.

Two prominent cases recently gave the issue some visibility. The traffic registration system and the online tax filing systems. The traffic department came to a grinding halt for literally weeks because of concurrency issues on the system. The online tax filing handled well enough during the pilot, but when it was opened to the public, it hung. Badly. And we’re not talking about millions of hits per day either…

Until you’ve got about 7yrs of pure development experience (as a guideline, not a dogmatic rule) i don’t think you’re qualified enough to even contemplate leading anything. Stick around for a bit, get some more diverse experience and when you start approaching 10 years in the trenches, maybe then consider grooming yourself in preparation for more of a leadership role. Until then, you’re ultimately only bluffing yourself. Of course, it doesn’t help that the market regards a one-month MCSD as a competent programmer. It just makes it easier to sidestep your own professional integrity.

Please note, the actual number of years is a guideline and, as with everything, there is a lot more to consider than just historical “age”.