Are there any systematic differences between software developers (sw engineers, architect, whatever job title) with an electronics or other engineering background, compared to those who entered the profession through computer science?

By electronics background, I mean an EE degree, or a self-taught electronics tinkerer, other types of engineers and experimental physicists.

I'm wondering if coming into the software-making professions from a strong knowledge of flip flops, tristate buffers, clock edge rise times and so forth, usually leads to a distinct approach to problems, mindsets, or superior skills at certain specialties and lack of skills at others, when compared to the computer science types who are full of concepts like abstract data types, object orientation, database normalization, who speak of "closures" in programming languages - things that make little sense to the soldering iron crowd until they learn enough programming.

The real world, I'm sure, offers a wild range of individual exceptions, but for the most part, can you say there are overall differences? Would these have hiring implications e.g. (to make up something) "never hire an electron wrangler to do database design"? Could knowing about any differences help job seekers find something appropriate more effectively? Or provide enlightenment or some practical advice for those who find themselves misfits in a particular job role?

(Btw, I've never taken any computer science classes; my impression of exactly what they cover is fuzzy. I'm an electronics/physics/art type, myself.)


Having an EE minor and a CS major, I've worked with both groups academically. I've never held a job where I designed EE style products, but I've consumed a lot of them doing work for companies with things like PLC, and so having been able to understand (from an educational background) what as occurring was nice. So I can't say that I know 100% about workplace behavior and characteristics, but I can describe the academic differences between the two to some extent.

EE folks tend to focus on the details, and they tend to know the exact implementation. If it's not 100% mappable, they don't like it. EE folks will optimize down to remove unnecessary details if they can.

SE folks tend to like layers and compartmentalization of logic. SE folks don't mind bloated projects. SE folks tend to be very math oriented. They tend to think in terms of equations and how to solve problems from a pattern concept. Joins are more intuitive to this group, like database work. The further SE you go the more you tend to see people who are fluent with things like Functional Programming. That's just not safe ground for an EE person.

Both folks know about stuff like Karnaugh maps so there's plenty of overlap in those areas. Logic reduction, that sort of thing.

Ok, so that's my subjective answer. Hope it helps.

  • This answer gives me insights to my current project. I need to switch careers! – DarenW Nov 2 '10 at 4:44
  • 1
    I almost 100% agree with you, except the part about functional programming. For instance, I believe pure ladder logic is almost 100% declarative syntax. Function block diagram is also popular with EE's, which is also, obviously, functional. – Scott Whitlock Nov 2 '10 at 16:23
  • @Scott W. ~ 2 thoughts ... ;) it's a subjective answer, I'm allowed to be wrong ... in reference to functional logic I mean like this lisp code ((lambda (arg) (+ arg 1)) 5) ... they would indeed use something "similar" but would the logic be the same to an EE? Not in my personal experience. Granted, I don't know that many professional chip designing EEs, most of the ones I know are more service personnel. And the ladder logic they key into a computer terminal looks like a literal ladder on their screen. Go figure. – jcolebrand Nov 2 '10 at 17:19
  • 1
    I think you're talking about functional constructs like lambdas, etc., and I'm thinking about functional concepts like immutability and declarative syntax. I agree that stuff like monads and the like are pretty abstract. I don't think EEs would normally run into stuff like that. – Scott Whitlock Nov 2 '10 at 23:20
  • I think that EEs run into monads more often than SE folks. Haskell even has a monad extension that allows monads to be modeled as I/O blocks, the bread and butter of DSP engineers. – Aditya Nov 27 '11 at 23:41

If I had to generalize, here's what my experience has been:

  • Engineers (or just EE's) tend to do better in the "perfection of the small". Given a small programming task, they think very long and hard about all the edge cases, and are more likely to end up building a piece of software that's very robust. It's usually driven from a top-down design-it-all-up-front approach, because that's what they're used to in hardware. It usually involves the use of state machines, because they're used to designing them for hardware, and it fits with the "big design" approach. On the flip side, they aren't thinking as much about scalability or maintainability.

  • Your traditional developers are better at managing large complexity, mostly because the training pushes breaking down problems into smaller more manageable bits. They're taught to avoid the big design, and just separate the concerns, write tests, and make the tests pass. Typically there are lots of little missed edge cases, just due to complexity & time, but those eventually get covered off. Developers tend to take advantage of the fact that it's just software and it should be (or is) easy to change. When EE's work with hardware, they don't have this advantage, and I think it takes time to make the transition.

As I said, that's my generalized experience. It's not true in every case.

  • Nice answer, with the contrast between the two. Now to see how many others agree that this is correct or comes close, by upvoting. – DarenW Nov 1 '10 at 2:27

In my experience - EE types seem to design linear programs and not to incorporate the abstraction layers CS types seem to be comfortable with.

No comment about the quality differences or lack thereof.


I doubt you'd see much difference in the usual sort of business or web apps that most people end up working on, once both have a few years of experience under their belts. All the things you list as confusing to the "soldering iron crowd" are normal programming skills. In essence you're answering your own question - someone without a programming background can learn programming, but until they do they're not a programmer. Someone with a logical and analytical mind will find it much easier to learn to program well than someone who does not - that would be the only advantage I can think for a self-taught electronics tinkerer.

Computer Science (as opposed to Computer Engineering) is predominently maths, as (at the higher levels) are the various other sciences such as physics - but it's a very different sort of maths. If you've done a different science then you will also have done maths and so should find it possible to get up to speed unlike someone who has no maths background. Of course, very few programmers ever really need to know about set theory, big-O, or whatever else - certainly not at a high level anyway.

  • Interesting answer. I may have downplayed the programming skill of electronics people - experienced ones can be anywhere on the scale from dummy to rock star. Would you say it's true that EEs can learn programming to a professionally competent level, more easily than a pure software person can pick up electronics? – DarenW Nov 1 '10 at 2:23

I started out with a BSEE, went to work designing logic circuits for a large telephone R&D lab, and (this was some 40 years ago) realized most of what I was building could eventually be done with a computer program. So I went back and got an MSCS degree.

I have always been interested in computer architecture, and what happens at the hardware level. Most of my career has been spent designing embedded microcontroller systems, where I try to find the best match between what is done in hardware and what is done in firmware. However, I've done quite a bit of web programming, and some database design.

Without my background in CS, I think I would have a lot more trouble grasping more abstract concepts. Besides many different assembler languages, I have used C, C++, C#, Pascal, Delphi, Perl, PHP, and some Lisp. I am currently trying to learn Ruby and Python. OO design I am pretty comfortable with. Functional programming I am not (yet).

Same for databases. I understand normalization. I have trouble with some of the more esoteric JOINs and avoid them. I'm not really comfortable with something unless I understand what is going on under the hood.

I want to be able to "see" how the computer would run the program in my head.

  • 1
    "I'm not really comfortable with something unless I understand what is going on under the hood." - that is the mark of responsible engineering. +1 to you sir. – luis.espinal Mar 21 '11 at 13:27

Not the answer you're looking for? Browse other questions tagged or ask your own question.