Why do a lot of electronics engineers end up coding?

[bd139]

What’s wrong with lisp?

[phil from seattle]

Sheesh, all this us vs them talk with amazingly broad brush strokes. For every "clueless SW guy blowing up a transistor" story there is one about some "EE guy making bone headed coding errors". The reality is far more nuanced than that. Any SW based project that needs more than one programmer will fail without some level of discipline. The wild-man programmer that says "ship it now, fix it later" is a more of a myth than not. And, every good team has at least one adult making sure that doesn't happen.

Like it or not (and I suspect a lot of not out there), software is here to stay. It's at the heart of just about everything we build. An EE that doesn't have at least an understanding of programming is at a very distinct disadvantage in the marketplace.

[bd139]

Err yes that’s me. There are 79 people on MY team. And we ship fast and often. And we don’t blow up transistors. The guy who blew up the transistors probably works in mcdonalds now. We only have people who don’t blow up transistors. And some people who don’t blow up engines and some people who don’t blow up calculators too. I think there are more hardware engineers on our software team than software engineers. And we just write software. That is the status quo at the moment. In the 20 odd years I’ve been writing software, bar some web shops, that’s how we all roll. I’d argue the exception is the other way round.

It’s a mish mash. You have to be good at both. Why do you think MIT broadly glues both disciplines into one subject now.

[Howardlong]

What’s wrong with lisp?

Another one of those fad languages, ISTR the AI crowd of the mid 80s were into it. Like Prolog. Yes, AI was quite the thing to be into in academia in the mid 80s. Just like flared trousers, these things keep coming back to haunt us!

[engineerguy]

Things that require knowledge workers to do non tangible work which is poorly understood by other humans is a recipe for making a metric shit ton of cash. Also there are so many mediocre and poor programmers that it's very quick to rise to the mega-cash jobs if, to use an analogy, you know not to put your dick in a food blender.

But hardware/electronics engineers are just as valuable knowledge workers, I mean they possess the sort of knowledge that, as another forum member put it, takes more time to understand and develop. The fact that there’s more SE than HE is a testament to that...but I think this is where the point about software requiring constant renewal comes in, which is where the higher pay comes from.

contracted myself out as ultra-pimped software engineer. Turned out that everyone else on the market was so dire it wasn't that difficult looking like a shiny golden nugget and taking relatively more wonga for the privilege. This has worked well for a long time.

So did you transition from an electronics engineer to software? Is that your everyday role?

Thanks for the replies everyone, it’s given me a lot of perspective and understanding. I’d like to quote more people but this would become too long of a post. I will continue to develop my software/programming skills since it seems like it’s a definite requirement. But my concern still remains: that electronics/hardware engineers are slowly “dying off” and I’ll eventually have to succumb to programming as a job.

[tggzzz]

What’s wrong with lisp?

Another one of those fad languages, ISTR the AI crowd of the mid 80s were into it. Like Prolog. Yes, AI was quite the thing to be into in academia in the mid 80s. Just like flared trousers, these things keep coming back to haunt us!

LISP was one of the first languages, contemporary with COBOL and FORTRAN, and predating Algol-60.

There is a reason it keeps coming back. There's an old aphorism "Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp."
https://en.m.wikipedia.org/wiki/Greenspun%27s_tenth_rule

More cynical people will simply remember George Santayana's famous quip.

[bd139]

Indeed. LISP is hardly a fad language. It's a bit meta and requires a different line of thought. SBCL craps on a lot of environments.

Also, wonderful for data representation. Don't have to parse s-expressions!

I suggest people sit down with some red bull, acid tabs and a copy of Structure and Interpretation of Computer Programs.

My domain and company name is a lisp primitive

[james_s]

The wild-man programmer that says "ship it now, fix it later" is a more of a myth than not. And, every good team has at least one adult making sure that doesn't happen.

I wish I could agree, but that attitude seems to be a cancer that is spreading throughout the industry, at least in software. Everything is becoming a perpetual beta, with frequent updates touted as a feature rather than being honest that it is mostly stuff that should have been done/fixed before the product ever shipped.

[tggzzz]

Indeed. LISP is hardly a fad language. It's a bit meta and requires a different line of thought. SBCL craps on a lot of environments.

Also, wonderful for data representation. Don't have to parse s-expressions!

I've always thought of XML as being a triumphant reinvention of LISP, albeit without all the interesting powerful bits.

[ejeffrey]

The rule of thumb to design a new device is:
- 1 analog electronic engineer
- 10 digital electronic engineers
- 100 software engineers

This.  Most hardware doesn't do much interesting with software -- not just firmware, but often drivers, application software, network software, database software, mobile software, the list goes on.  And the higher levels tend to be more complex even if it seems simpler due to higher level languages and library abstractions.  Application software simply has more ways to go wrong.  It interacts with more unpredictable things including the most unpredictable component: the user.  So it takes more development effort to get something reliable that actually does what the user wants.  A lot of that development is best done by someone who understands the hardware behind it all.

In fact, its not just hardware engineers.  Almost every technical job is going this way to some extent.  If you want to do X, you are going to need to tell a computer how to X.  If nobody has done exactly your X before, that is going to involve something similar to coding.

[Berni]

Well it doesn't always take a hardware engineer to do well with low level code and drivers.

The guy here that is super good with coding low level things actually went to school to be a IT technician but is now a all round bad ass programmer here. And the guy who keeps all the IT running here is actually a programmer (But really good at high level coding too)

Oh and yes "agile hardware". The prototype is already on my table, all packed tight into the small case and then in comes "Can we add WiFi to this? The competitors product is supposedly gonna have WiFi so we need on ours too"

[filssavi]

Don’t get me wrong I never (really used lisp for programming) but I hear it has a pretty powerful meta programming system and Evan be the best language around when that is needed, so I’m not in the fad camp...

BUT

In that eda suite lisp is used as a scripting language, and that is probably the worst choice ever... they could have chosen any other language designed as a scripting language,

[John Heath]

The rule of thumb to design a new device is:
- 1 analog electronic engineer
- 10 digital electronic engineers
- 100 software engineers

This.  Most hardware doesn't do much interesting with software -- not just firmware, but often drivers, application software, network software, database software, mobile software, the list goes on.  And the higher levels tend to be more complex even if it seems simpler due to higher level languages and library abstractions.  Application software simply has more ways to go wrong.  It interacts with more unpredictable things including the most unpredictable component: the user.  So it takes more development effort to get something reliable that actually does what the user wants.  A lot of that development is best done by someone who understands the hardware behind it all.

In fact, its not just hardware engineers.  Almost every technical job is going this way to some extent.  If you want to do X, you are going to need to tell a computer how to X.  If nobody has done exactly your X before, that is going to involve something similar to coding.

Best done by someone that understands the hardware. On the surface one can not disagree with this. However there are examples in real life where keeping software and hardware under different roofs had a positive effect. When Bill Gates started out with GW Basic there was a  decision to separate software from hardware. If the software said print "A" and the printer did not print "A" you phone IBM and complain to their hardware guys. The end result was it brought out excellence in both software and hardware. The hardware guys could not cheat by changing GW basic. They had to rewrite the BIAS on the mother board to make sure print "A" will print "A" period. This allowed software guys to do what they were supposed to do write code with confidence that it will be executed as written. This lead to top down software such as visual basic where dragging a browser icon over writes thousands of lines of code and 10s of thousands of lines of hex for a net browser. In this case separating hardware from software had a positive effect on both hardware and software development.

[CopperCone]

I feel that hardware engineering is way more of a trade skill if you want to be good. You need to know like thermal design, materials science, shop skills, physical understanding of the process you are controlling, radio behavior, wave theory understanding, mechanical aspects..

Not to mention heading of the industry, like knowing which direction to handle a problem with.. I.e. you can have like 20 different circuits which handle the same problem, all with their own quirks.. Then you need to imagine the device being in the field, infteracting with various things...

I mean your physically putting something somewhere. Plus you need to look at costs and ultimately make the decision of utility vs parts cost.

I think that programming is less stressful to learn, you dont really need to tango with decisions made by a supercorporation making integrated circuits.. Im sure everyone here has wished "why the fuck could they have not just made this spec a little different"...

Systems engineering is always more in the mind of a hardware engineer then a software engineer.

[paulca]

I think there is a lot of people here who just don't understand software or how it's developed.  I expect a portion believe that all software is just like they write for a MCU.

A recent comment is probably the dumbest yet.

I think that programming is less stressful to learn, you dont really need to tango with decisions made by a supercorporation making integrated circuits.. Im sure everyone here has wished "why the fuck could they have not just made this spec a little different"...

No, us software engineers don't need to deal with specs for software modules and specs for hardware at all.  Nope, we program in the ether, devoid of all interaction with other code or ICs.

Consider that you cannot write a single line of code without there being a spec behind it.  Not one single line.  Even if you get down to assembler there is still the spec of the processor.  Most "lines" of code huge amounts of dependencies, involve libraries and other components which have protocols, specs and our equivalent of "datasheets" which are API documents.  Then there is of course the OS and the users config and the vast variance of the environment, which in the hardware world doesn't really change.  Nobody suddenly changes the specs of your IC 2 years later and bricks all your products.

[Karel]

A recent comment is probably the dumbest yet.

It's ok if you just stick with arguments. No need to be arrogant.
Your opinion is just an opinion, like everybody else.

[paulca]

It's ok if you just stick with arguments. No need to be arrogant.
Your opinion is just an opinion, like everybody else.

Arrogant?  You are suggesting that software development is easy.  So I believe it deserves educated arrogance in response to an insulting and unfounded comment of ignorance.

Opinion?  I have over 30 years experience with around 16 years professional and hold the position of lead developer.  Billions of dollars have passed through my code and millions of people have used it.  I think that puts weight in my opinion.

My last paragraph is simply fact, not opinion.  If you can find evidence to deny it then I will accept your "opinion" with more weight.

[paulca]

As to the comments about juniors in code having an easier time getting up to speed.  Sure they don't blow themselves up and they get things kinda working, but its probably the same as it is in EE space.  One glance from an experienced developer and there are face palm moments.  It is likely it solves the happy path because that is all Universities teach, short snippets and happy path dev.

When you ask them things like, "What if there aren't any orders in the list?", they stare dumbly at their code and then a glimmer of "Ohhhhh... oops." spreads across their face.  So you send them away to fix the dozen or so time bombs in their code and it comes back as a jumbled pile of criss-crossed botch work attempt to address the corner cases.  They are told to rewrite it from scratch.   There are two ways to do things.  Right and again.

It takes experience to see the problem, the solution and the solution's problems then structure and design the code to flow neatly, concisely, maintainable and extendable.  It is not easy.

I think it's no harder or easier than EE, each have their easy parts and difficult parts.  Experience always pays off.  Teams need to be well balanced between juniors and seniors and we all need to fight the bean counters and trigger happy stress kitten project managers.

[tggzzz]

I think there is a lot of people here who just don't understand software or how it's developed.  I expect a portion believe that all software is just like they write for a MCU.

A recent comment is probably the dumbest yet.

I think that programming is less stressful to learn, you dont really need to tango with decisions made by a supercorporation making integrated circuits.. Im sure everyone here has wished "why the fuck could they have not just made this spec a little different"...

No, us software engineers don't need to deal with specs for software modules and specs for hardware at all.  Nope, we program in the ether, devoid of all interaction with other code or ICs.

Consider that you cannot write a single line of code without there being a spec behind it.  Not one single line.  Even if you get down to assembler there is still the spec of the processor.  Most "lines" of code huge amounts of dependencies, involve libraries and other components which have protocols, specs and our equivalent of "datasheets" which are API documents.  Then there is of course the OS and the users config and the vast variance of the environment, which in the hardware world doesn't really change.  Nobody suddenly changes the specs of your IC 2 years later and bricks all your products.

While I agree with your comment about software, your point about IC specs not changing is wide of the mark. Let's consider something simple like single transistors.

There 2N3055 has changed so many times that you can't necessarily replace failed devices with modern ones; they have a significantly highter f_t and can oscillate.

Then manufacturers simply stop manufacturing components (especially RF and low-noise components), even though they have valuable attributes and there is no replacement. That doesn't happen with software.

[paulca]

I think you missed my point.  When you ship your product how often do the specs of the IC change in the field?

[tggzzz]

I think you missed my point.  When you ship your product how often do the specs of the IC change in the field?

You can't copy hardware in the same way you copy software. The next batch isn't guaranteed to be the same. Nominally identical devices from different manufacturers can be subtly different. Ditto devices from the same manufacturer if they tweak their process.

Imagine if you wanted to sell your program in 5 years time, and you had to stockpile bits to make sure they hadn't changed in the intervening years

[paulca]

At least when you test something before it goes out the door you know it will work.  For domestic software the number of configurations is immense and the fluidity causes real issues trying to write software that remains reliable over time.  Something always upgrades and changing the playing field in a way you didn't expect.

And... 5 years down the line when you decide to re-release a new version, the latest versions of your libraries have all changed and some of the features you were using have been deprecated or changed ... or the entire component you were using has ceased to exist for modern OS's.  It would sometimes be easier to completely start again.  Consider those millions of web applications based on Adobe Flash.  Consider those websites that used Photo Bucket.

[tggzzz]

At least when you test something before it goes out the door you know it will work.  For domestic software the number of configurations is immense and the fluidity causes real issues trying to write software that remains reliable over time.  Something always upgrades and changing the playing field in a way you didn't expect..

Now tell us how Intel is changing the internal operation of its processors that are out in the field, in response spectre and meltdown.

There is vanishingly little difference between hardware and software.

[coppice]

At least when you test something before it goes out the door you know it will work.

From the context I assume you are trying to say that when you send hardware out the door you can know that it will work. Was that intended as a joke?

[paulca]

Now tell us how Intel is changing the internal operation of its processors that are out in the field, in response spectre and meltdown.

There is vanishingly little difference between hardware and software.

By changing the microcode.  Which is software.  Can you touch it?  No.  It's software. 

But... I concede your point.  However what impact do those changes have on the hardware beyond it?  Will your USB mouse stop working?  Will your Gfx card stop working? 

Now you could argue it is because the hardware interfaces are better defined and thus Intel can test they don't break said interfaces. 

There are differences, they are complex.  Software tends to exist in a much more fluid world.  The dependency scope is more diverse.  However the life cycle is much shorter.

Software that works as designed for decades requires a fixed environment, just like hardware.  But fixed environments are not what we have today.  We have a rapidly changing one.  Software that worked 5 years ago on modern computers did not work on computers 5 years before that and it might not work on computers today.