the eyes of the beholder

As some of you may know, I did my internship at layer3 from May 2007 to the first week of December of that year.

During this period, I got a clearer picture of how much I don’t know, and I also saw very clearly how little you need to know to get along in this Information Technology industry (at least in Nigeria). I by no means consider myself an expert in this field, but I came across people with far less knowledge than I consider myself to possess handling significant infrastructure– I even had to do some tedious explanation/lecturing on a number of occasions (being a Technical Support person where I was working).

All these experiences contributed a lot to my growing impression that you don’t really need to know that much after all (at least in Nigeria). I’m yet to decide whether or not this is a good thing, but this impression in itself goes a long in assisting me to more objectively evaluate projects which I handled, which can only be regarded as failed projects. This combined with the strong hint that skill isn’t the only, or even most important factor in successful project execution.


I make it a habit to make clear my opinion about any technical tasks I’m assigned: the level of difficulty I consider them to be at, and the likelihood of me coming up with a satisfactory solution. Usually, I get the impression that the client understands this, and is willing to take the plunge. I also explain carefully, how I expect the end-result to look like, and I usually get the approving nod.

However, from my experiences, I find that, the client usually expects that the solution will start out looking like you described the end-result to be, and then get more and more true to its specifications. This poses a problem when you present the first prototype. This problem stems from the fact that a work of, say web design is much like building a house. You may be shown a scale model, and you will understand what the end-result will be, but during construction, the house may not look anything like what you saw in the scale-model.

One of my projects collapsed at this point. After careful and detailed discussions with the client, I went to work, and presented a prototype with the general framework, and basic functionality. To my surprise, the clients voices went up a few octaves. "This looks nothing like what we discussed!", "Why didn’t you say you couldn’t do this?", "The logo is not the correct one!" … I hardly could explain that this was a work in progress, and that it takes time to achieve the finished product. Project was cancelled.

Another project failed because the client expected a true-to-specifications prototype (including appearance and navigation) e-commerce site to be built within a weekend. When this was not achieved, it signaled incompetence.

Perhaps these failures imply a certain insufficiency of technical ability, but I suspect more strongly that these failures resulted more from poor understanding of project life-cycle, or extremely poor communication of necessary information to the clients, or naivete in estimating the time and effort needed to implement a convincing prototype, or even incorrectly establishing which point in a project’s life it is ready to be presented to the client for evaluation.

What have these got to do with "not needing to know a lot"? I observe that the people being served by these supposedly under-skilled persons are quite satisfied with the work done.

Perhaps these people know things which I don’t know. And quite possibly, skill isn’t as important as I think it is.

[ps. my email signature (below) is a random quote supplied by the unix program ‘fortune’]

fortune: Never do today what you can put off until tomorrow.

Leave a Reply