We all say we want to learn new things, but the first part of learning is admitting your ignorance. Little kids in elementary school have no problem with this. They’re learning new things every day – every minute – so absorbing new information comes naturally.

But as we get older and gain some measure of competence in our careers, our hobbies, and the world in general, we also tend to ossify. We don’t want to learn because we don’t want to acknowledge that we’re inexpert.  Learning a new language means preparing to make a thousand dumb mistakes, garbling the grammar, and sounding like a hilarious idiot to native-speakers. Learning about wine means first acknowledging you don’t know much about wine. It’s the same for electronic engineering and programming. To get better, you first have to concede that you’re not already the best. And that can be hard, especially when you’re confessing your inadequacies in front of your peers.

Doctors and priests owe a duty of confidentiality to their clients. You can tell your doctor or psychologist anything and it will never leave the room. “What happens in the exam room/confessional, stays in the exam room/confessional.” For programmers, that guy is Jack Ganssle.

Jack has made a career out of programming embedded systems, which then morphed into a career teaching others how to program embedded systems. One of the most persistent roadblocks he encountered was the belief among his clients/disciples that they already knew how to program embedded systems. It’s hard to teach something new when your students think they already know the subject.

So Jack targeted the programmers’ bosses. As a rule, the head of a large software team or engineering department isn’t an active top-notch programmer (at least, not anymore). Thus, the bosses were more receptive to Jack’s suggestions. They also had less ego on the line. After all, Jack wasn’t telling the boss how to write better code; he was telling the boss how his/her underlings could write better code. That’s less threatening.

A bit more subtly – and this was a crucial point – it was the boss, not the programmers, who often stood in the way of better code. By educating the boss and the coders simultaneously, Jack found that the development teams could produce better code with fewer bugs, all while staying on schedule and within budget. A win-win!

Jack’s “Quick-Start Guide to Firmware Engineering” emphasizes metrics and discipline above everything else. If you’re going to call yourself a “software engineer,” then start acting like an engineer. Programming is not art. It’s not something you do when the mood strikes you and your Muse is indulgent. It’s a profession, so act professionally. That means numbers, metrics, and discipline are all important.

That starts with version-control systems. Most of us are familiar with versioning systems of one type or another, but surprisingly few teams actually use them religiously. Without versioning, things can get out of hand very quickly, and the team is forced to fall back on institutional wisdom and peoples’ sketchy memories.

For many years, I conducted a survey of embedded programmers and asked them (among other things) how much time they spent planning their code, writing it, debugging it, documenting it, reviewing it, and so on. One of the takeaways was that programmers spend more time debugging their code than they do writing it. That’s just nuts, and Jack agrees.

If debugging is the act of removing bugs, then programming must be the act of putting them in. His solution is to sit down for regular code reviews. Don’t start writing code until you’ve planned out what it’s actually going to do, and then agree on those boundaries with your fellow programmers. Meet regularly to review your code with your peers. Use automated code-inspection tools combined with human eyeballs. Look for bugs in every single line of C code. Sure, it’s tedious, but so is debugging. Bring pizza if that helps.

Error handlers are the worst. They’re designed to catch hardware failures, software failure, or operator failures, yet they’re rarely tested very well. Over the years, Jack and others have found that error handlers have, ironically, a higher failure rate than normal code. Comb through your error handlers with all the automated code-coverage tools you can find.

Spend like a drunken sailor. Really. Programmers are expensive, so anything you can do to cut the amount of time they waste on debugging and head-scratching is money well spent. Forget $1000 code-development tools; spend $10,000. Heck, if you can find a $50,000 tool, buy that, too. It’s a drop in the bucket compared to what it costs to feed a team of programmers working overtime before a shipping deadline.

Back when I had a real job writing code, I ignored about half of the warning messages my compiler would spit out. I mean, it complained about everything. I routinely skipped over the first 40 warnings or so, because they were always the same: nit-picky complaints about syntax or references or variable names. The same warnings popped up every time and just became part of the background noise in the process. I wanted to find the real mistakes. The warnings were just the compiler company showing off that they knew the ANSI C standard backwards and forwards.

You know what? I was wrong. As Jack points out, you should strive for completely warning-free code. For starters, that eliminates even small lapses of sloppiness. It also enforces rigor. And it keeps every programmer’s code consistent with everyone else’s, because if you’ve all got the same compiler looking over your shoulder, you’re all going to write equally squeaky-clean code. But most of all, warning-free code helps you (and the person who eventually takes your job) years later when you recompile that code and wonder, “was this one of those ‘okay’ warnings that I could ignore, or is this a new warning that I need to fix?” Today you can remember to ignore the first 40 warnings, but tomorrow you won’t remember if it was 40, 39, or 41. Better to have zero warnings and treat any that do pop up as significant.

Finally, leave your programmers alone to do their work. There is definitely a creative aspect to programming (as with other engineering disciplines), so it’s important to leave the talent pool alone with their thoughts. Don’t invite them to marketing meetings. Don’t pop in to ask how it’s going. Don’t pair them up in cubicles in a noisy open room. Don’t phone them, don’t email them, and don’t interrupt them. Give them a relatively private space and make sure they believe it’s a private space. Humans and other animals get stressed if they think they’re exposed, so the expectation of privacy is just as important as the reality. “This is a programming zone. Stay the hell out.”

In the end, you’ll have happier programmers (or be a happier programmer). If Jack’s observations are any indication, you’ll also have better code. It’ll cost less to produce, because everyone involved will be spending their time more productively, with less debugging. And the schedule may even improve, since debugging is such a time-sink. Maybe spend the savings on pizza. And art.