feature article
Subscribe Now

V=IR

Practical Laws for Social Engineering

I am an engineering god.

…a technology savant, an electronic wizard, a mathematical master, an understander of epic proportions… at least as far as my non-technical friends and family members are concerned.

They prove this to me almost on a daily basis – enlisting my help in solving every kind of engineering challenge from pop-tarts that won’t pop to radios that won’t receive to websites that aren’t behaving as expected.  And, in most cases, I deliver:

“Let’s try plugging in the toaster – now, doesn’t that work better?”

“Maybe if we tune the radio to a frequency where there is a station, we’ll get something more pleasing.”

“Here, let’s hit ‘refresh’ and see if that makes that site look any better.”

When you have a degree in engineering, non-technical people think you can solve pretty much any problem they encounter – as long as it involves some kind of equipment.  More savvy friends understand that your expertise is more focused:

“What kind of power plug do they use in Belgium?”

“How long will my battery take to charge?”

“How many amps are in a volt?”

That last one, of course, leads to another reality of attending engineering school.  We spend four futile years trying to learn things that will help us function as “professional” engineers.  However, everything I needed for this type of “social” engineering work, I learned on the first day of EE school.

“Ohm’s Law tells us that Voltage equals current times resistance, or V=IR.”

OK, V is voltage, R is resistance, and current is… I?  (hand goes up)

“Why is current I, shouldn’t it be C?”

“No, capacitance is C”

“What is capacitance?”

“We’ll learn about that later – along with inductance.”

“Inductance?  What is that? And why isn’t inductance I?”

“Inductance is L, and it’s measured in henries”

“Why isn’t…”

“Please lower your hand.  Thank you.”

So – maybe I learned it on the second day.

99% of the electrical questions I am asked, however, can be quickly solved with Ohm’s Law.  What were those other 3.99 years of electrical engineering school for?  Who knows?

As we’ve discussed many times before, the real skill we learn in engineering school is problem solving.  That is the skill that transcends technology, never goes obsolete, and serves us in practically everything we do for the rest of our lives.  The ability to assimilate and understand the essence of a problem is key, for at the root of all problem solving is a clear understanding of the question.  Of course, education and experience give us a trove of solutions to previous problems on which to draw – allowing us to match the current situation to something we’ve already conquered.  While every problem is unique, it is a rare problem that does not have at least a helpful analogy.  

The next step is to be a master of the notion of cause and effect – and to understand the difference between that and simple correlation.  Everyone who eats vegetables eventually dies, so there is a correlation between vegetable consumption and death. Vegetable consumption does not cause death, however.  At least, I hope not.

One of the biggest challenges in the social form of engineering is the prevalence of false cause and effect.  Non-techies seem to make a daily practice of divining cause and effect where there is none, adapting their behaviors based on these false notions, then developing a complex hierarchy of fallacy that leads to the ultimate failure – asking their engineer friend for help.

“Hey, I need your help with something on my computer.”

“OK, what?” (note: if you have a EE degree – people assume that you’re an IT expert as well)

“When I try to paste a spreadsheet into my email, it doesn’t work.”

“Do you mean paste? or attach?”

“Yes.”

“No – which one – paste into the body of the email, or attach the document to the email?”

“No – paste the text into the email – I can’t do attachments on my machine.  It messes up my wifi router.”

“Wait, what?  Attachments mess up your wifi?  No, that doesn’t sound right.”

“No, it does.  I can’t attach.  I attached and it killed my wifi router – I had to return it and get a new router, but it was under warranty.”

“I don’t think that attachments killed your router.”

“Yes, they did.  And, when I got it back, I attached again, and it almost broke the new one – it gave me a 404 error.  I unplugged it real fast.  I thought maybe I was sending the email to too many people, so I split it up and sent them one by one.  I did all that with the machine plugged directly into the modem, though, I didn’t want to fry another router.”

“Uh, a 404 is the error when a webpage isn’t available.  Are you sure that was related to your attachment?”

“Yes, I attached a photo and got that – and when people got the photo, it was sideways.”

“ahhh… have you called support?”

Supporting your friends and family with their technology issues can be both rewarding and frustrating.  Often, their alternative is a minefield of disinterested support organizations who will walk them through a canned debugging script, almost without listening to their actual concerns and symptoms.  One friend of mine had a computer support rep instruct her to reformat her hard drive and re-install the OS – losing all her data and software.  This was after only a few minutes of phone diagnosis, and the support rep gave essentially no warning that she was about to burn her own virtual world to the ground.  When we fail to step up and help out, we are sometimes sentencing those we care about to a frightening and dismal digital fate.

When we do help, it is important to remember that our subjects have no idea whatsoever about the limits of our knowledge and expertise.  Usually they overestimate our related skills.  I often find myself googling their specific error message or problem as my first step in rendering assistance.  Often, the answer is the very first result returned.

What does come into play are our problem solving skills and our empathy.  It is easy to forget what your non-technical friends do not know.  They have their own skills and expertise in their own areas, and much of what they know about engineering they learned from TV dramas – where tape-bespectacled hackers with pocket protectors slide into NSA computer networks with a few seconds of finger twiddling on the keyboard chanting “Almost there… aaaaaalmost there… Now, we’re in!”  Those expectations start us at somewhat of a deficit.

Take your support responsibilities seriously.

2 thoughts on “V=IR”

  1. “Do you mean paste? or attach?”
    “Yes.”

    From the point of view of an digital electronic engineer, this is correct.

    Anyway, I totally agree with the princip that we just learnt to solve problems. And I still learn every day.

    The day I will not be able to learn anymore, I will retire.

  2. I think the disk reformatting thing was a bluff called. Unwittingly.

    It often feels to me that support groups propose huge steps like that as part of the “diagnosis,” figuring that no one in their right mind would actually do it, and then they won’t have to waste any more time with the customer (and, more to the point, will never have to acknowledge that there’s a problem – or, worse yet, have to fix it).

    Most people will say, “Are you serious???” and balk, at which point the support person can shrug their shoulders and say, “Well, we have to do this to figure out what’s wrong. If you don’t want to spend the entire next month rebuilding your machine, well, I guess there’s not much else I can do. Have a nice life.”

Leave a Reply

featured blogs
Sep 24, 2018
One of the biggest events in the FPGA/SoC ecosystem is the annual Xilinx Developers Forum (XDF). XDF connects software developers and system designers to the deep expertise of Xilinx engineers, partners, and industry leaders. XDF takes place in three locations this year.  Sa...
Sep 24, 2018
For the second year, the Electronic Design Process Symposium (EDPS) took place in Milpitas, having been at Monterey for many years. This was apparently the 25th year EDPS has run. I find EDPS to be a fascinating conference, and I think it is a shame that more people don'...
Sep 21, 2018
  FPGA luminary David Laws has just published a well-researched blog on the Computer History Museum'€™s Web site titled '€œWho invented the Microprocessor?'€ If you'€™re wildly waving your raised hand right now, going '€œOoo, Ooo, Ooo, Call on me!'€ to get ...
Sep 20, 2018
Last week, NVIDIA announced the release of the Jetson Xavier developer kit. The Jetson Xavier, which was developed in OrCAD, is designed to help developers prototype with robots, drones, and other......