If you’re a fan of the Embedded podcast you know her voice well. If not, you need to check out the show! Of course we’re talking about [Elecia White], who spent her recent holiday answering our questions.

She’s an accomplished embedded systems engineer — she literally wrote the book on it. We’re delighted that [Elecia] agreed to lend us her skill and experience as a judge for The Hackaday Prize!

We find that embedded engineers come from all manner of backgrounds. Can you tell us a little bit about how you got into the field?

I majored in a combination of applied computer science and theoretical systems engineering: my classes were all about programming, C, Fourier, and control loops. I had no idea I’d built a major that would be perfect for low level embedded development.

After school, I went to Hewlett-Packard. I was in the network server division, monitoring servers, writing drivers, and getting ever closer to the hardware. I moved over to HP Labs’ BioScience division to do real embedded work, though I didn’t understand that at the time (yay for a hiring manager who did!). Once I made a motor move, well, it was all over for me. I loved having my software touch the physical world. Happily, the environment was great and the electrical engineers were very patient.

Do whimsical embedded challenges ever come to mind? For instance, do you ever flip on the TV and think to yourself: “some day I’m going to reprogram the uC and write something that works!”?

Yes, absolutely. Though, I tend to have much larger ideas than I have time for.

For example, a while ago, I heard a Radio Lab episode about how different animals see colors differently. That led me to the many ways animals see differently. For example, did you know that guinea pigs see more slowly than we do? Where our retinas see about 8.75 Mbits/s, theirs only transfer about a tenth that. They have fast and slow cells that respond to different visual stimuli. But what would it be like to see through their eyes? Blocky? Slow? With edge detect on all the time? [1]

On the other hand, birds see much faster than we do: things that are just a blur to us are visible to them. Some animals see IR, some see UV. All of these other things could be demonstrated with a processor, a camera, maybe some sensors laid out in a grid pattern overlaying the view from the camera… (and some software (also copious free time)).

So, um, yes. One little thing can set me off and I get on a tangent. I’m a bit of a dev-kit hoarder so when I combine “what should I try on this dev kit” with “what have I been pondering”, I can get lost for days.

PS Don’t get me started on the gear in the recent spate of superhero movies.

We enjoyed the section of your book Making Embedded Systems which covers self-test and unit tests. Do you always build from the start with testing in mind or do you still get bit and have to go back after the fact to add testing routines?

Ideally, I write tests first because they act partially as requirements definition: what should this function do? Though, I tend to do it in short back and forth bursts, breaking down a problem into manageable pieces.

Professionally, it is almost always going back because I usually work on initial designs or on end-of-project-must-ship-now fixing, I seldom get to see a project start-to-finish. Though if I get ownership of a module, I try to do testing right.

Personally, I am often hacking things together and am not always a good, disciplined engineer with that. Projects that I’ve been poking at for a long time tend to have better tests because I keep rebuilding the hardware and software, needing to verify modules. But the projects that I’m trying to figure out what I want to do, well, sometimes it is fun to just hack something together knowing that it might not work tomorrow.

Do you have any advice for managing your professional schedule and still maintaining some type of personal life?

As an engineer, manager, and director, I constantly felt the pressure to work more hours. However, my brain gets tired; the work in hour 50 of a week would probably take ten minutes in hour 2 of the next week. Working long hours for weeks on end makes me extremely ineffective. But I’m not good at figuring out what people expect and there is always something else that needs to be done.

Contracting is good for me because I get paid for the hours I work and don’t feel (very) guilty about unfinished tasks. If I’m frustrated and want to take a break at 3pm, it doesn’t matter as long as I still get things done. That was probably always true but I felt a lot of pressure to be at my desk all the time. Now, I can set expectations for how many hours I allot to a client each week and what I expect to get done in that time, everyone seems happy.

I have a clearer division between personal life and work and a more realistic balance. Though, I write this on the morning of the 4th of July while waiting for cross compilers to build… maybe my advice is not, um, good. Next question?

The Hackaday Prize requires all entries to be Connected Devices. Are there any data transfer protocols that you love using with microcontrollers? What are they and why do they make your development process easier?

While the connected requirement is neat, there are so many ways to implement it so I hope no one gets stuck on it. This is one area where, unless you are building a new communication method, it is easier to buy a good solution than make one yourself.

I admit to some partiality to Electric Imp. They’ve got a lot of the cloud based system ready for you, making an LED that lights from URL takes about ten minutes, making a button that tweets takes less than another ten.

I guess my favorite data protocols are ones with standards, ones that I didn’t invent or don’t have to puzzle out. If it has a Wikipedia page, I like it.

Are there any communications protocols that make you cringe in horror?

Not even CAN.

Wait… Yes, I have a horror of hidden ones, those that you can’t get to the signals on the protoboard. Debugging without access is painful.

Do you approach writing Open Source code differently? Or in other words: are you cleaner with your code and comments if it’s more likely that others will see your code?

A little. I wanted to say no: I try to write clean code always, I always believe my code will be read. However, for open source, I see the audience as me minus ten years of experience. But for industry code, I see the audience as me plus one year of forgetfulness. Since the intended audience is different, my Open Source code tends to be more wordy in the comments.

Tell us about your non-engineering-related hobbies.

I read a lot, both fiction and nonfiction. You asked about whimsical ideas, I read Kraken, a great book about squid and octopus, which brought up the point of how to test such alien intelligences. That still tickles my brain.

I read the fascinating Thinking, Fast and Slow; I think if I wanted to build an AI that acted like people do, I’d implement the chapters of that book as library modules. It would be a fascinating project.

Science fiction is a great way to loosen up creative ideas: what did the author think would be a problem in a hundred (or thousand) years? Other forms of fiction are great for seeing how other people view problems. While I hide it reasonably well for whole minutes at a time, I’m kind of socially inept so when I read fiction, I also tend to see it as tools for helping me interact with people in different situations.

I also garden and watch more TV that I should admit.

What else is going on in your life?

There is our podcast, Embedded. That is fun and strange, focused on people building gadgets of all sorts. I’ve met so many interesting people and gotten such a great response. I started out wanting to know what podcasting was all about. One thing led to another and now, a year later, I find myself being a Hackaday judge.

How can entries curry your favor when it comes to judging? Is there any type of entry you would love to see?

Many engineers often have internalized this idea of once “I’ve done it, it is easy”. Sometimes it leads us to assume everyone knows what we are talking about (because, of course, it was easy so everyone else already knows about it).

We get into the trap of documenting for experts instead of average (or beginners). I don’t think the experts need the docs as much as someone new does.

My advice: document it for another discipline. If your background is hardware, imagine a software person is going to read it. I don’t need to be condescended to, but I do need patience. Tell me what tools you used, maybe link to your favorite intro to the tool (if you’ve got one). Tell me how you made it but also tell me how I can make it.

Also, tell me why you made it. I love enthusiasm.

The Hackaday Prize challenges you to build the future of connected devices. Build the best and claim a trip into space or one of hundreds of other prizes.