What are the skills that you feel have made a significant positive difference in you Embedded Engineering Career and why?  

Once we are done with this thread, I would like it to be a place for readers to not only find a list of skills to learn/get-better-at in order to make them better Embedded Engineers, but also a source of motivation to get going.

Thanks in advance for your participation and for taking the time to write something that could be useful to someone else!

#FAQ

I have been programming since the old days when assembler was the king (good old days when you had absolute control of the CPU), nowadays with C programming and huge ROM memories the programs are becoming a huge mess difficult to read and follow.

I used to have an elephant memory, when debugging, I could know which line of code contains the bug according to the watch variable. Now try to remember a 32-bit register set by magic numbers.

Becoming a middle age man with a lower ram, I must optimize my framework to perform in “this project is for yesterday” days.

This is my list that will help you to continue motivated and love the embedded world!

A. BE ORGANIZED:

 -Organize your work in folders. This sounds silly but is very important, having a folder with the chip’s documentation, libraries, application in a single place will save you a lot of time. Do not be afraid to have file duplicates this is just for organization purposes.

-Backup your work. Even if you work in a share environment, make your own copies. Remember, hard drive space is cheap and if you follow a good folder structure you just, right click, zip and name day_month_year_version.zip; I do at the beginning of the day, so if the today version contains a lot of bugs, I can come back in time to compare with the working code from yesterday and last week.

-Code revision. Once you have a working code, commit your code and add a version review. For future versions add change log. Here you can delete your old copies and zips or put old copies in an external hard drive.

B. BE DISCIPLINED: (You can follow, or you can create your own rules!)

-Follow a programing code standard. Check if your compilers are compliant to C99, ANSI C, etc., in that way you can port your code to different compilers and/or toolchains.

-Follow a code coding standard. The compiler is not almighty bugs appears and could be hard to track. By following a code standard, you could reduce bugs, your code is easy to read and gives that feeling of “this is a work of a good professional”. Read Embedded C Coding Standard by Michael Barr or follow MISRA-C directives. For example. Add _t to structure names (my_structure_t) or p_ to pointers, p_my_pointer; by doing that the code speaks for itself.

-Use static coding analysis software. Do you use lint to check your code? This tool could teach you how to code C/C++ like a pro.

-Do templates and use code completion tools. Do you know that you can create your own Code Snippets?

C. BE COMMUNICATIVE

-Document your work. The documentation is not for someone else. Have you try to reuse your own code or PCB design and think “what I was trying to do here?”. Writing code is like writing a novel, it follows your mind state.

-Use pseudo-code and the “to do list”. Someone can thank you later, even your own self.

D. Adaptability:

Do not stick to one MCU or manufacturer, having the ability to choose from abroad catalog gives you the advantage, to do that, you have to read datasheets and try different MCUs, sensors, OPAMPS, etc. Go to a job interview and answer I only know how to do it with apples! I mean Arduino. I mean…you know what I mean? Do you?

Once you get use to read datasheets you can develop your psychic powers. Those psychicpowers will help you to understand the documentation. Have you read a page in a datasheet and ask to yourself “Say what?” (this can be very frustrating).

E. Conflict Resolution.

Go to a meeting with software engineers, electronic engineers and CEOs, then you know what I am talking about.

Try to show how the skills from A to D are useful for you. 

(Skill A) Ask yourself if this is only a problem of organization, can we implement a software strategy (share folder, server, etc) to put all the information together, so everyone can track the project? Can we schedule a project revision? Can we commit our changes and check if the electronics follow the software? Can we schedules small test? Do we required review the client requirements? Are we in the good route? .

(Skill B.) Ask to the team, which standards are following and make sure that we are following. Standards and rules can be changed so is good to be updated or ask for changes.

(Skill C.) Check if other teams are doing the documentation, share your to do list and make sure that other teams know your requirements and make sure that you understand theirs.

(Skill D.) Don’t be the gear that do not want to fit, sometimes changes must be done and because you can adapt your programs or reuse your work you can be the one that solve the problem or the one that offer a better solution.

F. Self-motivation

This is me most important skill. You need it because the embedded world is so dynamic and you need to adapt to new trends, new coding ways (HALs , RTOs), software tools, etc.

So, keep yourself motivated and do not be afraid to try new stuff. Some software developers hate electronics, and I know electronic engineers that do not like to do a line of code, they do not even read the software library code and/or documentation, they just plug'n play (#define) and then say, “this is not working!”.

Keep moving and update your skills, don’t be the assembler almighty that hates C, or the C developer that hates C++, or the we must buy Proteus because is the one I know.  

Having been doing this for thirty years, still loving it, and intending to keep doing it for as long as possible, I'd have to say the most important skill is a passion for learning new things. Second would be a willingness to throw away hard-won skill and knowledge and adopt new techniques at the drop of a hat when the marketplace shifts. Third would be a having a broad and general education, because embedded engineering requires the ability to understand the problem domain (oil field? aircraft? consumer electronic device?), related technologies (getting heat out, keeping EMI in, SMD manufacturing, metals, plastics,...) and business drivers (marketplace, BOM costs, volume requirements, etc).

Precise skill sets come and go. At my first job decades ago I laid out double-sided PCBs using Bishop graphic tape. Today I use a CAD system on many-layer boards. Back then I programmed often in assembly language; today mostly C++. FPGAs didn't exist then; now VHDL and Verilog are slowly transitioning to System-C. Water-jet cutting, 3D printing, SMD, BGA, global sourcing, not to mention the Internet, are technologies I use now that didn't exist 30 years ago. On my bookshelf are tomes on computer science, web design, signal processing, manufacturing, business, and dozens of other topics, not to mention a browser bookmark page that is in dire need of better organization. What hasn't changed is the underlying math and science skills, the business drivers pushing innovation, and the reading ability and passion for knowledge I acquired in elementary school.

I will try to be a little more specific in mentioning some of the skills. Engineers possessing these skills are in great demand and will continue to do so in the future.

1. Programming Languages: Embedded C, C++, Assembly, Data Structures, Shell Scripting and Python.

2. Embedded systems: Bare Metal Programming, RTOS and experience working on Multi-core processes.

3. Embedded Linux: Familiarity with building embedded applications on Linux and operating system concepts. 

4. Linux Device Drivers: I have put this in a separate point to stress its importance. There is a lot of demand for LDD Developers and less supply. Engineers possessing these skills are paid insanely high.

5. Github and SVN: Some version control tools to know.

6. Qt: A popular framework used for developing Embedded GUI Applications.

7. OpenCV: A popular open source framework for developing computer vision systems.

8.  Basic understanding of Electronics. For E.g., you need to amplify the output voltage from the MCU, you should be able to figure out how to do this and then do it!  

9. Reading and interpreting the information in Hardware Schematics and Device Datasheets.

10. Good communications skills: This is very important when you are working in teams, during integration process and when brain storming on resolving technical issues.

11. Traits of a Successful Embedded Engineer: Passion, drive to learn, enjoys solving problems, programming, discipline, curiosity, and patience.

12. Agile: Experience working in an Agile environment. A good to have.  

13. Last and the most important one: Stay humble and have a bloody good attitude. Don't let success and victories hit your head. This is one of the most important skill for an Engineer to reach those great heights and have a happy fulfilling career.

EDIT: Another two important one's I forgot to mention:

14. Practice: Code every day!!! and learn by doing.

15. Marketing: An Embedded Engineer should also know how to market him/herself by show casing his/her passion and skills. It will help to attract more and better opportunities. This can be done in various ways:

A. One of the most common and powerful way of doing this is by having your own Blog and Github Repo's. In this way you can show case your technical, writing, communication and coding skills. Just for inspiration, please feel free to checkout my Blog and Github Repo's. May be you'll find something interesting. Another advantage of this is, over a long run, you will also create your own brand and earn some income via AdSense and Affiliate Marketing.

B. Be an active community member in forums like TI, Stack Exchange, EmbeddedRelated, Arduino, Silicon Labs, ESP8266, Analog Devices, BeagleBone etc. Participate by asking and answering good questions.

C. Attend technical conferences and meet like minded folks. This will help develop contacts and gain some valuable information about the current industry trends and other tech stuff.

The single most important skill that I believe embedded engineers need to master is debugging. Debugging is one of the greatest challenges that face every development team. Yesterday I gave a lecture on debugging techniques at Arm Techcon and out of the 60 or so attendees, more than half raised their hands that they spend more than 50% of their time debugging. Some even raised there hands for as much as 80% of their time!

If a typical project timeline is 12 months, embedded engineers are spending on average 6 months debugging and trying to make their system work the way its supposed to! If developers could quickly and efficiently debug their systems, they could get to market quicker, add more features to their projects or focus more on innovation instead of bug squashing. 

- Good software engineering practices. It's easy to get into embedded; you just write a simple C program and blink an LED, and people seem to think that just because you can program in C, then that's the key to working in embedded systems. It's not enough. Good software design involves understanding a number of principles (SOLID, DRY, refactoring, technical debt, etc.) which are not necessary to get things done quickly, but are necessary to get things done well so that your design is maintainable.

Other important skills are tolerance analysis (if you're designing circuit boards) and signal processing (if you're working with ADCs).

I'll second that. System administration. Maintain your own linux system and keep it patched. Know how to download apps from github.com and compile them to run on your system. Know at least 2 or 3 scripting languages.

Continuous Improvement. If you don;t reinvent yourself at least twice during your career then you will be the night shift manager at a TacoBell by age 53.

Know how to touch type.

Understand how automation works. Most of my success as an IC designer came not from what I learned from the EDA industry but rather from what I learned as a manufacturing engineer. Henry Ford knew more about automation than most engineers in the EDA industry.

John Eaton

I have always wondered if embedded design is an art or science. Regardless of it being either or both, an aspiring engineer must have certain basic skills. These skills may be in-born or acquired abilities. Ever growing requirements and use-cases make product development complex by the day and necessitate constant knowledge updation. Way back, I started my career as a design engineer , 30 years ago. All our designs had CMOS and TTL digital ICs. Every logic was implemented only in hardware. For PCB design, SmartWork(anyone heard of it?. I googled and could not get any information) was used. Now we have plenty of commercial and free CAD software with scores of libraries to do the job.

From my experience, I would add the following into the list.

1. Basic Digital Principles : 
   1. Using logical operators in code becomes child-play. For example, on an 8 bit port, you may need to individually read from or write to an individual port pin. 
   2. Internal register handling becomes easy. Division and Multiplication operations can be done faster by shifting right or left. If you know the working principle of logical gates, shift registers, etc, visualizing code functionality is easy. 
   3. "Digital Computer Electronics" from Alfred Malvino is a great place to start.
2. Circuit Protective Strategies: Writing great code may work inside your lab, but if the embedded system is expected to work, anywhere and every time, you need EMI/EMC protective components around the system. your starting point may be, "Getting EMC Design the First Time" https://www.emcfastpass.com/rightfirsttime/
3. Digital Signal Processing : Extracting the required signal and performing accurate measurements has become an himalayan task today. Noise (electrical and electro-magnetic) is ubiquitous and we need signal filtering and analysing techniques to provide right results. Empower yourself with DSP knowledge. Master the mathematical techniques around it. If possible, learn related software like Matlab,etc.
4. Embedded Design Techniques: Buy this book, read it, chant it and relish it till you retire. The Art of Designing Embedded Systems" by Jack Ganssle - https://www.elsevier.com/books/the-art-of-designin..

Never used smartwork, started with OrCAD and Tango, but, this seems like the right time frame.  

vetusware.com/download/smARTWORK

Hello,

I think the most significant, important and useful technical skills are:

1. Hardware architectures.
2. Computer programming: C and Assembly. C is required. No way without it. Some people say Assembly language it's not useful anymore.. This is not true. If you have to program a C library (from scratch) for the architecture you are working on, you have to deal with it (no matter the architecture), basically because it's the starting point.
3. Electronics: in the embedded world you will deal with hardware and software. So I think knowledges of analog and digital electronics are needed.
4. MCUs and FPGAs: you can't run without wheels.
5. PCB design.
6. Linux and Real Time Operating Systems: almost all of ARM embedded devices run Linux. Embedded Linux means being able to develop device-trees, develop device drivers and administrate it. Of course include uboot. Regarding Real Time Operating Systems, most of the 32 bits MCUs can run a RTOS (e.g. freeRTOS) so it's all said as well.
7. Communication protocols.

The list could be longer..

I agree to write as much more documentation you can. Very important, as backing up everything and don't delete anything. Even the most simple GPIO toggle code can be useful sometimes in the future. For example, I recently put my hands back on STM32 MCUs, and I restarted from basic examples (as GPIOs toogle) I made during my self training a few years ago.

During my developments, when I have to deal with a new architecture or a new library, I always make some test or basic examples to start with. This is part of the learning curve.

I also think that the continuous ambitions to learn new stuff is always important, as well as being self-motivated as alvarogramirez said.

Simon

I am sure there are many skills that are going to be listed, (I take motivation as a given) but for me the two most important are reading and memory. Read as many things as you can, especially things like application notes and books (the National Semi Linear Applications manual is still the best example), even if they are not directly related to your current project. There is the implicit skill of extrapolating a solution to your need, but you have to remember the original solution and perhaps even more importantly, where you saw it. 

Places for information:

Magazines, forums, blogs, books, manufacturer data books, applications books and applications notes, exhibitions, conferences, manufacturer/distributor seminars, web sites

The most important skills in your toolbox are ingenuity, curiosity, and logic that every engineering student brings to their first day of their freshman year of college.Your ability to apply that knowledge to the real world while adhering to the KISS (Keep It Simple Stupid) principal will make life as an engineer more satisfying.The more that you understand about the hardware that you create code for, the less it seems like magic when the debugging begins.Creative application of a 4 channel o-scope and a DVM to a buggy microprocessor can kill any bug that comes along as long as you use logic and have the knowledge to apply it strategically.The most important skill, that I constantly draw upon when creating or debugging code in any language, is understanding how a microcontroller actually works, down to the register level.Be curious and delve into the nuts and bolts of drivers.Canned drivers are easy to use, but, there are times that you will have to create your own driver to complete a project or understand how a driver works to successfully debug code.

Never stop learning and don’t be afraid to experiment.In this line of work, there is a reset button.I have been an engineer for almost 30 years and still look forward to going to work every morning.

Almost two hands for Bob11)

My 5 cents: If you will make something fast but wrong, no one will remember you made that fast but everyone will remember you made that wrong. 

From my experience to the moment, the most important skills, is to make a good design from beginning, using that technologies, which you know at a given time: to catch the overal picture of the project, analyse possible bottlenecks, design both HW and SW, robust and scaled as best as you can do it...

Yes, your curiosity will help to know more and understand used things/approaches/methods better. Yes, the debugging skills are important, but more important is to not give up but dig to understand how things work and then do a right design or refactor it.

This skills - to see the overal picture of the project, see its bottlenecks, understand the nature of issues and correct them, have made significant implication to my career during last 15 years. 

What I feel is to know analog, digital electronics and software very well. Analyze how the system behaves in a given situation from all aspects (analog, digital and software) whenever there is a failure. Document the failure analysis and how it was solved, and see such a thing is not repeated in next system.