Jack Ganssle, Editor of The Embedded Muse Jack Ganssle's Blog
RSS Feed This is Jack's outlet for thoughts about designing and programming embedded systems. It's a complement to my bi-weekly newsletter The Embedded Muse. Contact me at jack@ganssle.com. I'm an old-timer engineer who still finds the field endlessly fascinating (bio).

For novel ideas about building embedded systems (both hardware and firmware), join the 40,000+ engineers who subscribe to The Embedded Muse, a free biweekly newsletter. The Muse has no hype and no vendor PR. Click here to subscribe.

Learn to Code in 3 Weeks!

April 16, 2019

Learn to code in 3 weeks!

Such headlines and advertisements sucker the unwary who see a technology job as an entre into the highly-paid tech world.

Then there's the never-ending stream of newspaper stories about the importance of learning to code.

Perhaps, back when simple html drove the web, it was possible to become a web "coder" in a short bit of time. But today, with CSS, PHP, Javascript and who knows how many other technologies that are vital to driving a website, quite a bit more knowledge is needed.

And that's just web design. Where creating a web page is like stepping over a narrow creek, firmware is the Grand Canyon. Take the New York times, a fairly complicated website. The home page this morning is just 339 lines of html long. A typical firmware project is tens to hundreds of thousands lines of code, code which is rife with pointers, interrupts, data structures and much, much more. Though our tools are excellent today, it's impossible to avoid some assembly, at least an occasional dive into the compiler's output. And assembly is impossible to understand without a deep knowledge of computer architecture.

I get a ton of email from folks who want to get into the embedded world. There's no simple answer, other than go to college for four to five years and study engineering. Yes, you'll have to master calculus. No, you'll rarely use it, but there will be some occasions where some knowledge of the math is needed to parse a scientific paper into a useful design. I hate chemistry, but have had to use some in building systems that use reagents to measure properties of materials. Want to build a hoverboard? Better have a good grasp of physics to get those BLDC motors to compensate for the accelerometer's inputs. And have you ever looked at what it takes to drive a BLDC motor? It's a complex real-time algorithm that's changing the input to the windings a thousand times a second in a way to keep Mr. Maxwell happy.

The challenge we engineers face is less coding per se, and more design. How will we solve that problem? What architecture is needed? Should parts be implemented in hardware or software? Or both, say in an FPGA whose "code" changes dynamically?

Some firmware people are pretty divorced from the hardware. But they are not coders. They're wrestling with nasty repository merges, parsing the output of static analyzers, building shell scripts to handle text files, watching protocol analyzers to find comm glitches, and much, much more.

Oh, also coding.

Then there's requirements engineering. Though the jury is still out, it appears to me that the 737 MAX debacle was a classic requirements problem. Getting them requirements right is often the hardest part of a project. Get them wrong, and, well, there could be another 346 deaths.

The most important lesson we should have learned in 2019 comes from that 737 disaster. That's described here.

"Coders" appeal to managers as they are cheap, compared to engineers. But cheap is often expensive. The old saw "if you think good design is expensive, compare it to bad design" applies. The "coders" word is usually used by managers who view software as a necessary evil, rather than a critical part of the value delivered to the customer.

In the embedded world there are few true coders. We're highly trained engineers who design and code, who create the structure and then implement it in firmware. Perhaps we'd be more efficient if we did separate designers and coders, but this seems unlikely to happen. It's certainly valuable to keep one's hands in the dirty business of making the system and getting it to work. The crucible of making things work always teaches us a lot about the limits of what we can actually build.

Desktop developers embrace "programmer" as a job description. Perhaps that adequately captures the limited range of skills needed to crank out a Windows app. Me, I prefer "engineer", a moniker that better describes the breath of experience needed for embedded systems, where hardware and software seamlessly blend together to yield a product.

What's your take?

Feel free to email me with comments.

Back to Jack's blog index page.

If you'd like to post a comment without logging in, click in the "Name" box under "Or sign up with Disqus" and click on "I'd rather post as a guest."

Recent blog postings: