My job forces me to deal with a lot of question marks. I write code for a living. So I have to constantly ask myself...will this code change screw up something else? am I understanding the requirements completely? will the response times get screwed by this teensy weensy change? are the servers healthy? what is the meaning of life? where do I fit in to this jigsaw puzzle also called the universe? did I have lunch today?
Most engineers are forced to study theoretical computer science, so that they may apply those concepts to actual work situations and reduce the number of unanswered questions. Unfortunately most engineers never paid attention to these theories in college. Even if they did, I doubt they'd be any better equipped to answer these questions. The problem with taught logic, is that it simplifies everything down to the duality. There is true, and there is false, and nothing but either of these two. Logic does not leave room for for uncertainty, which is unfortunately a major part of every software implementation decision. Hence university prepares the programmer for nothing, and when thrown into the wilderness of commercial software development, he is like the proverbial bunny facing the headlights of an out of control tank with a maniac at the controls.
So where does that leave me (and most engineers)? Emergencies. Every issue that comes up is an emergency, consequently, any efforts to prioritise tasks, go down the veritable toilet. If you have a fire to your right, and a fire to your left, and one to the front, and one warming your ass, how will you decide which one to extinguish first? Apart from these, you have the other little tasks, like designing modules, bug-fixing some minor parts of your system.. etc.
Management loves these situations. For them it becomes an exercise to assert their superior skills and exhibit their charting/graphing abilities. They'll decide which fire to put out first by simply considering how much money each fire is burning up. It doesn't matter that your ass is being roasted, you still have to put out the fires in the sequence they decide, while they explain their decisions with a lot of meaningless statistics and pretty pictures. Alright, maybe I am exaggerating a little. Maybe, the fires weren't really life threatening. But the intricacies of software development, leave the poor developer with very little margin for error.
There's a story I read somewhere. A big company has its industrial floor, and something is causing a complete shutdown in the machinery. Nobody knows what or where the problem is. So they call in a consultant, he walks about for a few hours, fiddling with knobs, reading meters, doing what consultants do...and then walks over to a boiler, takes a piece of chalk and marks a tiny X on the inlet pipe. He tells them to change the pipe, and almost instantly the problem is resolved. Then arises the problem of paying the piper. Management argues that the exorbitant sum demanded by the consultant hardly matches his actual effort. All he did was put a tiny X on a pipe. The consultant broke up his billing charges as 1$ for actually drawing the X mark, and 49,999 $ for knowing where to put it. This story may or may not be true, but it helps explain my point.
Commercial software development works much in the same way. Everybody and his dog can write code. It requires a special breed of programmer to know what's wrong, and how to put out the fire. It may be as simple as turning a switch on or off...but knowing which switch to toggle only comes from long hours of painful debugging, many cups of coffee, and many missed family dinners.
The point I am trying to make is this. Software development may be touted as a logical, systematic method to translate business requirements into finished product, but it is rarely logical, and even more rarely systematic. Problems never come unaccompanied. They arrive in multiples of 1024, and always on the morning after that late night which has you yawning throughout the day. Solving these problems needs a combination of exceptional judgment, time management, unbelievable skill and dedicated, painful manual labour. Trust me...programmers earn every last dime of their salary... the hard way.
In a future post, I will attempt to redefine the stereotypes associated with the programming fraternity. Some of these include the alpha-developer, his trusty hard-working sidekick, and his reason for suffering..the rock-star programmer.
2 comments:
no comments on this one. but hey, i just realized i don't remember your name! what does one call you? (i don't refer to people by shortened versions of their names on principle.)
and how the hell do i do this blogrolling thing?
Post a Comment