Archive for April, 2009

You Just Have to Tell Me What You Want

People in the IT industry have a stereotype for being poor communicators.  People outside of technology complain that we have our own language and just speak gibberish.  While that may be true, it's not a unique problem to IT.  I've dealt with, and continue to deal with, people who have a terrible inability to get a complete thought into words;  management, IT, sales, and project managers included. Communication issues aren't limited to one group.

photo courtesy of The Infamous GdubInstead of turning this into a rant, I want this to be a beneficial post aimed at bridging the gaps that exist between us.  I've had various people compliment me on my ability to make others understand things.  I'm not an expert, but I do feel like there are a few things that help me make known the things that I want known.   

  1. Engage yourself in the topic for the moment.  The absolute first thing that needs to happen is that the topic have your undivided attention while you are expressing yourself.  Multitasking is a horrible lie created by upper management to try to squeeze more work from people.  The truth is that I've never seen anyone that can do two or more things simultaneously and do any one of them with great skill and accuracy. If you want to get your point across well, you can't be thinking about a hot date tonight or worrying about your marriage.  Put that aside for 5 minutes and focus on the topic at hand.  
  2. Understand who you are talking to. By knowing your audience, you will be able to quickly make your point.  For instance, if I am talking to a non IT person, I will switch my vocabulary from entities to things, and from tables to buckets.  Getting your point across isn't a lesson for the audience in your area of expertise.  If you are talking to someone stupid not so bright, then use smaller words. (For once I'm not trying to be mean, I promise!)  If you are talking to someone who has a hobby, then try to use references that relate back to what they know.  Just try to find some common ground.
  3. Look to your audience for signs of confusion/lack of interest. This is a lot easier to do in person that over the phone or by email.  Read into the responses that you are getting to make sure that you are being understood.  If people's eyes are glazing over, then you know that they aren't understanding you.  If they are just disengaged, then call them on it and bring their focus back to you.  If they are trying to be engaged, but just don't understand, then change your explanation.  With any communication medium, watch out for unintelligent responses for the topic at hand.  If I'm explaining some business process to a salesperson and they respond about the fax machine not working, then I know I've lost them.
  4. Be respectable.  Your audience needs to have some sort of confidence that what you are saying is trustworthy.  In order for your audience to trust you, you need to know what you are talking about and somehow convey that to the audience.  This one is hard for me to quantify.  All I can tell you here is what NOT to do.  Don't use net-speak (LOL, ROFL, FTW, etc) and don't abbreviate like people tend to do in texting (R U OK 2?).  Don't use slang.  Don't mumble and don't stutter. I'm sure there is more here, that's not the point. You just want to make it easier for people to respect what you are saying.  
  5. Know what you are talking about. I saved this one for last, but it's far from the least important.  You can't effectively communicate something which you don't understand.  Period.  You may be able to BS your way through some scenarios, but people are able to see through most of it.  In order to be an authority on a subject, you have to know it in and out.  If you know what your talking about and the audience knows that you know what you are talking about, then they will be more engaged to what you are saying.  Getting undivided attention from someone is half the battle to getting your point across.

 photo courtesy of masochismtangoAs a software developer, I'm only one part of the IT umbrella and I can't speak for the entire industry.  With that said, it's my opinion that software developers are naturally good communicators.  We have to study problems and understand them intimately in order to turn ideas into work-flow and business decisions into code.  We have to write code in a clear and concise manner and then document the confusing parts.  Code is a communication medium.  Fortunately for us, the compiler tells us when it doesn't understand. People aren't so easy.

Management may complain that it's hard to understand us, yet I've spent my entire career (All 5 years of it! I'm still fresh.) trying to understand them.  In the end, we work problems from different angles and we have to meet in the middle somewhere to understand one another. If I can understand about your book of business and your pipeline, then you can learn about my web services and my databases.  You don't need to know how I implement things, just know the fundamentals about what they represent.  

You and I can all be better communicators.  It just takes a little willingness to understand what and who are around us.  Once we accept that we're not alone, and that the people around us are indeed different, then we understand that there is no one-size-fits-all answer to sharing knowledge.  Each person or group requires different technique, but everyone requires effort.  Just be genuine and truthful, pay attention, and the rest will follow.

Don’t Hate the Table, Hate the Game

I'm not too much of a table hater.  Tables in your HTML have their place, and they do what they were designed to do well.  They display tabular data with ease and relatively straightforward markup.  Tables work the way they work, and there are generally very few surprises between the various browsers.  With that said, I'm not a huge fan of tables being used for layout.  I like clean markup, and using a table for small bits of information just looks bad, at least to my eye.

One day, for whatever reason, I right clicked on the front page of Stack Overflow, only to be greeted with this:

<div onclick="javascript:window.location.href='/questions/620476/can-someone-tell-me-why-my-div-buttons-wont-resize'">
	<div class="votes">
		<table width="100%">
			<tr><td class="mini-counts">0</td></tr>
			<tr><td>votes</td></tr>
		</table>
	</div>
	<div class="status answered">
		<table width="100%">
			<tr><td class="mini-counts">3</td></tr>
			<tr><td>answers</td></tr>
		</table>
	</div>
	<div class="views">
		<table width="100%">
			<tr><td class="mini-counts">40</td></tr>
			<tr><td>views</td></tr>
		</table>
	</div>
</div>

That's 3 tables to display the following area, which is repeated nearly 50 times on the front page.

stack overflow front page

stack overflow front page

So I fired off an email to Jeff Atwood explaining to him that just by changing those heavy tables to divs that he would realize a 15K savings per page. Normally, I wouldn't blink at 15K for one of my sites. My sites don't get much traffic. But, for a site like Stack Overflow which has 500,000+ page views per day, that 15K can add up fast. Jeff quickly responded with the reasoning for their decision: "Vertical alignment is something that divs do extremely poorly."

Damn, I neglected to notice the vertical centering.  But, I knew that I could still make it work.  My first attempt to make this work involved nested divs with neagtive margin.  The markup looked like crap and wasn't working well in all of the browsers for me.  Then it hit me, this is just text.  What does the "line-height" css property do?  BAM!  The text was centering vertically and the markup looks nice.  I fired that off to Jeff, he got it integrated into a dev build to test the browsers, and off it went to production.

Now the markup looks like this:

<div onclick="javascript:window.location.href='/questions/514420/how-to-validate-numeric-input-c'" style="cursor:pointer">
	<div class="votes">
	    <div class="mini-counts">2</div>
	    <div>votes</div>
	</div>
	<div class="status answered-accepted" title="one of the answers was accepted as the correct answer">
	    <div class="mini-counts">5</div>
	    <div>answers</div>
	</div>
	<div class="views">
	    <div class="mini-counts">309</div>
	    <div>views</div>
	</div>
</div>

There, doesn't that look better?  I think so. I'm just glad I was able to see an issue, offer a solution, and get my voice heard.  There it is, my small contribution to Stack Overflow.  I hope they are realizing some bandwidth savings from that smaller markup.  Without hard numbers to go on, I'd say it's only a slight improvement after the content gets gzipped.

It still sucks that we have to play this game as web developers.  We're stuck compensating for the bad decisions of web browsers from 2001.  It's really easy to just fall back to tools we know really well, like tables.  Tables aren't bad.  Sometimes they just aren't the tool for the job.  The big bummer is that for 99% of us, it's a better use of our time to go ahead and use the clunky table markup to get something simple done in a timely manner.  There simply won't be enough people using our site(s) to realize any significant benefit from the extra effort to make things "right".   For those remaining 1%, the extra effort to get things right can be worth something. That's just wrong.  It's easier to do things the "wrong" way because the "right" way doesn't work everywhere and/or involves hacks to make it work.

It's worth noting that if you are a developer and aren't participating on stack overflow, then you are cutting yourself short.  It's a great place to find the answers you need and give a little back. Now I just need to get my rep up! ;)