CSDA Tips on what's really important  to learn in Engineering 101

	(add your thumbs up to Google if you like this page)
	(add your facebook like)

While one can consider what basic technical information is important for engineering, I think the more important aspect is knowing the way to apply that technical knowledge into a problem.  With that thought in mind, here is my personal list, based on my many years of engineering in Computer Hardware & Software design of what an engineer should learn in Engineering 101. 

• "Think outside the box" - While most engineering solutions to a problem are either off-the-shelf, or just applying the knowledge, many require looking at it a new way.  Consider changing your algorithm or methodology
  
  On my 1st out-of-school job, the more senior engineers (I guess that was everyone else there at that point) were investigating an intermittent glitch (using old-school oscilloscopes) and didn't want to use a logic analyzer (very primitive at the time 32 bits x 16 words), whose setup time was much longer.   After two weeks of searching for the problem (and ignoring my suggestions), they gave me a shot.  My 1st test located the problem to an RS Flip flop, the 2nd test used the rising edge of the analyzer's clock input (thinking "outside the box" in the usage of a logic analyzer) to capture a glitch on the set line. The 1 word captured on the glitch, showed all the data of the Flip flop's pins that pointed to the exact problem and how to fix it. Total time, 45 minutes.
  
  
• Bad ideas lead to Good Ideas - Bad or apparently stupid ideas in a brainstorming session can lead to a great solution. A totally useless idea (even from people who may not even understand the problem) still might cue you into another solution.  Let the creative juices flow!
  
  Take some of the most recent Mars rovers. Two were landed inside a giant airbag, another lowered to the planet on a cable while hovering! I would have loved to have seen the initial reaction to those ideas.
  
  
• NIH syndrome - Resist the NIH (Not-Invented-Here) syndrome. How many great ideas were thrown out because someone decided if they didn't originate it, it wasn't any good? (Related is the throw out the old, because I have to prove that I can do it better to justify my position)
  
  
• Multiple Approaches - Engineers should learn to try multiple solutions (within budget and time constraints). My son at age 16 has done 6 egg drops with different groups over many years, all with different materials and supplies.  The latest was 2 sheets of standard 8.5" x 11" paper and a foot of tape, and would work from any height. All of them survived, but used totally different techniques.
  
  
• Plan for the future - Plan for what might happen to your code or product. 
  
  For example, as the original author of the Phoenix PC, XT and AT BIOSes, I wrote the code to be tolerant of bad hardware or software designs/techniques/methods (that I could perceive as what another programmer or hardware engineer might do in the future), that were not used at the time the code was written.  Code that failed on the IBM PCs or other clones, played fine with the Phoenix BIOSes.  HW should plan for future upgrades too.
  
  
• "Good Enough" - Learn when to stop.  Engineers love to keep tinkering, but need to learn when something is "Good Enough" and ready to ship. That doesn't mean ship substandard items, but one that meets or exceeds the target requirements.  If time and money allow, then you can make it even better.
  
  
• Reading tech documentation - Learn how to read tech data sheets, user manuals, other technical documentation.  Many are written in a poorly translated document that force you to really think about what it is really trying to say.  Here is example of how not write a user manual (for a small video recording device)

• Write what is it and what it does? - Learn to write good documentation.  All documents should have what an item is, what it does, it's various inputs and outputs, what other things it needs to operate (e.g scope probes), etc, and it should be right at the beginning.  Don't wait till chapter 3 to tell the reader.
  
  Similarly, software documentation should have a good header included in a piece of code with information on the purpose of the code, the inputs & outputs (with their values or ranges), examples of use and special notes.  
  
  In addition, useful in-line code documentation (comments associated with code sections and lines) should be liberally sprinkled everywhere in the code. A comment that repeats what the line is, e.g. a code line of d=v*t might have a comment saying multiply v*t and return d (stating the obvious) is almost totally useless (except for a really new programmer), rather than say multiply current car velocity with the time from start to get total distance traveled.

• Nomenclature - In general, give clear naming to items (hardware and software). using as many characters as needed (but not overly long). Where naming length is limited by some constraints, choose names that are as clear as possible.  Some choose leading or trailing characters to indicate a type, e.g vTemp or TempV might indicate a variable Temp. If you need to sort by type or main name might be a reason for adding leading or trailing characters to the names.  Don't ever use spaces in code names, even if allowed, use underscores.
  
  
• Trick Documentation - Always document any software or hardware tricks clearly and completely so the engineer who inherits it does not have to figure out why you did what you did (and this includes yourself 6 months down the road when you have forgotten the solution).
  
  
• Know your tools - Learn about tools, how to use them, and how to maintain them. In other words, get your hands dirty. E.g, there are engineers that have never held a ratchet, applied glues, solder etc., all skills that should be learned. Read the manuals, watch instruction videos (YouTube?) etc and understand as much as you can about all the possibilities of the equipment you use.
  
  
• Design for users - Engineers need to understand how people will use or repair something they've designed.
  
  Example: How many cars were designed and are almost impossible to remove the oil filter easily because of it's placement? Or have trouble filling oil, brake fluids, windshield wiper fluid because of it's positioning? Or have battery terminals almost inaccessible making a battery jump almost impossible?
  
  
• Quantum Observance - Sometimes, placing test points on a hardware problem, cause the signals to change or the problem goes away.  So look as close to the points (both before and after) and deduce what the problem is at the problem point.
  
  Example: I had an intermittent software crash about every 2 weeks.  The incorrect data from a memory was being clocked in. I could never capture the problem directly, but had to create special hardware triggers before and after the program began to crash in software to start a logic analyzer that would then be looked at for the error. The error turned out to be a bad memory card design from another department.
  
  
• Interchangeable parts - Identical or interchangeable parts don't always work (Thank you Murphy!).  
  
  Example: Gun parts of identical size may have different temperature coefficient of expansion and may not work at different temperatures
  
  Example: In one case I replaced discrete digital logic (SSI) with gate arrays.  The parts were functionally identically as indicated by hardware and software simulations. However, the gate arrays were much more sensitive to ground plane glitches that caused signal delays of 50 microseconds to almost 1 millisecond and did not work without modification to the system.
  
  
• Peter Principal - If you ever reach your Peter Principal level (your 1st level of incompetence), try to demote yourself one level. If you ever have to deal with someone in this position, hopefully they will trust you if they don't understand, otherwise you need to learn to manage upwards (not fun).
  
  
• Gut feelings - Give at least some credence to your "Gut feelings"
  
  I was testing at a remote test site when a software crash occurred that just seemed to have no good reason. Over the next few months similar crashes started showing up with more frequency as well as other odd failures. The cause was production versions of parts were being used for the 1st time, and it turned out they didn't have exactly the same timing as the prototypes.
  
  
• Reason vs Monkeys - If you can reason through a problem, you can often accomplish the same result as 100 "monkeys" and have a better understanding of a problem.
  
  In one case I was trying to understand a problem with a PC motherboard design that I spent most of a weekend trying to reason the cause of the problem based upon data dumps.  At the same time, over 100 engineers were working on the same problem, trying many possible solutions but without any direction.  In the end, they came up with the same solution to the problem in the same time frame, but they had no idea why it worked.
  
  
• Penny wise, Pound foolish - A little money in design or fixes can save a lot of dollars down the road.
  
  An intermittent problem (see Quantum Observance) was very difficult to catch (maybe once every 3 weeks).  After about 3 months of testing (at a cost of about $1 million dollars per week to test with all the support personnel, equipment and power needed), I had a 95% certainty that the problem was memory related, and the poorly designed Ground and Power plane on a DRAM module was the cause.  A bunch of quick fixes to the modules were done, but with no positive results.  I suggested investing about $25,000 to have some new printed circuit boards made that would eliminate this problem, but my Department Manager did not believe me (see Peter Principal), would not authorize the expense (a small amount compared to the money being spent on test), so he had me testing for an additional 10 months, all the while making sure a new larger memory module that was being designed as a replacement had a proper Ground and Power plane.  At 13 months from when I started, the new memory module became available.  It was plugged in, and worked 100%.
  
  
• Coincidences seldom happen twice - Also may be phrased "Fool me once shame on you, Fool me twice, shame on me".  If a crash happens once, it may be just a totally random event.  But if it happens twice in a similar way, it should get you thinking about the cause.
  
  There have been cases where someone turning on a light in the room, or the air conditioning coming on, etc. causes a failure at the same time. Windowed EPROMS (before EEROMs today) were not supposed to be sensitive to light, but some have been.  Glitches in the AC power can cause failures in electronics if the DC power was not properly conditioned by a power supply.
  
  
• Rare occurrences do happen - 1 in a billion chances can and do happen easily for fast events.
  
  A billion network packets can be sent in the course of a week in a small office using a database. Sometimes a network packet can get through that looks like it is good according to it's error correction and detection scheme. This can easily trash a database index, or data. So an intermittent cable or connector can really cause a 1 in a billion occurrence.
  
  
• Bad things Happens - Rare really difficult problems can happen, that can be extremely difficult to solve.
  
  Example: One problem I had with a AT motherboard design had a variety of tests applied to it. Each test pointed kept pointing either a hardware or software problem, going back and forth 6 times as to which one it was.  I was very surprised that the tests didn't converge on the source of the problem quicker.
  
  
• Listen to Users - When a user has needs or problems with a product, 98% is probably invalid complaints, where the answer was already available to the user. But the 2% left is information gold for fixing problems, adding clarity to the documentation, improving the product or ideas for a future product.
  
  
• Can't be Done - So many people might tell you that something can't be done. Landing a man on the moon, IMPOSSIBLE would be what someone in the 1st part of the 20th century might have said! The inventor of the electronic spreadsheet (Visicalc) was originally told by his professor that you'd need a supercomputer to run it. But it was this very product that took the PC from a little more than a toy to something that was really useful for business.
  
  
• Do it again - As much as engineers hate to throwaway a working solution, very often if you throw the solution away and start again from scratch, you'll come up with a much better solution (although obviously with more development time and cost)
  
  
• Dot your i's and cross your t's - Make sure you've accounted for all uses of a product as best you can.  If you have to leave parts undone, at least document it so it can be done in  the future.
  
  
• KISS method - KISS stands for "Keep It Simple, Stupid", which basically means that, given all other criteria being equal, keep the design simple, using available parts and with fewer things to break/stop working.
  
  An old 1968 Ford Mustang has a very simple engine, easy to service and maintain.  Todays, cars, with all of their electronic systems, emission controls, etc. are much harder to keep running (although obviously a lot better on the environment)
  
  
• Good User Interfaces - So many devices have a user interface (i.e. buttons, displays) that do not consider frequency of use, physical location, grouping, sub-levels of menus, consistency in naming, that I believe it is extremely rare to find great user interfaces.
  
  
  • There should never be more than 3 levels of menus, such that a user could get lost.
  • When executing a button, consider carefully whether you want to stay at the same level, return to the previous level, or go to the top after finishing
  • Don't put a destructive button (e.g. erase/delete/record) button close to other commonly used controls (unless you have a confirm action)
  • On hand-held devices, the main buttons should be easy to find in low or poor lighting, and located in an easy access point (like the corners and sides), rather than buried in the middle with other buttons. Consider people who have large fingers, or long nails and have difficulty hitting the button. Buttons can be different sizes, shapes, colors and textures to allow easy differentiation as well.
    
• Making Improvements that are not -  E.g. 
• 1. Small changes can cause large consequences. E.g. a decimal to hex conversion that went from lowercase output to uppercase output may fail comparisons if case sensitive, so code need to be repaired
• 2. User Interfaces that have no backward compatibility require retraining, or can be harder than the previous version because it was designed for a designer's concept of usability, rather than the user's concept of usability/
  

---

---

Copyright © 2013, Computer Systems Design & Associates. All rights reserved
Terms of Use. Privacy Policy. Last modified: 24 June 2013