Source: Where Wizards Stay Up Late: The Origins of the Internet
Authors: Katie Hafner and Matthew Lyon
In chapter 3, Katie includes this bit of information about Frank Heart:
“Heart had a predilection for judging people not by their looks or manners or political views, but almost purely by how smart he believed them to be. or as he liked to put it, by how many neurons per cubic centimeter their brains contained. If he decided the number was unusually high, Heart was likely to tolerate a lot more idiosyncrasy in one than in another whose gray matter he thought was less densely packed. When talking, Heart often used computer jargon in nontechnical circumstances. ‘It’s a no-op,’ he might say to his wife Jane if they decided to leave a Sunday afternoon free. (No-op, or no operation, refers to a line of code that accomplishes nothing.) Or he might say, ‘It’s binary,’ to one of their small children, meaning it is a black-and-white situation.”
Engineers seem to think about the world differently. Heart may have been more obvious than most, but I analyze life like I approach my computer design. I weigh time cost against performance gains, I try to break down problems into smaller chunks trying to understand the inner loops, I dismiss unnecessary information without much of a glance while at the same time failing to explain my actions (comments) because obviously anyone would understand what I mean in this situation or by this action. My Dad, who has been a computer engineer for 30+ years, is very much the same way. One of my brothers, who also is a computer scientist, will quickly dismiss you when explaining a concept if you don’t immediately understand his explanation, which usually is only a minute step down from the original complexity. I’ve run into this same problem with many computer science professors.
I don’t understand how engineers can spend hours debugging code line-by-line to figure out a bug and yet struggle to have the patience to explain a technical problem to the layman. In the end, I think it is an important area of reflection for any engineer. In order to make quality software that acts intuitively, the way the user expects it to act, engineers must analyze their user base and break down their thinking and actions in much the same way they code: ‘
A user gets frustrated because he doesn’t immediately see a confirmation purchase page so he repeatedly submit the purchase (solution: handle first button click and ignore the rest) —– My girlfriend will be mad at me about ‘x’ and not say anything for weeks then she will want to kill me because I forgot to put my shoes up. (solution: ignore initial reason for all fights and decipher the real problem).
In the first situation, sometimes the problem is not with the user and the button needs to be clicked again. In the second situation, sometimes, maybe even most of the time, your girlfriend will be telling you what is bothering her; however, unlike the first situation where the user just reloads the page and starts from scratch your girlfriend will not be so forgiving. The world is not really as binary as engineers would like to think.