Inspired by a similar question on quora about software engineering, I thought it could be interesting to read some insights from this community of embedded systems engineers.

Thanks in advance for any positive contribution you add to the discussion!

#FAQ

1) Before jumping into coding, thinking, reading/writing, and understanding documents like requirements documents and design documents (however brief.  No need for a novel if a short story will do...)  If there are no requirements, you need to write your own by extracting them from the rest of the team or the customer.

2) In opposition to #1, knowing where the risk areas are and doing some quick proof of principle tests to knock off the square corners before committing to an approach.

3) Knowing when to use more of #1 or #2.  :)  This, as noted already, comes from experience.  And experience, as an apocryphal quotes asserts, comes from making mistakes.  And I would add "from studying your mistakes and the mistakes of others."

Hello, I'm from Argentina. I'm Electronics Engineer and last year, I took a course named "Specialization in Embedded Systems" at the University of Buenos Aires (http://laboratorios.fi.uba.ar/lse/cursos.html). I've finished the first year (it has the option to complete the second year for the master degree) and I feel that I've learned a lot. I think I can resume this in the following:

1 - Think about the firmware not only as a final product, but also think about its life cycle and quality concerns. Software engineering has a lot to contribute in this area: development models, testing, etc. 

2 - Better selection of hardware, understanding the things that you need specifically for your project and select the best suitable microcontroller, adc, etc. 

3 - On the other hand, I think it's important to know very well a family of microcontrollers and write reusable code that works btw different MCUs of the same brand. 

4 - Develop from the big things to the small things. It's better to spend more time thinking about the general architecture of a program, the function of every task, the ways that the tasks intercommunicate, and only then go to write code. The same with the hardware. This leads to faster development of hardware and firmware.

5 - write nice code. Adopt some code style. Use git. Use doxygen. Write a technical memory of the code and the hardware.

1> Better collaboration / integration of hardware & your code. The sooner that happens, the better Everyone is. Since I do both, it's easy, but I've had to write code for those who just threw the hardware design "over the transom" -- I won't say what I think of this.

2> Code reviews of stuff written X ago, and it still looks pretty good. Fewer "what in Hell was I thinking" moments...

3> Better initial approaches - closer on 1st & subsequent passes of how to get from A to B.

My suspicion, the common thread is: to write better code is to write More code. NO substitution for experience. Time in the Saddle (a fave acronym)  G.H  <<<)))

1) Projects which boot up and run correctly the first time, with fewer errors, omissions, or technological 'misunderstandings'.

2) More attention and understanding of the little details, such as the proper location and amount of decoupling caps, workable power and ground planes, cleaner initialization of the processor in the boot-up code, stuff like that.

3) (Given reasonable management and objectives) being able to correctly estimate the time, resources, and BOM cost of a project.

4) As CustomSarge said, fewer "what in Hell was I thinking" moments when revising or upgrading the project later.

1. Creating tools that improve over time. I have a CLI (actually, several) that I use as needed for both development tools (to understand hardware && write the actual drivers), and for the actual systems.

2. Knowing howto mumble with EE's to create good devices that are easy to control. Applies to both FPGA interfaces and discrete chip devices.

3. Ability to understand and do "cookbook" hardware through personal projects. Includes Arduino-level projects and learning hardware tools. Current favorite is kicad - a free and open-source schematic capture and PCB layout tool.

4. Spending a proper amount of time on design. Part of this is not starting implementation before the design is solid.

5. What they said

if you start spending more time on thinking about your code than you actually code.

Cheers!!