It starts with an LED

• Software Development
• Miscellaneous
• Education

And slowly builds up from there.

I have been an embedded software engineer for many years. I was programming when I was a teenager before then, as a high school student involved in an NSF program called "National Science Foundation Summer Science Training Program (for High School Students)" or as we would rattle off during that summer of exquisite learning, NSFSSTP. We were taught to program in Fortran and taught the fundamentals of Calculus. It was a very enriching experience.

When it came time to choose a career, it seemed natural that programming would be the thing for me to do. But at the time, Cobol was king, and embedded was relatively unknown, so why embedded software?

As with all such things, it seems that it was mostly the culmination of a lucky series of accidents. In this case, the accident was a book called "De Re Atari" by Chris Crawford.  (You can find a copy of it at http://www.atariarchives.org/dere/ ) For a young geek such as me, it was a wealth of information, and talked a great deal about the inner workings of my Atari 800. Things such as the graphics chip set, the joystick controllers, the expansion port and so on.  I spent a great deal of time plucking away at the keyboard of that toy computer, making the screen flash and things happen.  However, what held my fascination the most was a simple article about how to make an LED turn on using an IO port.  That magical 'click' of realization that happens when something so simple, yet so profound suddenly resonates in a person's mind happened to me then. The realization that "Hey! I can make this computer *DO* things, not just text things on the screen. REAL things, like making motors spin, lights light, and relays click."  I was hooked. Deeply, utterly and completely hooked. 

It's been nearly 30 years since that magical day and I have not looked backed with regret once over the choice I made that day.

I have remained an individual contributor my entire career. Yes, I have lead projects, mentored individuals, and architected solutions, but through it all, I have always kept my fingers in the hardware.  Through-out this journey, I have amassed a huge array of tools and tricks that have allowed me to debug problems that I have run into.

The common theme that I intend to keep here, with this journal, will be just that. Sharing those tips and tricks. However, as an older engineer, I have also come to realize that it's not just the tools of the trade that are important, but also the design process, the decision making process, and the process of balancing design decisions with business decisions. I have learned many lessons about those sorts of things, and those are also what I would like to share with you.

It's interesting to watch peopple grow and change in their careers. To see how they learn to be better engineers, and to see what decisions they push forward as 'good' and what decisions they decry as 'bad'. It's even more interesting to see how those change over time.  You see, engineering isn't just about bits , bytes, diodes and ic's. It's about doing what's right, when it's right, and, hopefully, understanding why it is right.  That last bit, the understanding, seems to take the longest.

So join me! Read what I have to write, and share with me your thoughts on them.

I look forward to the teaching, and the continuance of the learning, for I have a lot to share, but a great deal more to learn.

See y'all in the ether.

Sincerely,

Richard Dorfner

Sign in