The reason I'm asking is that I'm a pure software engineer, and I sometimes wonder if I'd have been happier on the hardware side. But I've gotten some reports that these days the work isn't actually all that different.
After 1.25 years, I realized that I was spending all my life in a lab with no windows, to the smell of toxic soldering fumes, fighting against extremely annoying software (altium & other proprietary overpriced pieces of technical debt). Also, I realized whatever I created needed a lot of work for an unsatisfying outcome (A sound amplifier is less satisfying than some webgl stuff that moves [but it requires a lot more work]). The nice feeling of being powerful when writing software & the instant compiler/interpreter feedback is what I missed the most.
At least, when you are a software engineer, you have more odds of finding a nice workplace, with windows and software you can choose.
The part I miss from electrical engineering is the physics part (But we were only skimming this part anyway).
Finally, circuits are a thousand times less satisfying to me than code. I've seen people for whom it was the opposite. They did not get programming at all, but they were designing circuits at the speed of light with an intuition that I did not have.
Also, solder fumes aren't toxic!
If you think Orcad is good, you've never used Eagle.
[0]https://www.youtube.com/playlist?list=PLy2022BX6Eso532xqrUxD...
Edit: ...is that Chris Gammell? How did I not know this was a thing he made?
So which one is better between Altium and Eagle?
For reference Altium is still around $7500 plus $1500 per year for updates and Eagle without board restrictions is $1600.
I really just find it hard to do hobby projects in Eagle because I'm so used to Orcad's workflow by now. All the shortcuts are different. :(
That being said, you should wash your hands after dealing with leaded solder and consider some disposable gloves if you're going to be doing a long session.
The only thing in lead solder fumes is the rosin, which is benign except being an asthma sensitizer, so you should probably take precautions if you have asthma. Other then that it's basically harmless.
If the solder has lead the fumes are toxic. If the solder has a rosin flux the fumes are toxic, and the operator needs ventilation to keep exposure below recommended levels.
It's a bad idea to be breathing in the fumes, but obviously this depends on how much you're breathing. At most risk are people who solder all day everyday.
I encourage you to support this statement. Lead doesn't vaporize at anywhere close to soldering temperatures, and from what I have read there is no lead component to soldering fumes and consequently no exposure through respiration.
Rosin and particularly No-Clean fluxes do pose a respiratory hazard, so fume extraction is a good idea regardless.
¹) I don't expect to find a real EE job without a degree, more like a generalist who also has clue about electronics.
Computer Engineering at the intersection of EE and CS is all of both or nothing really, depending on your point of view. A respected man once said, every idiot can count to one ;) But then again, digital and analog with enough precision seem to be the same thing from different perspectives. So, I'm not sure whether it makes sense to look for differences between those.
While I started out doing software and love it, for me electronics is just a whole next-level of awesomeness... Altium is actually in many ways a really good piece of software (yes, there are also some annoyances, but they are minor compared to any other electrical design software). It's true that it's stupid expensive but given the other options it is worth the price to us at least.
But I get to work on really cool stuff (mostly satellite tracking antenna systems), and our labs are on the side of our building with a full-height window down the entire length, so your milage may vary.
I actually don't get the solder fumes either, because we have techs who are much better at reworking tiny surface mount parts than engineers tend to be!
I've been doing software dev for a little over 10 years now and recently I have been leaning more towards electrical engineering. Partly because I loved electronics before I knew how to code, but the main reason is that I have yet to find a software company that can make thought out decisions on languages, frameworks, listen to their devs, etc. Most companies I've worked at usually just pick the most common stuff and go with it because they either don't care or aren't actually the right fit for their position, only to realize waay too late that the software wasn't the best choice. And usually us devs get the blame because we are the magic people that can "make anything work".
The other part to this is that we always voice our concerns early on, but they fall on deaf ears because it is too much of a hassle for our decision makers to make more decisions, weigh pros and cons, etc. It gets really frustrating knowing a project is going to have issues down the road but nobody listens until it happens. If you were to look back on our slack chats at the beginning of most projects you would see many devs predicting the issues with almost perfect accuracy.
Where as, (imo without real world experience mind you), EE is fairly straight forward because there are only schematics and circuits and tangible progress. No hours long meetings on which of the hundreds of frameworks will guarantee success, PMs that don't really know much about proper project management, owners that think of themselves as the next google even though us dev grunts know that isn't true, etc.
I'm probably letting my frustrations guide this reply a little too much, but what i think im trying to say is that the grass always seems to be greener on the other side even if it's not.
I made analog designs, digital designs, power supply designs... Then I started feeling more and more that I designed less and spent more time learning what the chip designers did, as chips incorporated more and more functions that once I did by myself.
So at the end I switched to FPGA design and today my typical workday is coding, debugging, simulating... 95% of the time on my computer. A good friend of mine coined a good phrase: FPGA engineers are SW engineers that disguise themselves as HW engineers. A good joke. But every joke has a bit of truth in it.
I started my career as a software developer, but got bored by web development that seems to make up 90% of the industry, so I started to study EE because I really enjoy playing prototyping fun projects. I just ordered a PCB for one of my projects.
But when I read your, and other comments, it seems that just as the things I enjoy about programming are not what a typical job is about, the things I enjoy about EE are not what typical EE jobs are about. I'm not sure where that leaves me...
You cannot really receive answers for your questions, because most of these things are subjective. You have to make your own way and make your own experience. Experience, after all, is the comb you get when you have no more hair ^^
A design engineer tends to have a batch-oriented life. Typical workflow might be like CAD -> sim -> layout -> debug -> small scale production -> testing -> handoff to production. Of course all of this is as a member of a larger team. Somewhere in there you'll either work on software or firmware or both. I spend about half my time in the lab or field, the rest in my office or meetings.
One bad side of EE is that you can break stuff much differently from software. When the magic smoke comes out, there's no 'svn revert' - you have to figure out what you broke and fix it before you can move on. This always happens when you're in a rush and causes plenty of unplanned late nights. And for additional fun, it's not uncommon for problems to crop up where you just have no way to get at the underlying issue. Datasheets don't have all the info you need, and you can't always figure it out. Sometimes you hit a wall and just have to start over. I used an Atmel processor which had a weird bug in its I2C slave module which prevented it from working properly. Best solution ended up being to go to a different processor, which was incredibly painful.
It's really awesome to be able to hold on to a thing that you built and make it go. Seeing your thing go out in the field and work is very rewarding.
Generally, "embedded systems" implies some programming as well, but I do little to none of that. I think I'm the exception rather than the rule in that sense.
If you wanna get simplistic about it, I spend half my time playing "connect the dots" in overpriced software, and the other half arguing with people about where I decided to put the lines.
On the one hand, there's a lot more standardization in the components I string together to make a working system. On the other hand, it can be just as hard to track down the source of a problem. You happen to have caught me at a point where I'm stuck trying to figure out the proper answer to a mysterious boot issue, and let me tell you what - it's about as frustrating as frustrating gets. You have to push yourself to think hard about what you haven't done, even when you've done everything by the book. ("The book" in this context is documentation, design guides, processor reference manuals - things that tell you what to do to get your system working.)
Point I'm trying to illustrate - don't think that hardware is any easier than software. It's very, very gratifying to see something real, that you can hold in your hands, work. Doubly so when people actually use your stuff and tell you how much they love it. (Yay, consumer electronics!)
> there's a lot more standardization in the components I string together
Embedded Systems is just one discipline in EE. How many people design something like an lm317 deployed on embedded devices? EE tries to teach that, too, until it's all to complex not to specialize on one branch. Another discipline I was offered to specialize in was Motor Appliances and Power Amplifiers. Those don't have much to do with CS, except maybe for digital control circuits.
I do a lot of POL planning for purposes of thermal management, so yeah. I'm definitely not that specialized.
Well, that's also a better example for my point. the sppeds they achieve require some research
This is why I quit my software job and started to study EE. I'm currently waiting to get my PCB back from Oshpark. It does worry me a bit that some people here describe their EE job as more boring and frustrating than software development.
The hardware job seemed more like "real" engineering -- it was more rigorous, there was less room for error or experimenting. But, I got bored with it eventually -- it was the same thing, just a bigger chip, more people working on it, and a longer design cycle from one thing to the next. Also, it seemed like upward mobility was hard -- I didn't want to be a middle manager anyway, and it felt hard to have a large influence in a company with thousands of engineers. In the end, I felt I didn't want to die at that desk, so I switched into working for internet startups.
The software end of things has felt more creative and has definitely been more fun. It's more laid-back, people are generally a little more interesting and well-rounded, and you typically work at a place 2-4 years and then move onto something new -- which I like. You're generally working in smaller teams and you get to work on a variety of different pieces of the system if that's what you like to do.
All in all, they were both rewarding experiences with good compensation -- the software thing might end up being more lucrative in the end and I just sorta have more fun doing it. At the time I made the switch, I took a pretty large pay cut going from a mid-level hardware engineer to a junior software engineer, but it's one of the best decisions I ever made looking back.
- Work on Schematics and layout for various different boards (usually only get time for one each day). - Go to meetings with multiple different engineering teams to make sure that cross-functional requirements are being met (usually the software and mechanical guys making demands of what they need which just means what they want to make their life easier by making the EE's suffer). - troubleshoot issues on the already built hardware and add the fixes to upcoming revisions. - Argue with purchasing department about the reason I need to get a certain type of testing equipment.
-A lot of component research and validation and meetings with vendors to determine if that components is right one.
and this is just the pure hardware tasks. There is always potential to have to deal with firmware issues as well.
I may spent half my day at my desk, at least an hour or two in a lab and the rest is for meetings.
I do think, though, that it's possible for an organization to structure it's meetings so that they're a useful and productive part of the job, and not a thing to be dreaded in the least.
I've seen this done with varying degrees of success/failure.
I feel like I go to a lot of meetings with a lot of people who are just there to be "in the loop" rather than actually contributing to the topic at hand.
If there were a Borg-a-Tron 5000 that we could all stick our heads in to let dev and QA and PM and mgt know what the rest of the team was thinking, I'd use it. But only during work hours.
Why hasn't someone made good software for EEs to use? And if the have, why do no EEs use it?
1) Barrier to entry is way too high compared to other software niches. Good luck designing a cycle-accurate CPU simulator, or creating a reliable and robust analog circuit simulator that competes with offerings from EDA giants like Cadence and Synopsys.
2) The adoption process. I learn tool X in school, I start a company that uses tool X, I teach my hires tool X, etc. Once tool X becomes a central part of the design process, it's almost impossible to get rid of it.
That's my read on it, anyway. Anyone who figures out a way to make EE CAD software better and easier to use stands to do well for themselves.
The best stuff is usually pretty expensive. Although Altium is making lower cost and free versions available with their CircuitMaker series.
But as others have said, EE jobs run the gamut. Depending on where you go to school and what emphasis you choose, you could be doing digital IC design (which contains multitudes within itself, e.g. high-level architecture, clock trees, verification, integration), analog IC design, RFIC design, board-level RF, chip package design, embedded systems, power electronics, antennas, FPGA, HDL/IP cores, test engineering, digital signal processing, control theory, communications systems -- the list goes on and on.
If you want to work with some hardware, or on a test bench with lab equipment, you can always move over to embedded, as there are many jobs available; some even say it's less competitive.
My experience has been that the embedded jobs are controlled by companies that are very picky about experience. I am an EE that has been out of the game (professionally) for four years. It's like pulling teeth to get anybody outside the Valley to talk to me about an embedded job.
And when that is not the case, when hardware is going to be built, the decisions about circuitry and methods are increasingly determined in advance with software.
Here's an example -- in my career as an electrical engineer (30 years ago) I designed any number of phase locked loops in circuitry. Now I design them with a keyboard and a computer monitor, [using methods like this](http://arachnoid.com/phase_locked_loop/). The new PLLs work much, much better than the hardware-based ones, as well as requiring far less guesswork and effort.
So my advice is not to abandon a software-based approach, it increases your employability compared to someone who only knows hardware.
The creator of that video was answering questions on reddit, and amazingly the whole design and build process took less than a week.
https://www.reddit.com/r/ArtisanVideos/comments/50tqgx/the_d...
Basically, hardware is way /way/ harder then software. Imagine software where each compile took multiple weeks, and cost lots of money (hundreds of dollars for the simplest of projects, to tens or even hundreds of thousands for really complex things). Changing the layout or design almost always involves a complete board respin.
There is no easy getting started (maybe arduino stuff, but there is SO MUCH horrible misinformation in the arduino communities), because the minimum functional system is a complete system. You basically have to get everything right the first time in hardware, or it won't work. The learning curve is more of a learning wall.
To give one example, let's say you want to start out by making guitar pedals. There's a healthy market for boutique guitar pedals, plenty of existing designs available online that you can modify when starting out, and when you're ready to start making designs from scratch you're looking at stuff you can understand with entry level electronics knowledge. Furthermore, there's room to grow as your knowledge improves (can get into DSPs, for example).
From reviewing these posts, it seems like EE spend most of their day frustrated trying to get the device to simply boot or do the simple thing. If there's a tool for beginners that snaps together and avoids these headaches, that seems valuable in itself, almost anti-HORROR.
1. The HORRIBLE code quality in the entire arduino codebase.
2. The prevalence of straight up factual errors everywhere in their stuff.
3. Their shitty, SHITTY schematics.
To be clear, getting a AVR to run a "flash the LED" program is trivial. There is really not much /to/ an arduino (it's an overglorified atmel eval board).
When you refer to `trying to get the device to simply boot or do the simple thing`, what you're normally talking about is trying to get a fully integrated complicated system to power up and function to the point that it can then be debugged further. This is a COMPLETELY different ball-of-wax, and requires a much more broad toolset, because you have to be able to diagnose why it's not working. Sure, with arduino things, you can plug the bits together, and it'll MAYBE work (assuming non-buggy libraries, which is very much not usually true). OTOH, if it doesn't work, ¯\_(ツ)_/¯. You're going to need a logic analyser, or an oscilloscope (or both!) to figure out why. I can pretty much guarantee the person who initially wrote the library for each of your "snap together" module components did have to go though all that.
Basically, arduino stuff is the PHP-equivalent of the hardware world. The general quality is low, there is little push for improvement, and everyone is sticking buggy crap on the internet.
For example, the "Arduino Mega" (call it a goddamn ATmega2560, dammit) has multiple hardware serial ports (4 of them). For a long time (possibly until today), even if you weren't using the ports, it allocated two 64 or 32 byte buffers for each port statically. This is on a platform with 8KB of RAM total.
Would it be trivial to fix this? Yep. Did they? Not the last time I checked.
These are also the same people who decided malloc() on a platform with 2 KB of ram was a good idea (it's not).
Think of it like physics problem sets though. You don't get to Physics 503 by just reading the first three text books, you have to actually do the problem sets and struggle with them. In our first problem here, assume there is no friction, even though any experimental physicists will tell you that's crazy, that never happens. Once you've mastered the exercises, then you criticize their clunkiness and move into a framework with more realistic assumptions.
And for me, the refusal to fix sub-optimal design is pretty appreciated as it doesn't subtly break some aspect of already written books, tutorials, shields, etc. Beginners will often look to copy very literally an already known solution, which may be on someone's blog from 2011. Little changes, which happen often with RasPi, result in hundreds of comments like 'This doesn't work, please help!'
When I joined the company, the very first role I was put in was on the core bringup team for a complex ASIC -- that is to say, the team responsible for screening chips, and working on issues that affect all of the individual functional blocks. I joined about a month or two before silicon was to come back. So, I spent the first six or eight months or so at the company in the lab; the first month was spent familiarizing myself with the tools and boards that we'd be using, and then once silicon came back, I spent a bunch of long nights and weekends in the lab getting chips to various teams, and, in general, solving whatever system-wide problems showed up. Bringup was a lot of work but it was also a really good view into "how the sausage was made", so to speak.
After bringup, I moved to an IP team [1], where my title was "ASIC Engineer". At the phase in the project that we were in, most of the RTL [2] had already been written, and owners for each sub-block had already been assigned. So my job was to do a bunch of the "checklist" items for netlist quality. For instance, I spent a while reviewing test coverage, and waiving coverage for things that couldn't possibly ever be reached. Or I reviewed tool output that did "clock domain crossing verification" -- basically, the tool pattern-matched on various chunks of code to make sure that they were safe. And yes, I spent some time staring at waveforms, trying to debug our testbench, or any kinds of such things.
I spent a while on another couple bringups, which I volunteered for this time. I enjoyed them, and then gave myself some time off for each to compensate myself for my nights and weekends.
At some point, someone decided that I was a better architect than engineer, which is probably for the better, because I was very slow at checklist items. So at some point I switched to an architect role, which meant that I was responsible for doing the definitions of sub-units, rather than implementing the hardware for them or implementing the testbenches for them. And, in general, the whole specification process is part of the architecture team's job. So, one day, when there was an output quality problem with our block -- it worked as specified, but given that it did some image processing, the image quality had some defect, so the specification was wrong -- I was tasked with spending a few weeks to reproduce it on hardware, find register settings that made it better or worse, and finally, understand what the defect was in the specification, and how to avoid it in the future.
Another task I had as an architect was to do the definition for a sub-unit from the ground up. This was a year or two of work. My primary output, interestingly, was not code, but instead a 100-or-so page Word document that specified how the block was to work, and what registers should program it; the consumers of that document would be the hardware team that implemented it, and the software team that would build the software. And, subsequently, I was tasked with implementing a model of that block in C, which could be checked against the RTL that the design team wrote. Near the end of that project, I wrote validation tests for it, and yes, I then spent some time staring at waveforms helping the design team to understand why their RTL implementation diverged from my C model. (They were, often, right. I am very lucky to work with an extremely skilled RTL team.)
These days, I'm doing more algorithmic research, trying to figure out what should be next for the block that I'm working on. In parallel, I sometimes get on phone calls with, for instance, image sensor vendors, understanding on an electrical level what's going on inside of their next sensors, and how they will be transmitting data back to our processor. So even though I work in the digital domain a lot of the time, having a firm grounding in 'is it possible to wire this to this' has gone a long way to help out, and being handy with a soldering iron has made my life a lot better on more than one occasion.
My experience spans some gamut, but not all of it. I don't work on place-and-route, and I don't work on board design (at work, at least). There are a lot of things that electrical engineers do :-)
Hope this helps. (I can answer questions, I suppose, if you like.)
[1] For some reason, the semiconductor industry calls functional blocks IPs -- yes, as in 'intellectual property'. This particular IP was not something that we licensed to anyone, or that we licensed from anyone; the only 'customer' of this IP was our own chip team.
[2] Again, another acronym whose expansion ("Register Transfer Level") is not super descriptive. Essentially, source code. Usually in Verilog, or an even higher level language. EEs seem to love Perl and Tcl, so most places I've worked have had Perl or Tcl preprocessors before their Verilog. Ugh.
ASIC work is fascinating.
> Working as shift engineer in power plant
I'd say my EEs spend 50% in design and 50% in debugging customer problems when a board fails in manufacturing or fails in the field.
The answers can be easy (say, a resistor is out of tolerance or the wrong oscillator was placed on the board), or they can be really tough (a transient is killing a FET and locking things up).
I spend 25% of the time talking about requirements to other engineers, 50% comparing components to use with datasheets, 12% in Altium Designer and 12% buying components and PCBs.
Huge pain #1: the unbelievably slow process of manufacturing PCBs. Imagine that you were back in the old days of computing where you had to use punch cards with machine code and you had to give your stack of punch cards (your "program”) to the punch card operator. He would run it overnight and you would get your results the next day. If your program failed, then you have to meticulously comb through it and debug in your head. This is modern-day PCBs. Holes in a board that take forever to make. Then you have to pay $80 shipping to get them next day or you can pay your engineers to sit around doing nothing. And the PCB might not even work. Learning feedback loop is very slow.
If you want to do anything remotely interesting like via-in-pad or four-layer boards, first you have to wait at least 24 hours for a custom quote. Half of PCB vendors don’t just give you the formula to make your own quote. Then you have to pay either $1000 and 2 days or $200 and 2 weeks to have 5 copies of your design.
Huge pain #2: reinventing the wheel. When I open a datasheet, I have to read about the device. The pins, the maximum ratings, the application note “gotchas” like “don’t leave this pin floating or else the chip will be unpredictable!” Then I have to make the schematic symbol and footprint by hand. That means manually entering IPC package dimensions into Altium like a braindead zombie. Every package is slightly different. I cannot tell you how many Texas Instruments DC-DC converters I have hooked up. I have no idea why device manufacturers don't just hire someone full-time to make open-source 2D and 3D footprints for the top six CAD tools. SnapEDA and Altium Vault are trying to do this, but the footprints are flawed and they are outright missing a lot of parts. I cannot tolerate mistakes when each board costs hundreds of dollars. The device manufacturers already make footprints to test their parts. Why don’t they share them??
Huge pain #3: High barrier to entry. Very expensive software. In software engineering, professional tools like git, Visual Studio, Eclipse are all free. You can pull code at home from Git and start contributing immediately. The only barrier to entry is the time you need to understand the existing codebase. Even in firmware you can download Code Composer Studio or PSoC Creator for free.
In board design, you need to pay $300 for EAGLE or $5000+500/year for Altium if you’re serious. Sometimes OrCAD goes on sale for $300. Lets say you want to simulate Bitcoin mining ICs frying themselves in their own heat. Or maybe you want to know the radiation pattern of your antenna. You can pay another four digit price tag for simulation software like CST or just copy a previous design like a zombie. Upverter is trying to solve the upfront cost problem with their $125/month SaaS subscription pricing, but I tried their editor 3 months ago and it was 15 FPS with the example board. Not cool. KiCAD is an open source alternative to Altium but as far as I know it is nowhere near comparable.
Huge pain #4: ordering components and PCBs. In my last project I had to order components from China. Ordering from China is not very easy with the language barrier, bad spec sheets, time difference. Alibaba is the place to go for ordering from China, but all the prices are “Contact us”, which means you have to give all your information blah blah blah until you get an email with the price and then pay with wire transfer. Sometimes you get lucky and you can find what you want on AliExpress and pay with credit card.
But the tradeoff to all of this is that if I do it correctly, I can hold something in my hand and give the software engineers a new API to play with. The APIs all stem from the hardware. The work is often more fundamental with equations and physics rather than purposeless corner cases I had to consider when I was in programming. And hardware often has the chance to be featured on the box of a product rather than software which is all just assumed to work. It feels more meaningful.
Software engineers usually have to take quite a few courses in calculus, linear algebra, and stats. But that stuff very rarely comes up in practice, at least in most subfields.
I know people that design electric motors, microphones for hearing aids, overhead electrification for railways, railway signalling systems and power distribution in very large buildings.
However, I don't know what a typical day would be for any of them.
EEs also study computer architecture and OS internals in detail, depending on one's emphasis.
On the other hand to do it properly you have throw out the 'reciprocity' of sending and receiving antennas. They are not really the same at all.