Engineering

Some tips for electrical engineers



Chime in with your suggestions in the comments. We’ll even allow the mechanical engineers out there to participate. Well…maybe.

The following are a few of the tips, advice, rules, or guiding principles, I’ve discovered after many years of engineering and in various engineering positions. I’m not an expert in engineering management; this list is just items I’ve discovered from being in the engineering trenches (or should I say, cubes).

Do you have a memorable experience solving an engineering problem at work or in your spare time? Tell us your Tale

General engineering

  • Trust the math. We’re lucky to be in a profession where many design solutions can be derived using mathematics – it is more science than art. Use the math and trust its results.
  • You can’t violate the laws of physics no matter how smart you are. I’ve been in a room when presentations have been made of a design, but where the basic concept violated some law of physics. These poor people spent a lot of time heading to the dead-end.
  • Be clever only when it’s needed. Don’t design in an “interesting” part into a company project unless it is needed. Save that exploration for your home projects.
  • Build on previous designs if you can. Reusing parts of a proven solution is very good for business, and for your career.
  • Document everything – code, tests, schematics, simulations, sketches. This is for the next engineer and for possible patent filings. It leaves a nice trail of work done to get to a solution.
  • Work on the biggest unknowns first. This brings the risk to a project down quickly. If these issues cannot be resolved, the project concept may be able to be changed to avoid the issue.
  • Estimate a project’s tasks to 8-hour resolution – make a list of all pieces of the project – code to write, circuits to design, mechanical, docs, testing, etc. Typically, you bring a representative of each design section into a room for a number of days. You discuss all areas of the design down to the smallest detail. I have found that if you break it down to a one-day task level, your time estimates will be very accurate, and you also may discover some risks early. Also never assume an 8-hour workday means 8 hours of engineering – many things get in the way. I always use 80% for the actual engineering time in a day.
  • Fight for your time estimates. Management may tell you that your time estimate is too long, and give you a number that is too short. If you do a deep estimate down to the 8-hour level, you should be confident of the estimate and you can, and should, defend it. Don’t get pushed into an impossible time line.
  • Adding people to a project in the middle may slow it down. Management may say they will give you more people. It depends on the project and where in the project you are, but more people can also be a time-sapping burden.
  • Focus on your piece and trust the others to focus on theirs. I often had people tell me how this other team will not be ready when their part is needed. This is for a project manager to worry about. Keep your eyes on your part and make sure you’re ready on time.
  • There is a fog-of-war on large projects. Project details can get lost and confused, especially on a large project. Things get missed in the activity – this is one of the project managers main tracking jobs. Make sure your part is well documented and progress/issues well communicated.
  • Always stay calm. Things will go wrong; project disasters will happen. If you stay calm during these times, you will see that fixing the issue will go much smoother.
  • Make sure all applicable department managers have signed off on the product spec. If someone wants a change, all departments need to sign off after engineering re-quotes the time/cost requirement changes.

Testing and troubleshooting

  • Pay attention to anomalies. Anomalies are often dismissed, but these can be clues to an underlying problem. Document these anomalies for future reference.
  • Ship what you tested – if you change anything, always retest. Don’t assume it will work.
  • Use simulations but verify in the lab as there may be unaccounted-for parasitics. All components can have some level of parasitics; resistors can have capacitance and inductance. Capacitors can have resistance and inductance; capacitance values can change relative to the applied voltage. Inductors have resistance and winding to winding capacitance. Transistors, FETs, and all semiconductors can have various capacitance, inductive, and resistive parasitics. Don’t even get me started on crystals.

Your job

  • None of us is irreplaceable. The company probably wouldn’t collapse if you were gone tomorrow. Management knows that – you need to know that, too.
  • Take care of your career yourself. Don’t depend on your company to move you along in your career. Push for a position you want. Discuss wages if you want an increase. Work to get the training you want and need.

Hardware engineering

  • Never assume a part can be substituted with one from a different manufacturer, product line, or value without retesting in the product.
  • Understand basic practical thermodynamics as it applies to electronics design – this knowledge is needed often in electrical engineering (EE)-type projects. Calculations are needed when using things like heatsinks, PCB heat dissipation, thermal vias, active or convection cooling, heat pipes, etc. Much of this can be dealt with by an EE without the need for a mechanical engineer.
  • Tell your manager that the first PCB assembly will have issues, the second works sometimes, and the third’s the charm. I’m not sure I’ve ever seen a PCB be perfect on the first pass (except maybe a very simple one). Problems can be EMI issues, schematic errors, assembly issues, pad/trace tweaks, mechanical issues, etc. The latest layout and simulation tools help a lot, but they won’t tell you that you spelled the company name wrong on the silkscreen.

Firmware engineering

  • Don’t write obfuscated code. If it seems a bit cryptic, then document it well. ( I actually saw production code with the line “Bet you don’t know what this does”.)
  • Stop using so many pointers.
  • All code has bugs, even yours.
  • Use a coding standard – consider MISRA guidelines.
  • Use lots of comments – at the top of the program file, at the top of every procedure, the top of large conditionals, and on all cryptic statements.
  • Adding your comments to AI-written code will help assure that you understand the code.
  • No magic numbers in the code – if you have an actual number in a line of code, consider if it is better defined in something like a #define or const.
  • Keep fixing code to remove all warnings from your compiled code – fix anything that shows an error code, at any level.
  • Minimize the use of global level variables (I’m admittedly a serial violator of this crime.)
  • Always check to see if pointers are in bounds. You may be creating unstable code along with security issues.
  • Consider using AI, because it can often speed things up. Then again, though, it can also slow them down. My experience is that it can write very nice-looking code that typically compiles, but often there are subtle errors, especially on boundary conditions. So, don’t trust but verify, but suspect and test.
  • Avoid dynamic memory allocation if you possibly can. This can very quickly lead to hard-to-understand crashes.

For managers

  • Employees are expensive, and equipment is cheap if it speeds their work up. Get them what they ask for.
  • Employee training is important – encourage and pay for expos and classes. Set up vendor presentations (and buy lunch).
  • Encourage patent filings and implement bonuses for filed and granted patents. Patents are good for the company portfolio and the employee’s morale, as well as your recognition of support.
  • All engineers have a type of engineering that they are good at. They may good at systems engineering, clean-sheet-of-paper designers (those that can design a device from scratch based solely on a concept) , lab test engineering, simulator/modeling, maintenance and component engineering, estimating/spec writing, customer facing or not, field engineering, analog and digital engineering, EMI/EMC experts, etc., etc. You wouldn’t assign a digital engineer to do a complex analog design; in the same fashion, don’t assign an engineer that’s good at analyzing field data to a clean-sheet-of-paper task (and vice-versa).
  • If you lead, supervise, or manage, never ever micromanage. This is discouraging to an employee. If you think they’re not performing, ask if they need assistance. If you think they are in over their heads, back off their task list or move them to another task or project.

For everyone

  • The 50% rule – this is my rule that states that 50% of the information you get from a user, having an issue with a device you designed, will be misleading or untrue. That doesn’t (hopefully) mean that they lied. It means they exaggerated, interpreted what happened and gave you the interpretation, mis-remembered a sequence of events, or used incorrect terminology (for example, said that the device died instead of that the screen or keyboard locked up). All data from the field must be vetted before digging too deep. ( I’m being generous with 50% because I actually believe the occurrence of this is more like 75%.)

I’m sure all the engineers out there have many other tips to add to this list. Let’s see some of yours in the comments. We’ll even allow mechanical engineers to chime in.

Damian Bonicatto is a consulting engineer with decades of experience in embedded hardware, firmware, and system design. He holds over 30 patents.

Phoenix Bonicatto is a freelance writer.

The post Some tips for electrical engineers appeared first on EDN.



Source link