MP3 Audio [24 MB]MPEG-4 AAC Audio [20 MB]DownloadShow URL

Yes, I know. This title is provocative. It’s challenging. But let’s have a closer look. For simplicity let’s take the approach and equal famous with becoming a recognized expert. There are two ways to fulfill this request:

• You become an expert by declaration
  You know these situations, somebody arrives at your desk and addresses you as the expert for whatsoever. If that happens several times and constantly you can admit that there must be something that others consider you as an expert.
• You become an expert with 10.000 hours of experience.
  That’s the well known rule of thumb. After a significant amount of time working in a particular environment it can be assumed, that you have become an expert

But are both rules true? And are only these rules of observation available? I assume that as many times the truth might lay somewhere in between.

In my opinion becoming a famous engineer depends on your individuality. Your personal intention and motivation to do this job or profession. Mainly driven by the question, how your special approach looks like when facing different tasks and challenges. Over the years I have observed several ways how individuals become famous – but not all of them were successfull. I have extracted five basics within Embedded Systems to make your approach to become a famous engineer successfull.

Getting closer

To come closer to these basics, let’s first look on the entry statement from a slightly different angle. Let’s change it into the question: “Why does it seem that complicated to achieve the right knowledge to become a famous Embedded Engineer?“. There are several reasons, but mainly:

1. Embedded Systems are different from regular computer systems. Let’s face one definition of Embedded Systems:
   Embedded systems are limited stand alone computing devices usually dedicated to perform limited computing functions reliably, securely and with minimum upkeep costs.
2. Embedded Systems are a combination of hardware and software.
   1. This increases the complexity of the system impacting the behaviour of the system over the time, i.e. race-conditions, etc.
   2. And Embedded Systems arevery often quite hard to understand
3. The most challenging problem however is, that there is no dedicated education to become an Embedded Engineer. “You learn something, but you do not know whether it is the right thing.”

What’s regularly learned?

Regularly during computer or IT studies it is emphasized to understand abstraction and object oriented approaches. On the agenda are a lot of scientific details, combined with abstracts about  creation and design, processes and methods. However, is that really the knowledge which is needed for a successfull Embedded Engineer? This leads us to the question:

What type of engineer is needed?

There are 3 main aspects a successfull Embedded Engineer needs to consider:

• Thinking in small systems
  the systems you are working with as Embedded Systems are regularly smalls systems in a matter of hardware resources and therefore also software capabilities. How well do this system match the required functions. And if it matches how well can it be maintained?
• Thinking in limitations
  working Embedded Systems is a never ending story of limitations. What’s limited within these?
  • Processing capacity
  • Storage capacity
  • Energy efficiency
  • Resposiveness
  • Reliability
  • Integrity
  • Handling
• Cross-functional thinking
  An Embedded System is a combination of hardware and software. The designers, implementers, testers and their leaders needs to be able to talk to each others across departments or industries. The Hardie (You know that? Don’t you? The hardware-engineers are hardies) should be able to discuss and understand the Softie and vice versa. Systems like the control of a big excenter-press (800 to of press weight), need for electro-technicians, system-Engineers, mechanics and software-specialists working close together. And they all need to talk together, understand each other and finally agree with each other.

5 smart principles to become a famous Embedded Engineer

Now the pieces come together. Here are my five smart principles you become a first class Embedded Engineer.

I will give you a short action for every principle. Give it a try and test your own level.

Limits, limits, limits

Embedded Engineering means dealing with limits. Every Embedded System has tons of limitations. You should know them all. At least the ones impacting you. Whether this is the available RAM, the temperature-range, the CPU-power, the other applications, the Operating System, the network bandwidth, or whatsoever.

You should know the overall architecture to understand the limitation of your system. If you’re only looking into your Eclipse-based development environment or dealing with your Hardware-simulator you will never understand the big picture. It should be one of your major desires to understand the system in general. This will simplify a lot of your things. Don’t hesitate to read architecture documents. Ask the architects if you do not understand. Start asking your senior engineers that they provide you knowledge and information. Don’t be shy.

Action #1: Dig out the limiting details about the system you’re currently dealing with. Try to understand the implications of these limitations. And point out how these implications change the system itself and the way you have to deal with it. (I’m sorry that I have forgotten this action in the podcast-episode).

KISS-principle

Keep-it-simple-stupid means to make things as simple as possible. Very often problems are overcomplicated by the engineers. But the break-down is not done to a sufficient level but stopped before leaving too big chunks. Therefore some small guideline to become as small and simple as possible:

• Task breakdown into sub task; 4-12 hours each
• Problem breakdown; each problem one or very few classes/functions
• Small methods – no more than 30-40 lines; only one use-case solved not many at once
• Solve before coding not vice versa
• If you’re smart enough to break down on-the-fly then do it. But refactor on all means over and over again.
• Do not be afraid to throw away code
• Following these advices leads to minimal code
• For all other scenarios: keep it as simple as possible. That’s the hardest pattern – because it needs time!

Action #2: Check today where you can be more simplistic in your work.

Thinking out of the box

Change your perspective. You’re regularly only familiar with your perspective on your piece of work. But later on, when the system is in operation you will not be confronted with this view any longer. Instead you get the tester’s view or finally the customer’s view. Therefore make yourself familiar with other perspective on your system.

Be aware that your will get a different perspective on the system when it is used in operation. You’re not longer receiving your algorithm based view. Instead you get the view spend by outsiders. And the bad news is that it will be your task to prepare yourself for this difference. You will be asked for the reasons of the observed problems. Even without having your logs available..

And all starts the way how you will comment and instrument your code. Imagine the code running for years. You will have forgotten the internal way of working of your code. Thus you will not understand your own logging. It only shows the algorithm working – and that’s what you do not know any longer.

Change that! Change the way you instrument your code. Change your perspective on your code. Get into the perspective of outsiders, of testers, of customers. For me this is an essential principle because if widens your view on your system. It makes things easier to understand if you’re not limited by your own (small) angle of view.

Action #3: For the next week whenever your start implementing code take into account that you will see your code first again in 5 years. Adapt your comments and outputs the way you understand them initially even you have not handled this system for 5 years.

Test on real systems

Very often Embedded Systems are tested using simulators. But, I have never seen a simulator for Embedded Sytems which is a 100% equivalent of the real system. Even the NASA will not rely on simulators but create an exact duplicate of the system in use.

Simulators fail for several reasons:

• not fully implemented features of the real systems,
• distracted timing and function conditions,
• irregular behaviour in operation,
• or simply some implementation errors.

All the time you might follow the simulator’s results might weigh you wrong safety!

The time saved by parallel development of hardware and software has regularly to be spend back to harmonize the non matching hardware and software systems. I have seen differences in simulator and real hardware that big, that they have had to reimplement major parts of the software. Or there are new versions of hardware available which are no longer matching the existing simulators. You see – the alleged benefit will be thwarted into a major drawback.

Action #4: If you have not tested on the real system – prepare for tomorrow to get a first run. Get the results and fix your glitches and problems.

Looking over the fence

Famous engineers are opening their eyes, their ears and sometimes their mouth. They are aware of the main trends in the industry. They do not get stuck in their area for ages. They are in touch with the on-going stuff. They are in constant touch with new streams in technology like Internet-of-Things or general problems like security and integrity.

Make yourself a listener and a viewer. What’s happening in your industry? Diving deeply into details is fine, but do not get lost in your very deep drilling hole. You might reach back and it’s dark aside because everybody has gone somewhere meanwhile. Be attentive.

Action #5: Discuss with your colleagues and friends about the main trends in the Embedded Systems and IT overall.

Finally…

How to become a famous engineer?

How do you experience famous engineers? What exactly do these guys do differently? What’s your perspective? Give me your feedback.

Thank You For Listening

Out of all the podcasts available in the Internet you tuned into mine, and I’m grateful for that. If you enjoyed the episode, please share it by using the social media buttons you see at the bottom of this note. Also, I would be very happy if you would consider taking the minute it takes to leave an honest review or rating for the podcast on iTunes or Stitcher. They’re extremely helpful when it comes to the ranking of the podcast. For sure I read every single one of them personally! Or, if you prefer a more direct contact, don't hesitate and drop me a note at feedback@embeddedsuccess.com