Let's pretend I started writing TacticSheet six years ago. If you would have walked up to me back then and asked for a quick explanation on how the login of TacticSheet works, I would have presented you with a document called 'module specifications for the login use-case' containing multiple diagrams, some of which, would have looked somewhat like:
But then I didn't start building TacticSheet six years ago. I didn't even think about it back then. Methinks my not attempting to start with TacticSheet six years ago definitely had something to do with the diagram above. Humor me. I have a point to make.
Six years have flown by, faster than I thought they would ever fly by. A lot has changed in ways I would have never thought it would change. Six years ago I encountered my first 'successful failure' which to a large extent, changed everything. Since then, I've come full circle. Today if you walked up to my office and asked me how TacticSheet authentication works, I would probably just take you to a white-board and draw something like this:
Six+ years and one colossal failure later I learnt my lesson which taught me how to use a white-board. I learnt that design isn't all about locking yourself in a cubical and writing fancy documents. I learnt that Project Management isn't about building Gant Charts and then going around the office asking people what the status is. I learnt that If I was ever going to work with (I'd rather not use the word 'manage') a team of smart developers I would have to roll my sleeves and at-least try and write code which is somewhere close to the code the rest of the team was writing. More than all of this, I learnt the art of 'trying' to express myself using a language and tone that others could connect to and understand. An art that even the most veteran of all consultants in our field lack.
As a part of my job, I talk to so called software developers, programmers and consultants all around the world. I interview them, discuss their profession with them and more than anything else I observe them; a lot. If there’s one thing I can tell you about most of them, it’s this:
Most of them are full of crap.
Why?
Because they complicate things; Un-necessarily.
FTC, UTC, LDD, HDD, SRS (the list is really end-less but I think you get the point); Talk to a group typical consultants about their projects or what they are up to and it’s not un-common to come across at-least a few of these three letter acronyms within the first ten minutes of your conversation.
Most of them seem to light up when they use these. God-forbid, if you cannot connect FTC to Functional Test Case, or HDD to High Level Design Document, you would have given them a deep sadistic pleasure of being more knowledgeable than you are.
Turns out, I’m not the only one who has a problem with these crappy attempts to complicate perfectly simple things; like a test-case or a design document for-example.
Scott Berkun describes why he hates most software consultants:
| I look at the English language as a good thing. Shakespeare did some good with it, didn’t he? Although he did invent some words here and there, I don’t think most of us need to create new words to get our points across - 200,000 is plenty to work with. In fact unless your new word enhances my understanding of what you’re trying to say instead of diminishing it, it’s hard not to see you as either a fool or a blowhard. You’re not making a new word or using obscure language to help me, you’re doing it to help you. If you look at how most consultant talk, you’d think they hated English, had a personal vendetta against it, as they seem to take such pride in burying clear thinking under layers of vacuous, disingenuous jargon. |
With armies of consultant, clueless about craft of building software, complexity in the way they communicate is something that's bound to happen.
The infinite loop of failure often moves around a vicious eco-system. If consultants who are iterating in this loop are using excessive jargons it’s probably because the entire eco-system encourages them to do so. In his same article Scott Berkun describes how the eco-system encourages this crap:
| Certainly (bad) consultants aren’t entirely to blame for what they do - some clients want the made up stuff, they want to believe in things they don’t understand, or they want to rely on a outsider simply so they can blame the outsider later on. |
Do you, dear reader, use complicated acronyms and jargons when you talk to your clients or fellow developers? If you do, ask yourself if you are using them just to impress or intimidate the person you are talking to; or are you using them for a greater self esteem and feeling better about yourself? Either ways, whatever be your reason, if you are using too many jargons in your conversations, stop; stop using them right now. Stop before you are perceived as a consultant who is full of crap.
I have quite a few friends who happen to be doctors and family physicians. When it comes to picking my doctors or physicians I judge them by their ability to say ‘I don’t know’. When a doctor or a physician is talking to me about my health and what's gone wrong with it I expect that he takes time and explains it to me in a language I can understand; even if it's just minor stomach ache.
If he doesn’t know what’s wrong with me and decides to give me a treatment based on a gut feeling or instinct, that's ok too. Either ways, I want to know and I want to be told in a language I understand.When I come across a doctor or a physician who lives in his ivory tower of medical-terms or jargons and uses them at every opportunity he gets, I turn around and run. I perceive this as a signal of incompetence and immaturity.
When you talk to intelligent clients, they are judging you; all the time. Just like we judge doctors and physicians. They’ll respect you and connect to you only if you can explain the most technical terms and concepts to them with simplicity; using a language they understand. Insult or intimidate them with your crap load of jargons and they'll be gone way before you know it.
It took my six years to develop a shamelessly-thick-skin and then put it to use in the real world. Now every time I hear a self-made-jargon or an acronym I'm not aware of, being used by anyone, I stop the discussion and ask the person using the jargon to explain it. I do it over and over every time a new acronym that I don't understand is used and I do it shamelessly.
At times, the person using the jargon feels highly irritated and after being interrupted a few times, stops using them. Other times, he draws a conclusion that I'm an alien with a third eye who is not good enough to be a part of the discussion and decides to ignore me completely and focus on other 'wiser' participants in the discussion who are as equally lost but would hardly ever admit it for the fear of lack of being intimidated.
I started this blog for developers like me. More specially put, .NET developers. When I analyze my traffic now-a-days it's easy to analyze that more than 50% of the regular readers of this blog are not .NET developers. Every now and then I'll get praises and criticisms about this blog. I love them both; but the praises that I've enjoyed the most are the ones, where people have told me that my blog is read and understood even by non-dot-net-developers including folks who are not technical.
Off-course, depending on the nature of the post it’s not always possible to cater to a completely non-technical audience, but I try my best even to make sense to a non-technical audience. Any complements on the lines of this blog making sense even to a non-technical audience are complements I love and treasure because they remind me that I'm not a Jargon freak scaring people away through the crappy technique of intimidation.
Next time you hear a consultant using self-invented-short-forms-and-acronyms and you are clueless about what he is trying to say, give Mr. Jargon a gentle reminder that there 200,000 words in the English language and if Mr. Jargon cannot say what he is trying to say in those 200,000 words, what he is trying to say is probably not worth listening to. Net-Net, either give him a gentle reminder about the vastness of the English language, or maybe, try using the Consultant's Jargon Generator, beat him at his own game of stupidity and then tell him how you did it. I prefer the former. It's much more polite.
If Mr. Jargon cannot simplify and explain what he is trying to say like he were explaining it to a teenager, he is probably just full of crap and probably isn't worth listening to; I don't care how many FTC's or HDD's he has written in his life. Seriously.
You’re not the only one. I’ve seen a lot of workplaces where people get pleasure in complicating perfectly normal terms by using unnecessary jargons.
In the end the folks I really look up to are the people who can simplify the most complex of things and explain it to me in a language even a teenager would understand.
I’ve been rather lucky to have been inspired by a lot of such folks, directly or indirectly. Maybe it was because of that inspiration, that somewhere down the line, I made an implicit promise to myself that I’ll pass of the same culture of simple communication over to the folks I communicate with.
With every single person I communicate with, If they don’t understand what I’m trying to say, I assume I wasn’t clear enough and simplify further.
Have I been fully successful? Who know! But I’m trying; to the best of my abilities.
or should I say, that they add a layer of simplicity above them and hides all the complexity which lies underneath them.
Take water for example, so simple..isn't it. But if you dig deeper, things change.
This post shows how:- http://www.digibio.com/archive/RedHerring_com-Why_water_is_weird.htm
Coming back to your post, I feel that *sometimes* its good to confuse people with stuff they don't understand. It makes them go "wow!..i did not understood a word he just said...he knows so much !!"
Like in your post you said, "When you talk to intelligent clients, they are judging you".
However, you don't always get to interact with intelligent people.
The only issue here is if the person at the other hand is intelligent he usually ends up going: “wow! This guy is talking crap and he doesn’t have a freaking clue of what he is talking about”. Personally, I prefer impressing with simplicity and clarity rather than stupidly complex jargons.
> However, you don't always get to interact with intelligent people.
But you want to, and you want to learn from intelligent people you interact with. Don't you? :)
Comments are closed.