Electronics is one of those fields that is tough, complex, and hard to learn, and yet it fascinates like nothing else: the possibility of manipulating electrons according to our wishes is indeed magical. For people just starting out learning electronics, are there things they should focus on? Can they emulate other people and possibly avoid the mistakes that experienced engineers have made?

To answer this question, we interviewed engineers about how they got into electronics, what makes them tick as engineers, and what tips they’d give to people learning electronics — including great resources, books, role models, and ideas. The inspiration for this comes from a Quora question — What advice would you give a EE freshman — which I answered and people seemed to find useful. This made me think that it’d be great if we could expand our answer with feedback from some of Octopart’s own engineers.

Russell is a software engineer at Octopart with a background in electrical engineering. This interview allowed me to go behind the scenes and learn more about Russell’s journey so far. He also had great tips on how to get into electronics. Here we go!  

Sanket Gupta: What do you do at Octopart, and how did you get started here?

Russell Smith: I've been at Octopart for almost four years now so I've touched just about every aspect of the site at one point or another, from frontend to backend to data to design. One of my first projects was an early version of what has now turned into our BOM tool. Now I mostly work on things like building out systems to improve our data and identifying what new features to build.

I studied electrical engineering for my B.S. and M.S., focusing on microelectromechanical systems and microfluidics for my thesis. After graduating, I worked on control systems for medical devices for a couple years, then moved to New York to do a three-month sabbatical at The Recurse Center, which is a free, self-directed educational retreat for programmers. And after that I started at Octopart. I felt the pain of searching for electronic parts in my previous jobs and internships so it was pretty exciting to have the chance to improve that experience for other electrical engineers.

SG: When was your first electronics project? What got you motivated to start in the first place?

RS: One of the first projects I remember building was for a fifth grade school social studies project. Every student was assigned to choose a topic and create a poster board display. I wanted mine to stand out so I decided to add an electronic multiple-choice quiz. If you pressed the button for the right answer a green light would light up. RadioShack didn't have all the parts I needed, so I convinced my mom to take me to the Allied Electronics warehouse (thanks, Mom!).

I remember sitting there at the pickup counter paging through the catalog. When I finally found a pushbutton that looked like it would work and wasn't too expensive, I put in the order. But when it came out it was just a plastic cap for a pushbutton! I had assumed that a part that costs $2+ must be an actual pushbutton. But it was just the cap. I was a little embarrassed but was allowed to exchange it for a real pushbutton.

I remember getting Allied catalogs on CD in the mail after that, if that gives you an idea of what era this was.

An old Allied Electronics catalog

SG: What sites and resources did you frequent? How did you go about getting new ideas?

RS: At some point I got my hands on a RadioShack 300-in-1 kit and a couple of Forrest Mims books. There was a subscription to Popular Electronics, too. I also remember there were a number of electronics homepages on the web, where somebody would post a bunch of their favorite circuits. I'm sure many of these have disappeared but Bowden's Hobby Circuits is one I remember.

A crystal radio amplifier from Bowden’s website

I learned a lot by taking things apart. I remember pulling apart a broken clock radio one summer and desoldering all the parts from the board. At one point I used a wireless doorbell and 555 timer to create a remote trigger and self-timer for a cheap digital camera. And I was also given free reign to poke at the family computer as long as no irreversible changes were made, starting with our first computer, an IBM 286. But I never had a good understanding of circuit analysis until my college classes. Understanding where the formula came from to pick a particular resistor value for an oscillator circuit felt like some kind of deep magic.  

SG: What projects did you build after learning how to design circuits?

RS: One class I took was entirely lab-based, and we had a new project every week — things like designing a switching power supply or motion-tracking laser. I learned to use Eagle to design PCBs for class projects. My senior design project was an ATmega-based Bluetooth password manager. And for a grad-level biomedical circuits class the project was an in-ear EEG recorder. These were two-layer boards ordered from Advanced Circuits (looks like they still have the same student pricing). This was a nice step up from my high school days when I etched my own PCBs using the toner-transfer method and HCl/H2O2 from the hardware store for etchant.

SG: How can electronics design be made easier for beginners?

RS: I think it's helpful to compare the experience for beginners in software and hardware. Someone new to software can read through Learn Python the Hard Way and build a toy social network with the Flask web framework, and then they have a good starting point to build any web app that comes to mind. But if you pick up an Arduino and follow a tutorial to wire up an LED and make it blink, where do you go from there? Blink a dozen LEDs? 

Software has the luxury of being able to build up these really clean abstractions so that, for example, with the Flask web framework you don't actually need to know anything about networking, HTTP, or concurrency when you are just starting out building web apps. But in electronics it's harder to separate the concerns. If you're working on an embedded project, pretty soon you're going to need to know about the control registers on your MCU or about floating point arithmetic gotchas. If you're interfacing a sensor over a high-speed bus you need to know a little about electromagnetics to maintain signal integrity. And if you want to do something as simple as interfacing a motor you need a basic understanding of circuit analysis or else you'll make your power rails dip or fry your MCU. And then as you're about to drop another $10 into a new dev board you'll think to yourself that maybe you're better off just sticking to software. This is sort of just the nature of working in the real world where the rules are set by physics, not designed by humans.

So I think there are two things that need to happen to make it easier for beginners: one is better abstractions to wall off the complexity (but not hide it entirely), and the other is a smoother ramp-up to the minimal base of knowledge needed to be an effective electronic designer.

Platforms like Arduino and Raspberry Pi have been fantastic at bringing more people into the world of electronics. Things like Arduino shields with freely available driver libraries lower the barrier to entry, and open hardware and software at least allow you to see what's going on under the hood. But I'd argue that these are hiding the complexity under the rug instead of addressing it head on. Most embedded systems are fundamentally signal processing systems, so why can't we program them using abstractions from control theory instead of twiddling bits in the PWM register?

To the question of the learning ramp-up, I do think it has gotten much more accessible with the large expansion in the range of resources available for learning electronics. MOOCs make the course content of top universities' circuits classes available for free. YouTube channels can explain the hard-won practical advice that comes in handy in the lab. Adafruit and SparkFun pair high-quality tutorials for common projects with an easy path to buy the parts you need to build them. So now I think a lot of the difficulty is not in getting access to information, it's sorting through it all and deciding what to ignore and what's the quickest way to learn what you need.

SG: What tips and resources would you give for people starting in electronics?

RS: I highly recommend the book Practical Electronics for Inventors. It does a good job of covering the full range of basic electronics while combining intuitive explanations with just enough theory. The Circuit Designer's Companion covers all the gritty details you need to turn a prototype schematic into a robust PCB design and BOM for manufacturing.

No electronics workbench is complete without a copy of The Art of Electronics. It's sadly not as relevant in day-to-day EE work as it once was. I mean, let's say you need a headphone output in a design. Are you really going to design your own DAC and amplifier stages? No, your boss is going to yell at you if you do that. You're going to drop in a $2 TI or NXP codec chip and call it a day.

 

 

Some great books for learning electronics

But even though this makes the electronic design process faster, sooner or later you'll need to know why that codec is glitching, or why the ADC in your MCU is drifting, or where the ripple on your switching regulator output is coming from. And that's why it's good to have a copy of the Art of Electronics lying around.

For analog electronics, it's hard to beat the app notes and magazine columns from the analog design greats like Bob Pease and Jim Williams. Bob Pease also wrote the fantastic Op Amp Circuit Collection app note for National.

For embedded, I'd say just pick a microcontroller, find a good tutorial, and start building a project. At a more advanced level, I'd recommend An Embedded Software Primer and the AOSA chapter on FreeRTOS.

There are now so many high-quality blogs, podcasts, YouTube channels, and tutorials out there that it's hard to list just a few. These are a great way to learn how other people design things.

I'd say it helps to simulate circuits. And that doesn't just mean LTSpice. I used Paul Falstad's circuit simulator a lot in school. It visualizes the voltages and current flows so it's really useful for checking your understanding.

Paul Falstad’s circuit simulator visualizes current

And of course there's no substitute for breadboarding circuits or soldering them up on protoboard and checking their operation with a scope. The Octopart guide to what to stock in an electronics lab and Common Parts Library for Prototyping are good resources for setting up a lab.

SG: What should an electrical engineer focus on in college?

It's hard to give generalizable advice here. I’ve been consistently surprised by what turned out to be useful. And I could name a number of semester-long classes where I would have been better off just flipping through the book in an afternoon. So a lot of it is just developing an understanding of the extents of the field, and knowing what you can dive deeper on if you ever need it. Nobody can be an expert in everything, so you want to combine a broad base of knowledge with deep expertise in a few specialties.

One thing to keep in mind: it's important to know how those specialties play out in the job market. For example, if you want to do IC design, you're probably looking at a grad degree and internships before you're qualified for entry-level positions. Or for some specialties the only path may be in academia. So it's important to make sure the specializations you're choosing match with the career path you want.

The next thing to keep in mind is that technology changes quickly, and the pace of change has been accelerating. I remember in school coming up with all these ideas for projects to build. Things like an accelerometer-based sleep tracker. Or hacking a Wi-Fi–enabled grayscale–LCD handheld device to run ssh so I could check email. Then in 2007 the iPhone came out. You can't control the future, but you can develop confidence in your ability to learn on your own and adapt to change.

Finally, if you want to find solutions to problems that haven't already been solved, one of the best ways is to look to other fields for inspiration. The most enduring concepts I've taken from my education are ones that cut across domains and help make sense of patterns in a variety of fields. So I think it's helpful to have a good base in fields like physics, math, dynamic systems, and CS fundamentals. Also, biology has proven to be one of our best sources of examples for building resilient complex systems. And statistics will always be important since it gives us techniques for understanding the "territory" when we can only directly interact with the "map."

So if you want to work in electrical engineering, at the intersection of the information domain and the physical domain, you can find a lot of inspiration by looking for parallel problems in other fields.

SG: Any thoughts on programming for EEs?

RS: One thing I've noticed among some EEs is that there is a tendency to write off higher-level software without any clear justification. This idea that "real programmers" work in C, asm, punch cards, and solder — and anything else is a cop-out. I got caught up in this to some extent, I think in part because when I started programming my sense of taste was shaped by game programming forums. I fortunately did take away the lesson that it's better to do things the hard way and understand how they work all the way down the stack when given the choice.

But I also mistakenly believed that since I already understood for loops, struct byte alignment, hash tables, and time/space complexity, everything else in the software realm was something I could figure out along the way. After a while I noticed I kept bumping into classes of problems where the solutions weren't so immediately obvious. It turns out that a lot of smart people have put decades of thought into developing CS theory and software engineering best practices, and it's nice to be able to stand on their shoulders instead of figuring it all out yourself. I finally took some time to step back and study CS fundamentals in more depth.

To get specific, I'd say that in addition to the standard EE must-have exposure to C, asm, Verilog/VHDL, and Matlab, I'd recommend every EE learn at least one good general purpose programming language that has a batteries-included standard library and ecosystem around it. Python is nice because it's very expressive and has a wide range of libraries for anything you might want to do, from data analysis and machine learning down to serial port interfacing. A number of other languages could fit the bill too. I was disappointed to learn that EE's at my alma mater can now graduate knowing only Matlab. There's nothing wrong with Matlab when it's used within its domain, but it's not ideal for expressing certain programming paradigms. I think you want a language like Python as the Swiss Army Knife you can always fall back on.

I also think it's helpful to take a class (or do some self-study) on algorithms and data structures, compilers, computer architecture, programming languages (including object-oriented, ML-derived, and Lisp-derived languages), and an intro to machine learning. Even if you aren't working with these concepts day-to-day, it helps to know the bounds of what is possible with current techniques instead of simply assuming "we can do that in software."

SG: Looking back, is there anything you would do differently?

RS: Hmm, good question. It’s easy to get caught up in small tasks that come up throughout the day. There's a quote inspired by a speech made by President Eisenhower that fits here: "What is important is seldom urgent, and what is urgent is seldom important." So the thing I take away from that is that if you want to do work that has an impact you need to be mindful about how every task fits into the big picture.

SG: Thanks Russell for sharing all this info!

We hope that these words inspire the next generation of electrical engineers. If you have any comments or questions, please drop them below or say hi in our Slack chat room!