|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 email@example.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 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.
Why Did You Become an Engineer?
January 28, 2019
Many years ago my son was tasked with a high school assignment to build a circuit to re-encode a bank of switches. The teacher expected a simple diode-based design, but I suggested tossing an embedded computer in, so if the problem changed the solution would a simple software change. Also, of course, the thought of tweaking the instructor was appealing. When Graham got the thing working, the flash of excitement in his eye was a tremendous reward. He built the project, he wrote a little code. And it worked.
That's exactly why I became an engineer.
Engineering is the art of solving problems. "In order to make a machine that does X, I have to figure out how to design some hardware and firmware that does Y." Puzzling out these solutions is both an intellectual challenge and a game. Am I smart enough to do this? What will I have to invent?
Problem solving is its own reward. But it's not enough, for me at least. I want to make something that works. Not push paper, not write proposals, not document someone else's creation, though all of those tasks are an inescapable and wearisome part of this profession. I want the thrill of seeing the motor turn, the LEDs blink, or a message marqueeing across the display. No doubt that "I made that work" satisfaction is rooted somewhere in the same brain center that rewards gamblers and addicts.
Many developers work on large projects that take years of effort. More power to them, but I could never do that. I want to see something work, relatively soon. Invent solutions, see them implemented, and move on to the next project. You can have those big government projects that consume entire careers; the thought of being caught in that mill horrifies me. Thankfully others are more patient and will see these efforts through.
I sort of fell into the embedded space as it didn't exist in the late 60s when I was in high school. An obsessive interest in electronics morphed into ham radio, but the important thing to me was always building something. First, learn the material, absolutely. But build a small project to get feedback, for fun, and to get a visceral learning that does not come from books.
Later I learned about programming (rather, became consumed with it), and when the first microprocessors came out was accidentally and fortuitously positioned with the right skills and interests.
To me, embedded is the best of all engineering fields. One person can design circuits. Write code. Often figure out the science, or at least its application. And then make something that works.
In the olden days some companies didn't let engineers work on the hardware. Technicians soldered, scoped and instrumented under the direction of an engineer. Screw that - half the fun is working with the hardware! The irony now is that hardware can be so hard to manipulate - I have a sub-inch-square chip on my desk with 1500 balls on it - that the required special equipment becomes a barrier to that intimate physical manipulation of a circuit that can be so satisfying. If that sounds like some sort of foreplay, well, perhaps there is a connection between those two parts of the brain, too.
What about you? Why did you become an engineer?
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:
- Life in the Time of Coronavirus - how are you faring?
- Superintelligence - A review of Nick Bostrom's book on AI.
- A Lack of Forethought - Y2K redux
- How I Write Code - Comments first, code second.
- 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.