Of Lengthy Answers And Contracts

Back in those engineering days, we had to write very lengthy answers to score marks. About an entire page for four marks. The people who evaluate these things never actually gave a hoot about what you wrote, but then your answers had to have the following qualities:

1. It has to be of the "right size".

2. It has to be neat.

3. Lines drawn with pencil and scale after each answer, if possible.

4. All the words in the question must be there in the answer. Highlighted in fluorescent green if possible.

A lot of people in class truly understood and played this game well. They would write on and on, pretty much repeating the same points using different words. Even in the few cases where they didn't get the full score, they'd go and fight like so: "Sir, How can you give 3 on 5 for this answer? See this, full page here and the neat diagram half of that page. I deserve 5!" And they'd get it, with due apologies from the lecturer in charge.

Having worked with my company for five quarters, I've come to realize that this is a very useful skill to have, the skill of writing lengthy answers. Each time we put forth an idea to the client with the hope of turning it into a contract, we have to write what is called an approach note. The document template has such sections as "Current process", "Improvements Proposed", "Advantages of implementing the suggested ideas", etc.

When I'd joined the support team (very long back), I had the idea of "Let's stop staring at production logs, we'll build something that will notify us of exceptions through email." The only real advantage of this idea was: I don't have to work. (2. I can do more useful things in life, like sitting in the canteen watching the AMEX vs Phoenix cricket matches. 3. Go to gym, which will lead to good physical growth. Hah! I'm good, too.) But, thanks to being educated engineers, we were able to fill up the "advantages of implementation" part of the document gloriously:

1. Increased stability of the systems.

2. Decreased response time for system issues leading to increased stability.

3. Decreased effort required for monitoring leading to decreased response time leading to increased stability.

4. Hey, these are live production systems. You want stability or not?

5. Increased profits due to increased reliability from the increased stability.

6. Increased business capabilities resulting from the increased profits mentioned in point 5.

And so on! OK, it wasn't exactly like that, anybody's blog has a little embellishment. But it was very much like that, the approach note we sent. My managers have given me extensive training on how to convince clients. "Assume that they (clients) don't know anything, not even the word 'Java'. All the understand is business, dollars, profits and costs. Say everything in these terms." So the contract got through and I had interesting development work even in the support team.

From these experiences, I have come to the conclusion that education wasn't a total, 100% carnal waste of time. It's just 99.999999999999999999999% now.