A look at Real Software Engineers...

Its been a while since I last wrote my regular blogs, and looking back, it seems to be filled with complaints.. so let me repent and attempt to do better.

I've been noticing over the recent years that there is a distinct difference between real software engineers and others (who are in it for the money, or just wannabes). Since I promised not to complain, I'll just focus on the software engineer bit.

Real engineers seem to have the following characteristics
1. they get negative with time.
Its a professional hazard. I mean, name me one other profession that has to think about failures even before it happens. Good codes does error handling in a respectable fashion and we test for possible errors even before it occurs. Is it any wonder that most good engineers are cynicals?

2. They have a cast-iron bladder control
again, its a byproduct of the profession. we tend to stay for long periods at our desks, being lost in the process of writing or debugging code. And sometimes, its just so exciting that we can't bear to take that 5 minutes to dash to the Loo.

3. Real Engineers are slightly warped.
Software engineers are mentally warped. as a very basic proof: who else in their right mind would want to spend hours sitting at the screen, debugging abstract problems that cannot be phyiscally modelled? and the scary part is, the engineers enjoy it. Only two other groups of people are more warped: the theologians and the philosophers. (Oops)


Having stated some common characteristics of software engineers, let me construct a method to describe the poweress of an engineer. Using the "level" terminology used in role playing games, we can describe engineers as the following (only levels 1-10 are described. the rest belong to the demi-gods category):

Level 1:
Learns about the need for logging. logs alot. lots of useless logs.

Level 2:
debugged his first live system, and wishes that he logged more. starts realizing that his previous work was rubbish.

Level 3:
realizes that he needs to know concurrency, else his system cannot scale. (don't laugh. there are places where concurrent-styled programming are discouraged because "its not safe").

Level 4:
Understands that the lessons taught in computer science 101 and 102 are not for show: there really is a producer-consumer problem. Death by starvation, livelock and deadlocks are real concurrency problems. Start buying text books and hitting head against the wall when faced with such problems.

Level 5:
Tends to overengineer systems. Small systems become large. Large sytems become unusable.

Level 6:
Knows how to avoid previous problems, but runs into another set of problems altogether: previously unusable systems are now usable, but its hard to impossible to describe. Diagrams showing "how the system works" tend to look like spider webs, and span 16 pages. Consequently, such diagrams are often used as wall paper.

Level 7:
starts to develop "glow in the dark" problems. What else can you expect after being exposed to such amounts of monitor radiation?

Level 8:
Having attained this level of expertise, he is left alone by the project manager to handle death marches. A death march is a project where
a. lots of heroism/sacrifice is required for the project to succeed
b. the engineers tend to get very suicidal or depressive (and often thinks about going to tahiti)
c. the phrase "DOOMED! WE'RE ALL DOOMED!" is often heard in the halls. alternatively, Beethoven's fifth is often sung to the words "DOOM DOOM DOOM DOOM!"
d. coffee intake rises dramatically
e. heads are constantly banged against the wall. the engineer might even have a "BANG HEAD HERE" sign on the wall somewhere.

The plus part: he is constantly challenged. The negative part: his assignments require him to "walk on water or drown". No fun.

Level 9:
is often required to do "15 seconds reverse engineering". i.e. given a piece of code which he had never seen, he has to give an answer to the question of "what does this code do?" in the extremely generous 15 seconds alloted. (these questions typically come from non-software engineers). Engineers at this level often have an aura of divine light around them: after all, they need solomonic wisdom in order to be able to state confidently what something does.

Level 10:
smells death marches in the air and are able to get out of the situation fast.

Heroism tends to wear out the hero..

Am rather exhausted now. The development for that product is at an end, and I'm worn out.

its bad enough that i had to teach basic computer science. Its worse that i had to do code reviews. Its horrible that I found the same mistakes inside, despite having told the wanna-be engineer about it.

then on looking inside, i found that the *word to do with going forth and multiplying* code does not work.

looking back, the project took 6 weeks, if i didn't have to teach him and wait for him, it would have taken 3 weeks. And I wouldn't have to suffer the pains of baby sitting, and the pains of teaching someone who is obviously not listening.

even though we were supposed to work together, a loose estimate of the work i did would be something like 95%. i.e. at least 95% of the code was written by me. gosh. no wonder i'm feeling tired.

I've been getting so stressed that I started to have dreams about my work. in one dream, i woke up feeling greatly relieved. I found a solution to my work problems! but as my mind recalled the solution, i started frowning.

what was the wonderful solution?

QUIT THE DAMNED JOB!

the truth, the whole truth and nothing but the truth.

Let XXX be the name of the application I'm working on.

from a colleague - "XXX has alot to do with voodoo. There are too many occasions where i spent eons trying to locate the problem, but found nothing. but after laying on my hands, it started working again"


I'd claim that we had a gremlins infestation, but i guess voodoo would do as well.