Resources for Software Best Practices

A friend and former colleague emailed me this question:

“I’m going to be leading a group of firmware engineers and I’m looking for resources about clean coding, design, code reviews, revision control, coding style, etc. What do you recommend?”

I asked the question around the Embedded FM water cooler and got a lot of good answers, so I’ll summarize them here.

Clean coding, design, code reviews, revision control, style: these all fall under the umbrella of “software best practices.”

The best way to use any advice/resource/information/opinions on software best practices (including this one!) is to follow these three steps, in strict order:

  1. Understand what was said.
  2. Understand why it was said.
  3. Decide if you agree with it.

If you jump to step 3 you’ve missed the point. Steps 1 and 2 are useful even if you completely disagree with what you’ve read.

Absorbing best practices (aka wisdom) in any field takes time. We’re always short on time today, but if you don’t actively make time to learn and think about our craft, you’ll be stuck in today forever. Groundhog Day is a great movie - don’t make it your career.

Given that we have limited time, though, if you read just one thing, start with The Pragmatic Programmer by Andrew Hunt and David Thomas. It’s almost 20 years old (published in 1999), but most of it holds up well, and it’s a good overview of software best practices.

If you read two things make the second one Code Complete by Steve McConnell. It’s a well-written technical tour de force of practical software engineering topics.

After you finish those, here’s a list of books, articles, and podcasts that we’ve found useful.

Books:

Articles:

Embedded FM podcast episodes:

  • Being a Grownup Engineer with Jack Ganssle, about being a good embedded software engineer (hint: it takes discipline).
  • Don’t Be Clever with Dennis Jackson, about drones (and Airware), simple code, and learning.
  • Happy Cows with Chris Svec, about Empathy Driven Development and writing code for your colleagues and your future self instead of your compiler. (I know, I know, I’m suggesting my own stuff, but I really think that empathy is a key to mature, healthy software teams.)

And finally, if your team is hesitant to get started with code reviews, Elecia has a good suggestion: Pick a small, public project (maybe something interesting on Adafruit, or some open source tool you use at work) and review the code together as a team. This way you can learn how to articulate and rank issues as a group and how to review code without getting defensive.

Do you have a favorite book, blog, article, or advice about software best practices? Please share it in the comments!


Thanks to Andrei Chichak, Christopher White, Dennis Jackson, and Elecia White for contributing to this post.