Have you ever watched the movie Forrest Gump? If you are reading this article the odds are pretty high you have. As you watched the movie did you notice how Forrest told his story? Forrest wasn’t the sharpest knife in the drawer but yet he was able to paint a picture that drew the listener in. He didn’t use big words to speak or even speak in a lavish tone. Yet his story kept audiences glued to their seats. It is a true classic. We can all learn from Forrest, especially software developers.
How To Communicate With Others
Before I dive into a few samples let me just say this. I am not the world authority on communication. It is something I have had to do a great deal throughout my life though. Communication can be done a lot of ways in our society today but no matter what the medium is the same rules apply.
Have you ever had a situation where you met someone that wasn’t in your industry or profession? Sure you have, we have all done it. Let’s pretend for a moment you are on an airplane or at a dinner party. To be friendly you decide to carry on a conversation with a person. In a typical friendly fashion you ask the person “What do you do?”. They reply, “I build the CRC47 uplink devices for the SRT1250’s for Yoseph Industries.”
At this point you are thinking to yourself, “What the hell did he just say?”. Now reverse the role. What do you tell people when they ask you what you do? More times than not you’ve probably sounded that very same way to people. The question of what do you do is a very simple question but the answer people give back more times than not is not the same response Forrest Gump would have given them. What would Forrest have said in this situation if he worked for Yoseph Industries? Forrest would have probably said:
“I create these devices that send information up into outer space so folks can watch TV.”
I don’t even have to state the obvious at this point, it is so obvious how much easier it is to understand the Forrest version than the previous one. As developers and software engineers we have a severe tendency to be the other guy though. Maybe it is because we like to sound smart, or maybe it is because everything we do is an acronym or skews the English language into something that sounds more complex than it really is. Whatever the case is, as you go throughout the next several weeks and interact with friends, team members, management, business analyst and so on, listen to what you say and then ask yourself if that is how Forrest would have said it. If it isn’t, then the chances are you just sounded like the guy at the dinner party you met and no one understands what you are talking about. Here are some basic tips on how to tell it like Forrest Gump:
- Do not use industry terms even if it is something as simple to you as a “web service”. While most all developers know what a web service is, other people don’t. Gump it down. Instead of saying “We are going to build a web service in the middle tier”, try “We are going to pull data from that server over to here”. Leave out the details, model numbers, etc.
- If you are communicating something to someone who is not technical, pretend you are talking to your Grandmother or your children. The visualization of this in the back of the mind will make you speak completely differently so people will understand you better. A perfect example of this in real life is when your children ask what does Daddy do. You immediately think, I have to Forrest Gump what I do down so they can understand it.
- Practice. It takes practice to undo the years of technical speak.
- Remember conversation isn’t about you and how smart you are or how smart you sound. It is about trying to convey your ideas or thoughts so everyone else around you can understand them.
- Use analogies. I learned at an early age that analogies go a long ways with people. It helps them see the overall big picture. For example, say you are trying to explain to someone why data should be pulled from a web service in TCP binary messages vs XML messages. Use an analogy. One you might use is to take a bunch of pieces of paper which simulate the messages and put them into a waste basket. Then, take the same amount of paper and run it through a shredder to simulate how much more data can fit into the waste basket. Even the analogy of leaves works as well.
- Basic rule of communication. Never ever ever ever use an acronym in conversation until the other person uses it first.
These are six simple steps that if followed will help you communicate more clearly. If practiced you’ll be amazed at how much more engaging non-technical people will be with you. Have you thought about how you would handle the initial question of “What do you do” now? What is it that you REALLY do at work? The odds are you work for someone and they pay you to help their business run or succeed. In case you are wondering what my response is when I meet people and they ask me what I do I say:
I tell computers what to do so they can help us run our business.
How To Present Technical Information
This section basically builds off the previous section but it warrants another heading because the challenge of presenting technical information is much more broad. When presenting technical information, you have to be on your Forrest Gump game more now than any other time. Unfortunately, a lot of presenters assume since they are presenting a technical session everyone there is technical and on the same page. If you are presenting at a large conference this is never the case. If you are presenting something to your immediate team at work maybe so.
A technical presentation is one of the hardest things to pull off. Why? Let’s use an analogy (rule #5) to follow my own rules. It is like explaining Algebra to a room full of students from the 4th grade to the 12th grade. Sure all of them know some math, but they all know it to varying degrees. Good presenters poll their audience to know the boundaries of their audience. “How many of you here have ever done division? Multiplication? Complex expressions? Linear algebra? Algebraic combinatorics?” Based on the responses, the presenter should raise or lower his Forrest Gump meter and then communicate to the middle of the bell curve (8th grader). The presenter knows a fourth grader hasn’t done complex expressions but the topic to be covered still has complex expressions in it. The presenter should realize the forth grader is going to get lost during that section but also should understand there isn’t time to cover the complexity of complex expressions to a forth grader. A really good presenter will still help the forth grader out by coming up with an analogy so they get the bigger picture. If the forth grader comes away understanding the bigger picture, the presenter did his or her job. In order to achieve that though, you have to tell it like Forrest Gump.
So you can understand what I am talking about here is a quick Forrest Gump rendition of Windows Communication Foundation explaining the concept of Service Contracts.
Windows Communication Foundation is best described as a technology developers using Windows use to let computers and devices talk to one another, no matter what language those devices speak. One of the ways this is done is by all computers and devices agreeing to at least speak with one another in the same manner. We call this agreement of how to speak a contract. No one really signs the contract in legal terms, but everyone that wants to join the party agrees to it. For example we do this in our daily lives today. If I were to call a complete stranger there is an understood contract of how we should greet each other and what should be said. When I call someone they say “Hello”. I can then say, “Hi, this is Keith, how are you?”. They will respond, “Fine, and you?”. Within our conversation there is an agreed upon contract of how we are going to speak.
Let’s say I am calling a company that provides me services like AT&T or Comcast. I could say, “Hi, this is Keith, my account number is 123466, how much do I owe on my bill?”. AT&T and or Comcast understand this type of speak or contract. But, If I called my Mom and said the same thing, she is going to think I’m crazy. Thus the contracts that serve these functions given the situation serve different purposes.
While no one really signs these contracts in legal terms, everyone agrees to a verbal contract. So computers and devices can communicate with each other we put these agreed upon contracts on a centralized computer that serves these contracts up along with the information these contracts return back (how much do I owe would warrant a response of $19.15). If a device wants to know how much is owed they call the computer with the contract that is able to tell them that information and they get their information back. Since these agreed upon contracts are really providing a “service” to the computers or devices that use it, we call it a “Service Contract”.
This is one way to explain the concept of Service Contracts. I explain this scenario about Service Contracts in Windows Communication Foundation to show you a case in point about how to explain technical things so everyone in the room can understand it. Hopefully I did a good enough job of that to show you what I mean. Even if a person has no idea in the end how this really works, they should at least come away with an understanding of the bigger picture because of how it was explained.
Taking the exact same topic, here is an example of how a presenter explained Service Contracts in Windows Communication Foundation at a Microsoft Tech Ed conference. I use the example below because I was at this presentation. Here is how a Microsoft employee explained this same concept of Service Contracts.
The presenter basically just read the bullet point above and moved on, I remember the presentation in detail because I was thinking to myself that he should have stopped and explained further. I remember this presentation specifically because when I left the room I had no idea how Windows Communication Foundation worked or even what it was. It came off as sounding very overly complex and I remember telling someone afterwards, “He talked about all of these contracts and then these litany of bindings. I think Microsoft just took something simple and made it so overly complex no one is going to use it”. That was the impression I was left with. The whole thing just sounded overly complex. Digging into Windows Communication Foundation in more detail I now know that it isn’t overly complex, in fact it is extremely flexible and has a lot of benefits. The reason I thought this after the presentation is because the presenter didn’t tell it like Forrest Gump. They spoke about it from a very entrenched high level abstract view point and then hoped the demos they showed would wow us enough to go look at the technology. Here’s are some Words of Wisdom from The Elder if you are a presenter:
If your demo is suppose to make everything make sense then you didn’t tell it like Forrest Gump.
I can’t but help think what Forrest would do with the bullet point above. He would probably rewrite it like this.
Simple, to the point yet easy to remember.
The next time you are presenting technical information keep all of this in mind. Once you establish what something is then it is ok to call it a more complex term. Explain to the person or the listeners that “the thing” you were speaking about is now going to be called “this” from now on. If you are using slides, this should transition easily. Also remember the #4 tip above. The presentation isn’t about you. You only did your job if you told it like Forrest Gump so they can understand it.
How To Write Code
Developers write code. That’s just what we do. While Forrest would be a long way from getting hired as a software engineer there are still some things we can learn from him once again. I was reminded of this the other day as I was reading a post Scott Hanselman wrote about one of the function names in the ASP.Net MVC framework. In Scott’s article he talked about how he originally referred to it as “Magic”. Partially it was the name of the function that made it sound magical. Scott brought this up to the MVC team and after some debate it was renamed. The fact that the function was renamed is good but even after reading the new name it still isn’t what Forrest Gump would have called it if he was writing that piece of code. We have a saying in the South that says:
“Call a kettle a kettle.”
A kettle has several names: teakettle, tea pot, tea kettle, or the pot. The point of the saying is to call a kettle a kettle since that is what it is. There is no need to rename it, obfuscate it, or come up with a name that sounds cool or anything like that. Just call it what it is. For those that aren’t well versed in kettles, a kettle has a spout and a lid. Just because it can be used to boil tea doesn’t mean it gets a new name. Just call it what it is, a kettle.
I was reminded of this as I read Scott’s post. Here is what the original name was.
Binding.UpdateFrom(viewData.Product, Request.Form);
After some discussion with the team it got renamed to:
Request.DeserializeTo(viewData.Product);
The Forrest Gump version of what is happening at this point is data is getting submitted from a form and a developer has an existing object he or she wants to take the data that is getting posted from the form and map it to their object. Now ask yourself, even if you don’t understand the full scope of what is going on at this point. What would you call it? And then ask yourself what would Forrest call it so the lady sitting next to him on the bench in the movie could understand it? Would she have understood either of the two previous examples? The answer is probably not. While the second example is less ambiguous than the first one, it still doesn’t tell the story like Forrest Gump. Why do we care? Answer: What we name our functions and variables communicates what it does back to other developers that use it. It boils down to communication. The easier it is to read and understand the easier it is for developers to pick up on, even if they don’t know what’s going on.
It isn’t my place to tell the MVC team what they should call this method but I know that I would not “stumble” upon the new name as Scott mentions in the article. It isn’t Gump and doesn’t call the kettle a kettle, at least that is my opinion. I think it is calling a kettle a tea pot. It wouldn’t jump out at me merely by reading the API as to how or what that function did. Phil Haack, one of the developers on the project posted a comment with a new name that was pretty funny. While Phil’s comment was sarcastic, you know what, at least it tells it like Forrest. Here is what Phil posted:
Request.TakePostedValuesAndSetPropertiesOfTheObjectWithTheSameNameToThePostedValueUsingReflection(product);
Obviously Phil was making a sarcastic comment, but you know what, that is closer to what it should be called!
The whole point is when writing code, tell it like Forrest Gump and call a kettle a kettle. Don’t obfuscate your code with naming conventions or terms that don’t make sense. Things that should be simple, well, should be simple. They should be easy to find and simple to understand. For some reason though when a developer touches a keyboard and starts writing code they talk themselves into calling things something they aren’t. There are countless examples within frameworks and systems that aren’t simple to understand.
Let’s take a case in point within the .Net framework. Let’s say I wanted to write some text to a file that I already had in a string variable. Since this is an IO operation I would probably expect to be able to “stumble upon” how to do this within the System.IO namespace. As I type System.IO I see there is a File sub namespace. So far so good. This makes sense since one of the things we do with IO is handle files. As I stumble around trying to find which method to use I see Create() and CreateText(). Since I have some string data, and a path where I want this file to be written to nothing jumps out at me. Thinking like Forrest Gump I’m looking for something like this to help me out:
File.CreateFile(path, data);
Simple, easy to use and I would be on my way to my next business problem. Yet, if you look at the .Net framework and see how the CreatText() method is used, it isn’t Gump. It takes further reading and backward thought to understand that the words CreateText actually mean to either create or to open. Here is the official documentation from MSDN.
Now ask yourself, is this calling a kettle a kettle? Is it what Forrest would have named it? The answer to both is no. Not only does the name of the method fly in the face of what it actually does it is way more complex to write a file to the file system with the framework than it should be. Here is full example.
// Create a file to write to.
using (StreamWriter sw = File.CreateText(path))
{
sw.WriteLine("Hello");
sw.WriteLine("And");
sw.WriteLine("Welcome");
}
Are you starting to see the point? This is a real easy problem to fix and one that should be fixed.
Try this the next time you finish a new feature in an application. After you get done with your code ask yourself, if my Mom read this would she know what it was doing? If your answer is no, then developers on your team are going to also have a hard time. One scenario that plays out because code is not written like Forrest Gump is when a particular engineer works on a feature in a system by themselves. Down the road that feature needs to be enhanced or fixed and the original engineer that worked on it is on vacation. The engineer assigned to it reviews it and says:
“You better wait on (insert name) to get back. I don’t know how it works, I looked at it but don’t understand it.”
I’ve seen this more times than I care to count and have even said it myself. Writing applications doesn’t have to look like rocket science yet more times than not developers love to make things harder than they really need to be. Software should tell a story as it is read by other developers. If it does then other developers will love working on the system. If it doesn’t, they will hate it and eventually rewrite it.
We’ve looked at a lot of ways developers can learn from Forrest. Forrest was a simple man but he had a great way of explaining a complex story about his life in a way that everyone could easily understand. If you try these techniques don’t think just because you are explaining or writing something the way Forrest would that you are dumbing yourself down. You’ll actually find it harder than you think! The next time you are in a meeting, giving a presentation or writing code just ask yourself one question.
Did I just tell it like Forrest Gump?
