Why I quit my job as an engineer after 40 years (RANT)

[Tomorokoshi]

Pseudo-random thoughts (includes stereotypes that are 3dB over the top. Put on -3dB glasses to read the realistic version):

1. There is a tendency for managers on software or electronics-heavy projects to have Mechanical Engineering backgrounds, not Electrical or Software Engineering backgrounds. This seems to come from that there is always more electrical and software work to do, as it proceeds at O(n²), but the brackets and boxes tend to get done at O(nlog(n)). The respective engineers eventually tend towards estimating projects the same way, which is why software engineers get in trouble from management for always making estimates that are well beyond what a mechanical engineer-manager will come up with. Mechanical engineers, tending to be the ones who played sports in school, are naturally more assertive while the chess-playing software engineers slink back to their cubes to put in even more 10-hour days while the managers go golfing.

2. Compared to certain other professions, in engineering almost by definition the task is always in a state of failure, incomplete, and broken. Not everyone can work like that for days, weeks, months, years, and decades on end. Once the project in finished, it dissipates away, to come back either in another state of failure, or as the cracked foundation upon which to build the next task. Meanwhile the salesman says, "Ship It!", and takes credit for the successes of the product, while engineering gets the blame for the failures.

3. Unknown and not understood by many is the distinction between Product Development and Technology Development. Similar to the issues above, Product Development may proceed at O(nlog(n)), while Technology Development may proceed at O(n²), O(n³), O(n!), etc. Which category a particular task falls in can be very difficult to determine early on, if one is even lucky enough to have that awareness to see it. Usually such things are completely missed, so the problem instead appears in the form of slipping schedules, multiplying budgets, and cascading problems.

[b_force]

Just bumped into this topic.
I can completely relate to this whole story.
Also active in audio and boy what a mess.
Whole companies totally build on myths and lies.

Makes you wonder why we put so much effort in doing proper research.
(Floyd Toole, anyone?)

Good luck with whatever you're decide to do!

[ferdieCX]

Maybe my last "resort" is to actually write a decent engineering book about it.
In my opinion that is part of the issue. Good books are rare and/or very expensive.

Do it. 
I did it for my students after realizing, that the good books about general electronics are not any more in printing (at least not in Spanish) and that the second hand ones are scarce.
We live in a time, where very few people really cares about having a deep knowledge of anything.
To make knowledge available to the few people that really care about it, is an intellectually very rewarding task.

[nctnico]

However I accept that ways of doing things change and thus old ways die because they are obsolete.

I have no issues with things becoming obsolete. What I have issues with is people: general lack of sanity and robustness, and prevalence of short-sighted design and decisions.

For example, there are very, very few companies that create products that work anymore. Due to commercial pressures, they all create products that sell. Fitness for purpose is a tertiary consideration.

That sounds like companies which are trying to implement an agile development workflow but have not grasped all the details yet. Agile is a completely new way of developing products. In the old days you'd develop a product from A-Z based on a design specification and then find out whether the customer likes it or not. In the agile way you develop partial product and finish it based on customer requirements. The idea is no time is wasted on features the customer doesn't need, the product is on the market quicker and customers get a product which fits their needs. However it is something you'd need to wrap your head around and not everybody (including management) gets it yet.

[basinstreetdesign]

Maybe my last "resort" is to actually write a decent engineering book about it.
In my opinion that is part of the issue. Good books are rare and/or very expensive.

Do it. 
I did it for my students after realizing, that the good books about general electronics are not any more in printing (at least not in Spanish) and that the second hand ones are scarce.
We live in a time, where very few people really cares about having a deep knowledge of anything.
To make knowledge available to the few people that really care about it, is an intellectually very rewarding task.

Many times I have come home from the office to unload the cares of my job onto my wife knowing full well just what patience she needed to muster to wait out my rant of the day.  Most of the time the issues discussed originated from a lack of understanding of a fundamental point of the way engineering systems work or a realization that we could have handled a particular client-driven situation better if only we had had a little foresight and educated either the client or ourselves in an attempt to handle some risky event better.  After the heat of such a rant we would sometimes say things like “You know, somebody should write this stuff down” or “It’s too bad this stuff is not taught in school before the kids graduate to the real world”.

So I started organizing and writing thoughts about what was NOT taught in engineering school.  Stuff about getting a REAL education in a small company or diatribes on the joy of going it alone.  Also lessons learned concerning the execution of the engineering and design cycle or what and how to get it in writing.

I'm up to 160 pages and ran out of steam a while ago.  I'm sure it all still applies.  It could still stand a LOT of polishing and finishing...

But if you want to write a book on this stuff then go for it.  I would love to offer any constructive advice.
Tim

[BillB]

It sounds similar because agile development is synonymous with cutting corners.   
 
Agile development only works in very specific types of projects and when the "customer" is fully involved through the entire lifecycle and completely comprehends the project management triangle.  For example, for web development projects where most of the features are user UI and the technology is low risk.

What ends up happening, however, is that companies latch onto the latest fad that promises, somehow, to magically sidestep all the steps necessary to develop a quality product.  The customer likes it because they don't need to put in the work coming up with requirements, the developers like it because the can jump right into coding and skip the boring architecture/design/documentation phase, and management likes it because they think they're getting something for nothing.

In no other engineering discipline would someone attempt agile development; design that PCB, building, bridge, etc. by skipping requirements and design to quickly implement features! 
 

[Nominal Animal]

In the agile way you develop partial product and finish it based on customer requirements. The idea is no time is wasted on features the customer doesn't need, the product is on the market quicker and customers get a product which fits their needs.

That only works when the customers are rational and seeking solutions to a problem they have, instead of seeking how to solve a problem with a tool they have already chosen.

I've always loved the work when I'm actually allowed to solve a problem. But, typically due to management having no clue about the technology or the problem at hand, or being mislead by salesmen or "experts" who fake it but have the social skills to not get caught too often, I'm asked to implement something that does not solve the actual problem, or creates at least as many new problems than it solves. It is often as if people do not want their problems solved, but someone to implement their magic thinking.

[Tomorokoshi]

Agile: A methodology used with projects when someone comes in for a talk and gives away free copies of their book to management. It is then applied to hardware development.

[jmelson]

Worst example I heard was from a friend who designs smps.
He designed a (figures might be a bit incorrect but its just an example)
30W 95%eff smps  and an 90W 94% eff smps.
In comes the marketing guy: "Listen up I did marketing research with our customers and I now know what they really want: a smps that can be last minute configured between 30 and 90W with the same efficiency. Go build it so I can sell it!"

He could 't make the marketing guy understand :
1) that you can not get that high efficiency when the power output has such a high range
2) that this smps even with lower eff would cost more than a fixed output

The marketing guy went to his boss called him incompetent and the manager gave him a bad score that year on his annual assessment.

The right answer (yes, of course, in hindsight) would be :  OK, so you want me to design a 90 W power supply that we can sell at the 30W price.  RIGHT?

Jon

[Corporate666]

I just need to vent this, but I pulled the plug after 40 years (close of being retired).
I decided to quit my career as an engineer.

I was mainly active in analog electronics, amplifiers, (SMPS) power supplier and other audio related stuff.
Unfortunately there seems to be a trend with people who have a serious lack of (basic) knowledge and skills.
In some fields it's even so bad that you're basically talking to a wall of myths.
Myths that are being spread like a terrible incurable disease.

What's worse is that it's impossible to have a good scientific factual discussion anymore about subjects.
People are being not only totally blunt and rude, but attack you on a personal level.
At the same moment their arguments are very far from scientific facts and seriously lack on very simple high school knowledge in physics/electronics.
I guess years of research, papers, books and all don't matter anymore?
To make it worse whole companies seem to be build on this.
(not the first fight I have with a owner)

Lately I had another of these typically non-discussions about basic knowledge and that was the last straw.
It's to unfortunate, but I just simply don't enjoy it anymore at all.
It basically is like talking to rude disrespectful toddlers 
Sometimes also the reasons that I am not very active on forums anymore.

Don't know yet what I am going to do next, I have enough savings for a while, so we will just see.

I just had to vent this. Feel free to share your own similar experiences.

Honestly, I am going to put the blame on you here.

Life isn't about being factually correct, or "technically correct... the best kind of correct".  People who get hung up on being technically correct about small details are usually just covering up for some sort of insecurity or something in my experience.  The ability to compromise, salesmanship, personality, temperament, being able to understand ROI, cost/benefits and being a master of people skills and being able to light up a room and make people like you are FAR FAR more important skills than being the guy who is technically correct on minute details.

If you are having multiple fights with company owners, then it would seem you are failing on the aforementioned skills in favor of being hung up on being technically correct.   That does yourself a disservice, and if that has led you to being jobless late in your career and feeling like the whole industry is full of know-nothings who get by on bullshit and hot-air while you've jettisoned a 40-year career over your unwillingness to adapt and compromise and now find yourself with some savings and faced with having to find new work this late in the game... well, I don't think you came out ahead on this one friend.  I think you chose the wrong hill to die on by a long shot.

Hope things work out for you, seriously, but I genuinely don't think there are too many people smiling on their death beds because they died knowing they were technically correct to the end. 

[Nominal Animal]

The ability to compromise, salesmanship, personality, temperament, being able to understand ROI, cost/benefits and being a master of people skills and being able to light up a room and make people like you are FAR FAR more important skills

I'm not sure if you are being sarcastic, but I know people that genuinely think that way.

The issue I have with that, is that it is only relevant in a very limited context, where this particular moment in time and a very specific limited set of chosen values, are the only ones that matter.  Fact is, nothing beautiful, lasting, or truly new, has ever been built by people like that.

I know you don't want to, either; it's not cost-effective.

[b_force]

Honestly, I am going to put the blame on you here.

Life isn't about being factually correct, or "technically correct... the best kind of correct".  People who get hung up on being technically correct about small details are usually just covering up for some sort of insecurity or something in my experience.  The ability to compromise, salesmanship, personality, temperament, being able to understand ROI, cost/benefits and being a master of people skills and being able to light up a room and make people like you are FAR FAR more important skills than being the guy who is technically correct on minute details.

If you are having multiple fights with company owners, then it would seem you are failing on the aforementioned skills in favor of being hung up on being technically correct.   That does yourself a disservice, and if that has led you to being jobless late in your career and feeling like the whole industry is full of know-nothings who get by on bullshit and hot-air while you've jettisoned a 40-year career over your unwillingness to adapt and compromise and now find yourself with some savings and faced with having to find new work this late in the game... well, I don't think you came out ahead on this one friend.  I think you chose the wrong hill to die on by a long shot.

Hope things work out for you, seriously, but I genuinely don't think there are too many people smiling on their death beds because they died knowing they were technically correct to the end.

I don't agree at all here.
Yes to some little extend you're right.
But if after a while people just are talking BS and they simply just don't understand the fundamental basics or worse tell you that you don't know anything about it, that's were a discussion ends.
Good luck with it, I am also someone who is not gonna bother telling people things they SHOULD and MUST know.

 I even think what P.Mouse is doing is the right thing. Just let people believes in their own weird little false believes.
And yes, writing a book is indeed the right approach than.

[nctnico]

In the agile way you develop partial product and finish it based on customer requirements. The idea is no time is wasted on features the customer doesn't need, the product is on the market quicker and customers get a product which fits their needs.

That only works when the customers are rational and seeking solutions to a problem they have, instead of seeking how to solve a problem with a tool they have already chosen.

I've always loved the work when I'm actually allowed to solve a problem. But, typically due to management having no clue about the technology or the problem at hand, or being mislead by salesmen or "experts" who fake it but have the social skills to not get caught too often, I'm asked to implement something that does not solve the actual problem, or creates at least as many new problems than it solves. It is often as if people do not want their problems solved, but someone to implement their magic thinking.

Well as an engineer you should make sure you understand how what you are asked to make fits into the needs of the customer. If you just follow what the customer's procurement department and the sales people say they need then you are likely on a wild goose chase. But that has nothing to do with the development method but it has everything to do with getting clear requirements. The lead developer should talk to the technical people from the customer for that.

[andyturk]

2. Compared to certain other professions, in engineering almost by definition the task is always in a state of failure, incomplete, and broken.

Yes. Well said.

It’s better if you have a choice about which projects to get involved with and the ability to only spend time on those where your personal contribution can move the ball across the goal line. When your work matters to others, it gives you freedom to shout back if some other nitwit’s idea is going to lose the game for the whole team.

[Nominal Animal]

Well as an engineer you should make sure you understand how what you are asked to make fits into the needs of the customer. If you just follow what the customer's procurement department and the sales people say they need then you are likely on a wild goose chase. But that has nothing to do with the development method but it has everything to do with getting clear requirements. The lead developer should talk to the technical people from the customer for that.

First: Well, to be honest, I'm not an engineer; I was a software developer and am now more of a scientist. I just see the value in good engineering, and try to follow sound engineering (no pun intended) principles.

Second: I've been the lead developer for most of my career.  My problems stem from not having the salesman bullshitting skills to fool clients and management into thinking I'm doing what they described to me, while I actually solve their underlying problem; and, being completely fed up with bullshitters and short-sighted idiots doing the opposite.  And being exploited by those with excellent social skills.

Think about this: One third of all large IT projects in Finland fail. And that is an acceptable state of the art. Salesmen love it, management get no repercussions, and everybody just shift the blame around.  "It's just how the world is."  I can't stand such asshattery.  We know how to build stuff well, but we choose not to, because doing so is not cost-effective. The result is crashing bridges, houses that become inhabitable due to mold issues, ceilings that crash, patient data systems that don't work, credit card services that are hackable so millions of people are at risk of their identities being stolen (misused) and all kinds of credit issues due to no fault of their own, and so on.  A pretty crappy world: more like a shantytown built out of garbage, where people use the unpaved streets as a toilet -- but with a really good-looking fake facade, if you look at it from a specific angle. (And don't mind the stench, you get used to it after a while.)

If I could, I'd live alone in the woods and switch to pottery or gardening, but I can't: I'm absolutely, irrevocably hooked to computational physics, simulations, sensor interfacing, and creating and discovering tools to solve problems, especially related to those aforementioned fields.

[P.Mouse]

I think there is some miscommunication here.
I wasn't talking about marketeers or anything else.
I was talking about direct co-workers or fellow engineers who claim to know it all, but aren't even able to understand the very basic concepts of it.
Worse spreading myths around which are purely based on marketing stories and use their status to claim to literally better than the rest.

I have been literally into situations people actually saying that someone else had to shut their mouth because they had a lower positions.
Even when everyone else knew that on a scientific or factual level they were totally dead wrong.
The "But this certain big company is doing it as well" is also often an argument these kind of people bring forward.
Not realizing that a big part of a product development is marketing or only offering a small niche or certain kind of customer.

[Nominal Animal]

I was talking about direct co-workers or fellow engineers who claim to know it all, but aren't even able to understand the very basic concepts of it.
Worse spreading myths around which are purely based on marketing stories and use their status to claim to literally better than the rest.

No, I'm just communicating badly: I'm talking about those people too. I just call them marketers and whatnot, even though they claim to be developers or whatever, because it describes better what they do: they market themselves, instead of working for those who pay their salaries. Bad wording, sorry; me fail english. (Also, I haven't worked with proper market professionals, myself.)

I have been literally into situations people actually saying that someone else had to shut their mouth because they had a lower positions.

I've had a manager introduce me to an expert in the field, in the hopes that some of it would rub off on me. With me having prepped that same expert on that particular subject the previous week.

[Bassman59]

Agile: A methodology used with projects when someone comes in for a talk and gives away free copies of their book to management. It is then applied to hardware development.

And how many board spins are allowed because "agile development" demands "early delivery" and "continual improvement?" I honestly don't understand it.

[Bassman59]

I guess it's also because of the requirement to know everything today. Every employer wants his staff to know everything about everything.

Ask shit, get turds.

And further, the problem with the "know everything" requirement is that the employers are rarely willing to pay for someone who knows everything. You see job descriptions that list requirements as "the sun, the moon and the stars," followed by salary range "small asteroid."

[Mr. Scram]

And further, the problem with the "know everything" requirement is that the employers are rarely willing to pay for someone who knows everything. You see job descriptions that list requirements as "the sun, the moon and the stars," followed by salary range "small asteroid."

Spot on. Of course they want someone with decades of experience and a stupefyingly varied yet in depth skill set for the wages of a junior fresh out of college, but that's not going to happen. What does happen is that the results become a lot less predictable if you don't set realistic requirements. It could now be a subset combination of any of those things, or none of them.

Another thing you sometimes see is that employers or sectors say they can't find enough staff to keep up. Reality often is that there is plenty of staff available, but not at the wages offered. Only rarely there actually is no competent staff available.

[ebastler]

Geez, guys. And I thought I was a bit jaded...

[Mr. Scram]

Geez, guys. And I thought I was a bit jaded...

We call it how we see it. The economy has picked up and is doing quite well. Is this reflected in the wages offered?

[KE5FX]

Agile: A methodology used with projects when someone comes in for a talk and gives away free copies of their book to management. It is then applied to hardware development.

And how many board spins are allowed because "agile development" demands "early delivery" and "continual improvement?" I honestly don't understand it.

Then again, board spins are cheap, especially nowadays, compared to the cost of being outcompeted.  If we could iterate PCB spins as fast as we can iterate software releases, we'd never have to worry about component obsolescence, supply-chain hiccups, bloated inventory costs, regional regulatory differences, or any number of other things.

[IanB]

Then again, board spins are cheap, especially nowadays, compared to the cost of being outcompeted.  If we could iterate PCB spins as fast as we can iterate software releases, we'd never have to worry about component obsolescence, supply-chain hiccups, bloated inventory costs, regional regulatory differences, or any number of other things.

Right, it's much more than board spins. It's about tooling up for production, establishing supply lines for components in the BOM, considering lead times and order volumes, and much more. You can't just simply change a product design every few weeks or months like you can with software.

The reality is that "Agile" as it applies to software doesn't apply to hardware. The hardware equivalent is "Lean Manufacturing", which has many similar principles, but it is applied in a way that is more appropriate to the industry.

That said, I see much evidence of short production runs where someone seems to design a product, make a certain number for sale, and then switch to a new design when the first lot of production is complete. It can be annoying when I buy something I like, go back for more, and find they don't make it anymore.

[BravoV]

The reality is that "Agile" as it applies to software doesn't apply to hardware. The hardware equivalent is "Lean Manufacturing", which has many similar principles, but it is applied in a way that is more appropriate to the industry.

Not very sure, but from my personal very limited experience, this "Agile" buzzword obeys the basic law of physic everywhere (software included), as once you grew with big mass body, you just can not make fast and "safe" turn anymore, without burning lots of energy (resources) to cope with the inertia. Every major changes need the readiness, simple things like documentation, support infrastructure, back end cost management/adjustment, and etc.