|Jack Ganssle's Blog
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 firstname.lastname@example.org. 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 35,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.
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.
"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:
- How Projects Get Out of Control - Think requirements churn is only for software?
- 2019's Most Important Lesson. The 737 Max disasters should teach us one lesson.
- On Retiring - It's not quite that time, but slowing down makes sense. For me.
- On Discipline - The one thing I think many teams need...
- Data Seems to Have No Value - At least, that's the way people treat it.
- Apollo 11 and Navigation - In 1969 the astronauts used a sextant. Some of us still do.
- Definitions Part 2 - More fun definitions of embedded systems terms.
- Definitions - A list of (funny) definitions of embedded systems terms.
- On Meta-Politics - Where has thoughtful discourse gone?
- Millennials and Tools - It seems that many millennials are unable to fix anything.
- Crappy Tech Journalism - The trade press is suffering from so much cost-cutting that it does a poor job of educating engineers.
- Tech and Us - I worry that our technology is more than our human nature can manage.
- On Cataracts - Cataract surgery isn't as awful as it sounds.
- Can AI Replace Firmware - A thought: instead of writing code, is the future training AIs?
- Customer non-Support - How to tick off your customers in one easy lesson.
- Learn to Code in 3 Weeks! - Firmware is not simply about coding.
- We Shoot For The Moon - a new and interesting book about the Apollo moon program.
- On Expert Witness Work - Expert work is fascinating but can be quite the hassle.
- Married To The Team - Working in a team is a lot like marriage.
- Will We Ever Get Quantum Computers - Despite the hype, some feel quantum computing may never be practical.
- Apollo 11, The Movie - A review of a great new movie.
- Goto Considered Necessary - Edsger Dijkstra recants on his seminal paper
- GPS Will Fail - In April GPS will have its own Y2K problem. Unbelievable.
- LIDAR in Cars - Really? - Maybe there are better ideas.
- Why Did You Become an Engineer? - This is the best career ever.
- Software Process Improvement for Firmware - What goes on in an SPI audit?
- 50 Years of Ham Radio - 2019 marks 50 years of ham radio for me.
- Medical Device Lawsuits - They're on the rise, and firmware is part of the problem.
- A retrospective on 2018 - My marketing data for 2018, including web traffic and TEM information.
- Remembering Circuit Theory - Electronics is fun, and reviewing a textbook is pretty interesting.
- R vs D - Too many of us conflate research and development
- Engineer or Scientist? - Which are you? John Q. Public has a hard time telling the difference.
- A New, Low-Tech, Use for Computers - I never would have imagined this use for computers.
- NASA's Lost Software Engineering Lessons - Lessons learned, lessons lost.
- The Cost of Firmware - A Scary Story! - A hallowean story to terrify.
- A Review of First Man, the Movie - The book was great. The movie? Nope.
- A Review of The Overstory - One of the most remarkable novels I've read in a long time.
- What I Learned About Successful Consulting - Lessons learned about successful consulting.
- Low Power Mischief - Ultra-low power systems are trickier to design than most realize.
- Thoughts on Firmware Seminars - Better Firmware Faster resonates with a lot of people.
- On Evil - The Internet has brought the worst out in many.
- My Toothbrush has Modes - What! A lousy toothbrush has a UI?
- Review of SUNBURST and LUMINARY: An Apollo Memoir - A good book about the LM's code.
- Fun With Transmission Lines - Generating a step with no electronics.
- On N-Version Programming - Can we improve reliability through redundancy? Maybe not.
- On USB v. Bench Scopes - USB scopes are nice, but I'll stick with bench models.