Probably there’s nothing new with your professional jargon seeping into your day to day vocabulary. I mean it’s the most natural thing. So if you are gonna list taking bath as an ‘action item’ I’m not going to mock you. But engineers, they are a bit different from the rest of the lot. No I’m not saying we terms drop (which we do), but even the intended audience won’t figure out what in the www are we talking about. For the sake of saving time on analogies I’d like to call these technical ramblings – ‘Droppings’.
Now let me tell you I’m not talking about the nerdy type portrayed in sitcoms like the big bang theory. I’m talking about the weasels (Read Dilbert) who thoroughly enjoy your expression of bewilderment that is brought about by a flurry of technical terms that have as much relevance with each other as Himesh has with acting. I confess I’m heavily influenced by the Dilbert books I’ve been reading, but that has only made me put the obvious truth into words.
Now, as someone who has a reputation of doing just the same (sample here), I think I’ll let you in on the secrets of effective Droppings. First lets identify the scenarios wherein you might need to resort to dropping.
Scenario 1: Status reports
Any status report meeting, simplicity is a vice. When it’s a question of explaining your screw up or in the rare case of exaggerating your accomplishments, it always serves well to make it complex. Remember, there are people who might see through your bluff and hence never commit yourself.
Eg:
U: “We are 2 days behind schedule. The modules on interoperability of the interface and making the tool vendor independent would require more analysis”
Him: “The what? Where did that even come into the picture?”
U: “I made it a point of analysis to ensure the power ratings and latency related problems of the vendors do not hamper the performance of our tool. For this we need to collect the tech specification from the diff vendors and ensure there’s no anamoly”
If you thought any of it is supposed to make sense – think again! By the time the other person recovers from the shock, you are free to get back to your browsing.
Scenario 2: Project documentation (Applicable to college students as well)
Well this is one lesson that is taught in college. A project report is something everyone demands but no one reads. But keep it in mind that everyone wants to pretend they are going through and hence point out some spelling mistake or the other.
Droppings here must comprise of abbreviations and if engineering project, a lot of greek alphabets. You might as well add telugu and tamil alphabets to emphasize it’s a genuine work. They always look nice in reports.
Abbreviations – make them up as much as you can and you can always say you’ve listed it in the look up table. In fact this works in status reports as well. You can always christen stuff like “That Icky Gooey Stuff” as TIGS and expand it later as some Thermally Insulated Gallium Silicide. (a 50-50 chance that something of that name actually exists!) Mathematically, 26P4 + 26P3 possibilities for conjuring your own 4 letter and 3 letter Abbreviations!
Next year some lazy junior is gonna take up your project work for reuse and by the time he figures out he’s been heavily loaded with droppings, his project reports would be spiral bound and hence your legacy will be carried on.
(Ya Its ok, you can mention me in acknowledgement and this blog in your bibliography)
Scenario 3: Code Red Scenarios
Ok, this is when you are in deep shit like having to explain what caused the system to crash. What’s different from the earlier scenarios is that here you better pray you can get away with it.
In such scenarios try to be highly generic. Use words like ‘possibly’, ‘probably’, ‘may’ every sentence and then use not more than 3 technical words a sentence. Preferably, try to get it right.
Eg: If your application had crashed while you were playing online Halo on your laptop, truth can crucify you. But for any chance of salvation you need to report accurate data. “While testing for performance of the tool when running a graphic intensive application over the web server, the system performance possibly deteriorated due to memory constrains of the processor”
Hurts no one, but talk about the weather if you are asked to repeat this [;)]
Scenario 4: Blip in the Radar
If you find two guys in an animated discussion of something too technical with grins and lols between each statement, the chances are high that they are talking about something so trivial. If you look around, you might find the triviality not too far from them.
This topic I can’t explain with too many details, but I can tell you this works like a charm. If you actually got what point I’m driving at, the chances are you don’t need any more explanation [:D]
If you don’t, ignore them as jackasses and get on with your work.
Scenario 5: For the heck of it
This is the ultimate human nature. Men (and women) play for reactions. And nothing more gratifying than a “Oh Shit!” expression for a performer. I mean you can’t get expression of awe and appreciation without working and hell, like someone wants to do that! Easier way out. Doesn’t it explain the hordes of PJ cracking smart asses that you find at every nook and corner?
So, the next time you are subjected to droppings from an engineer, stop trying to make sense out of it. If you were to get it, they’ll put it in simpler words :) On the contrary if you are an engineer and practicing the philo, cheers to us!
After reading Dilbert and of course seeing a few of my friends struggle, I realized things could have been worse. So here’s a word of thanks to my team and my TL here for making a life lot easier. (Touchwood)
