The More You Know

I think for some engineers, the greatest problems in an engineer’s life are due to the simple fact that most people are not engineers. And that is not to say that engineers are better people, despite the fact that some do believe this. Engineers just think in components, systems, and solutions. That is to say, when presented with a problem the engineer is more interested in the how, why, and solution, rather than just the solution on its own.

A good example of this is the following situation, an engineer named Henry has created an application that loads massive amounts of data and presents it to the user in a simple and intuitive way. Needless to say, his application is a hit and people are dying to use it. However, when importing the data for the first time, the user is asked to specify the data file and two optional fields, which if filled in can not contain any white space. One of these fields, is label “Name.” When this field has any white space put in it, an error message of “All fields must have valid Oracle identifiers” is returned.

To anyone who has used an Oracle database system, this message is painfully clear. To an engineer who is not familiar with Oracle the problem is obviously that there is a limitation on the character set allowed in the name field. A quick search for what legal Oracle identifiers are will result in the proper knowledge learned. However, to other users, what are they left with?

These users are not stupid, they just come from a different mind set. They see an error, and wonder what they did wrong. Upon reviewing the information they entered they will conclude that they did nothing wrong. Nothing told them they could not use spaces in the name field. Names are just names and are non important information used to quickly identify things. However, in this system counterpoint is true. The name is special and specifically an Oracle identifier, but that was never relayed to the user and it is expected they know what an Oracle identifier is. The user is left in a lurch without any more information provided to them.

One might argue that the user could/should go and search for the information. The user possesses the skills to seek out this knowledge and correct themselves, so why don’t they? The simple answer is they don’t know what to look for. Understanding how computational systems work is not part of their daily life. If it were, they would be working in the IT industry. Chances are, they aren’t.

So the phrase “Oracle identifier” jumps out to engineers and not to most normal people. Those who do notice it, might still get lost searching for what its real meaning is. At that point, Henry is taking a chance that they know what Oracle means to his system and that if they do search for the information they end up at reading about database systems and not the Roman oracles who predicted the future.

This whole situation could be avoided by simply replacing the current error message with something along the following lines: “The name field can not contain spaces.” Better yet would be to have the field not use the label “name,” but “identifier.” The label “name” is too informal and doesn’t convey the strictness that “identifier” does. Also, when an error in the field is encountered, specifically stating all the requirements of the field would help the user not fall into yet another error. A good message could be, “The Identifier field can not contain any spaces or the characters {}[],. .”

This would allow Henry’s users to import their data and not fall into trouble with optional fields. Henry’s problem was not understanding that each person has knowledge specific to what they do and experience in life. Expecting users to extrapolate information is never a good practice. A simple exercise would be to sit back and take in your application from some one who is like my mother, who knows nothing about computers or computer systems. She is smart, intelligent, self educating, and she can run circles around me with knowledge on how to deal with people, but throw a computer error at her from a complex system and she is dead in the water calling me. So pretend your mother (or sister, brother, grandma, whoever) is using your system and reading your error messages. Would they understand them? Would they understand them if they knew nothing about the technologies your application uses?

Try to remember every problem is like a giant pit. One side is the user, the other side is the solution, and right in the middle is the problem. Engineers know how to build the bridge and users only know how to jump. Try not to make them jump so far.

If you are a consistent visitor to this site and the links/comments stopped working, it was due to a recent upgrade in WordPress, which manages this site’s content. The links should now be working for your viewing pleasure.

The easiest way to put people off and eventually put them against you is to hurt their pride. The problem is that dealing with people is not a science. People react to emotion rather than logic and thusly their reactions are not always logical. Things as simple as responding to a question could spawn emotions that put the questioner on the defensive. Rather than obtaining a warm and friendly conversation, a gritty and tense one forms. Take for example something that happened to me recently.

I was at work enjoying some water-cooler-talk at a co-worker’s desk. From the other side of the cube wall another engineer peered over and asked me if he could live edit a file on the main development web server. The file in question, was a library that I wrote.

I was thought “why does this guy want to edit MY library.”

That initial thought was what sent the conversation into an immediate tail spin. It prompted me to feel sole proprietorship over something that belonged to the whole. Instead of being a team player, I became a me-player.

“Why do you need to edit the file.”

“I need to add an id option to the …”

To which I cut him off. The library did nothing with id’s at all. The only things that would use any id would be from application specific implementations. I began to explain that he shouldn’t be adding anything application specific to the library. That it was meant as a stand alone library and that putting those options in the code base would compromise the viability of the library. I used a stern voice as if I was chastising a child.

During this conversation I was standing sideways to his head which bobbed over the cube wall. Upon finishing my rant I turned to look at him and I was shocked. He stood shoulders hunkered down, eyes cast away from me, and was deliberately standing away from me. I, in less than fifteen seconds of speech, made him regret talking to me. I could see it in his face, body language, and his response. I could see how affronted he was.

Now this engineer is a pretty good friend of mine. However, by feeling too much pride and ownership over the library in question, I forgot to approach him with respect. By interrupting him and not letting him explain his situation I was saying “you are not important.” Using a stern voice and telling him “what is what” made him feel as though I saw him as my lesser, devaluing him as a person and as an engineer. Chastising him stripped his pride. I took what could have been a friendly conversation and made it as unfriendly as possible without shouting curses at him and insulting his private life.

What I should have done is focused on what he needed and wanted. His concern was getting his work done. He knew that I was working with the same file and out of respect he came to me to ensure working with it was okay. In return I gave him zero respect and made the situation hostile. The conversation should have been kept on an even level addressing him with a friendly demeanor and willingly saying he could edit the library, but then express interest in what his goal was and offer my help. Doing that would have revealed he wished to work on temporary function I had mistakenly left at the bottom of the file that was supposed to be moved into a public API file.

Not only was the developer free to edit this file, but it was my error that the function was in the wrong place to begin with. Thinking about this, I went to my co-worker’s office and apologized for being so confrontational. Explaining the mistakes I made due to my pride. He responded positively and even accepted my actions. We then discussed the changes and what needed to be done to the code to make the situation better for all. His demeanor changed instantly and he was open and friendly during the whole conversation.

I made a mistake of being prideful. I made the right move by accepting my fault openly and then treating my peer with the respect he deserved. Doing that made him willing to offer information to me and me to him. It created an energy between us that promoted growth and friendship. I praised on his politeness in coming to me and making sure working with the file was okay. He only continued to respond positively.