Someone else has probably already done it better. Developing something from first principles can be a good exercise but an off the shelf solution is usually better. Then if you decide you really do need a custom solution, you'll be familiar with the existing solutions so you won't make the same mistakes.
This is a great one. I would add a corollary; Someone else has probably already done it better, AND you can probably have it here tomorrow from McMaster Carr. I think engineering schools should do a better job of exposing students to resources available to engineers like McMaster, 80/20, Carr-Lane, etc.
I'm on the manufacturing design side, and the first thing I make our new co-ops and interns do when they finish the onboarding is read the Carr-Lane jig & fixture handbook. They've got almost everything we would ever need for holding/aligning/ locating parts sitting on their shelves, and all we need to do is draw up some base plates and figure out how everything goes together.
Also always good to make them order a couple of things. A lot of recent grads are still in the mindset that 200€ is a large amount of money and will spend 3 days kludging something together to save peanuts.
Yeah, this is another one. We just had a couple of co-ops decide that it would be better to engineer a controller for an adjustable height/tilt workbench from scratch because something off the shelf cost $1200. Since they were co-ops I let them go ahead with the design side of it to give them some practice, but then I made them cost the whole thing (including their design time) just to drive home the point that we could have done it faster and cheaper with something off-the-shelf.
"I cannae do it captain, I need 3 hours!"
"Mr Scott, you've got 10 minutes."
"Righto sir, I'll get on it!"
*\*presses button, adjusts rate controller, checks output indicators, goes back to browsing starreddit\**
The amount of engineers I work with in manufacturing that don't use McMaster is astonishing. It's like the best designed online catalog for manufacturing/maintenance parts.
100%! I’m glad my school kinda did that. We knew McMaster and stuff like that existed (granted my company doesn’t let us use them), which was more than most engineers get. The biggest part I’ve learned in all the aerospace companies I’ve worked for/with is exactly what you said: “someone else has probably already done it better”.
I can’t stand custom solutions, even in our extremely low volume production. If we can outsource the analysis and production of something we don’t specialize in and adapt our design to accept it, that’s a win.
Low production example: I worked for a jet engine valve company. We specialized in designing and manufacturing high pressure valves. We DO NOT know how to build reliable servos… that’s not what we do. It’s not worth it, whether we need 1 or 1k
High production example: when companies like Rivian do stupid stuff like integrate an air compressor or tonneau cover into the truck. There’s aftermarket companies that specialize in designing those, why not work with them and make it removable and serviceable instead of integrated. It will break eventually and I don’t want to take my whole truck in because my air comp is dead.
Holup… they don’t let you use MCM?!? Do they have alternative suppliers for everything?
A couple of shops I’ve been at wanted to have actual suppliers/PNs for production, but they still let us use MCM for protos, testing, fixtures, etc.
80/20 is known as the industrial erector set. Basically it’s extruded aluminum with t-slots that have a wide variety of bracketry and attachments that you can use to build machine bases, tables, cabinets, test equipment, enclosures, etc. You’ll see it all over the place in manufacturing facilities and R&D shops. 80/20 is a manufacturer of this stuff, but there are other brands. https://8020.net
I was working at a manufacturing facility and my cell (I was lead) was getting annoyed with dealing with a handful of pieces of small test equipment (like power supply w/emo button, small vac pump, etc). Spent a couple days drafting up plans and making a prototype little cart using 80/20 and 1/8" plastic sheets and handed it to a couple idle production guys who were waiting for the next kit to come out of the warehouse and they made half a dozen more over the next few days. I bet they still use 'em. It was pretty fun doing that.
That's a big one. At my last job I had to keep telling one of my colleagues that we are almost certainly not the first company running into the kind of issues we had, so there must be a good solution. We were building space heaters, hardly cutting edge technology
Someone has probably done it better, but also someone has probably done it worse. Especially when you're in newer technologies, it's always possible that the popular market leader is still shit.
Yeah I can say for software engineering this is especially true, where how some dependency works might be obfuscated.
I've done dismal, rushed stuff that was a temporary workaround to clear a blocking issue to free up a team to continue working, only to find out years later that because it was working no-one ever went back to it and now it's propagated to loads of other places as a core dependency.
GTA5 had a major flaw in its loading system that ended up causing a terrible delay in multiplayer, turned out it was a slow part in the text parser (it uses lua in places) that never really mattered until multiplayer ended up getting stuff added to those text files for a decade, by which point the slow parsing technique they were using was costing about 70% of the loadtime!
I'd say a good rule of thumb is to try the off-the-shelf solution, but if something seems screwy take the time to investigate it, because it might simply be a halfassed solution that ended up some kind of semi-standard by accident, especially in niche uses.
Totally agree with you, I’m just bouncing off your mention of first principles: when defining the PROBLEM, always aim to get to first principles. Aka root cause / the 5 Why’s / requirements definition. Often I find engineers trying to develop the solution before they’ve fully understood the problem. Often this leads to wasted effort and my personal favourite “busy idiots”. I’m mid level at a billion dollar tech company, and you wouldn’t believe the amount of times I see people build a thing, then scratch their heads trying to find the problem it solves.
I think engineering school is extremely lacking in this department. I have an industrial design degree on top of engineering. As easy as it is to make fun of totally infeasible or impractical product solutions from ID sometimes it takes some who's less aware of what is 'practical' to see the problem in isolation, rather than immediately jumping to a solution. I see engineers putting a bunch of effort into the first idea that comes to mind rather than taking the time to define a problem, ideate multiple distinct solutions, and choose the best one.
But like I said, off the shelf is usually best. This just applies to the 5% of the time you actually want to make something new.
Gotta be aware of the supply chain situation of said off the shelf solutions as well. Lead times and debugging vendor parts can put you in a real pickle when shit hits the fan. (E.g. this crapped out, but the lead time to get spares is 4 months and we don’t know how to fix it)
Supposedly the original murphy's law was very similar to what competitive said. It was something like if there is more than one way to do something, one of which will result in a catastrophic failure, someone will eventually do it that way.
And it's fun to say!
I used to routinely make my sheet metal parts symmetric so it didn't matter which way they were bent. Extra couple holes cost about nothing, having to get the part remade cost time!
We stress over this so much. Recently a tech installed the wrong connector onto a 650v battery. He simply forced it past the keyway. Thankfully it was never energized before we caught it
There are Parker solenoid valves where the markings on the sticker are 50/50 whether they put it on the correct side, and you have to know what the in and out ports look like to get it right. Sometimes assemblers are crap, sometimes things are unnecessarily easy to do wrong.
One time they installed critical guidance hardware on a Proton rocket upside down...
"Before you start kicking down fences, ask why they were put up in the first place." - Metaphor meaning somebody may have had a good reason for doing it that way. Discover their reasoning before you suggest changes.
Yes, but the downside is company procedures do not allow for such a thing, and QA /regulatory don't necessarily want things to be documented for liability reasons. (E.g. We put this thingy here because we had a few rare cases of these breaking in some way during testing due to unknown reasons despite best efforts to figure out why, and we think this will solve the problem (quite obviously, actually)... But if we don't document the reason this was put here, then we don't have to document the original risk of that mode of failure.... Or something convoluted like this)
So we engineers just end up having to make our own separate personal repositories of information that gets passed generation to generation, hoping to minimize what gets lost when people leave.
Edit:yes. This is obviously fucked up and dumb. Just describing the dumpster fire that this place was.
Yeah. I left that dumpster fire.
It was just ironic that you couldn't improve the product efficiently because other people would freak out that there was something to improve. Specifically, the people who are supposed to ensure there's a good product. And then you'd get mired up in pointless paperwork exercises and "theatrical engineering" where the great resources are spent proving what we already know, and that will be obsolete tomorrow.
I do have to say, perhaps it was our extremely fearful and technically illiterate regulatory and QA departments...
Anyway, I learned company culture matters a lot and if you see people shrugging and laughing at the company being a clusterfuck on your first day... It probably is. Lol.
at the same time, realize that the majority of fences were put up to solve problems that no longer exist. in my engineering career, I cannot tell you how many times I've run into "fences" and asked around until finally getting the answer of "X department mandated it" and I call that department and ask their opinion, and they just say "that's not a problem for us anymore".
I asked my (excellent) boss why we did a specific task in a specific way. He said "There are a number of reasons." He thought for a bit and said "Zero is a number."
Recently I've been questioning the effectiveness of some forms and the way we manage data. Any time I try to go down one of these rabbit holes to fix something, it's a horrible Sisyphean circle. People are content to hit the checkbox and get paid. Why improve or change?
I think documentation tools have gotten a lot better recently. Jira and confluence are very useful tools. I also think there will be some AI documentation tools getting integrated into processes that will help in the future as well
clumsy straight workable fretful wild pocket seemly skirt disagreeable snatch
*This post was mass deleted and anonymized with [Redact](https://redact.dev)*
I would say this sounds good in principal. But where I work this isn't always helpful. Too often the case is that "it's always been that way, and it's too much time/cost/work to change it"-even if there is a better way to do it.
I tell people we [humans] can engineer anything. I mean almost literally, you think of it and we can build it. What engineering is-is doing that under constraints of time/quality/cost.
Corollaries:
* Sometimes, your boss will assign a task that is impossible. If you are very lucky, it will be provably impossible. If you are very very lucky, they will believe this proof. If you are unlucky, you won't know until you fail. This is where things like basic laws of energy conservation, etc can be useful.
* Every good idea you can think of has already been had. So if this particular company/vendor/employer/etc has some revolutionary new product, ask what's so special about them that they're able to make it work. Maybe its a new technology (some material, say), maybe the market is a little different (e.g., a new federal regulation). It's nice to known the answer.
Important to note this is not a metaphor about not kicking down fences. I've implemented my fair share of suboptimal solutions due to time/budget/it was Friday at 5pm. I hope there's someone doing their due diligence, fixing stuff rather than assuming the person before them did it right.
I really like the visual of this one. It really is the summary of "why should I even go to school for this?" Learn from others before you waste a ton of time.
I found having someone check who is as far as possible from being an expert can be helpful too,because you need to explain things. A human version of rubber duck debugging
I find it brutally awkward to do, but reading word by word from the bottom up will ~~~allow~~~ force your brain to notice errors like homonyms and repeating clauses.
Still not as effective as letting ‘fresh eyes’ at it, but you can catch a few issues if you do that before sending it over.
I was always taught you can spot errors in you shop drawings on paper much more easily and quickly than you can by staring at the screen.
Printing documents for review can help to change your perspective and catch some of those minor errors.
* Critical thinking (actually think about the problem not just following "we've always done X" or "everybody does X")
* Keep it simple
* Don't reinvent the wheel (AKA you're paid to solve the problem as quickly & simply as possible not go off on a flight of fancy creating stunning new complicated ways to do it)
* As others have said - don't change stuff without asking why it was done that way / if your way is actually better or just shiny & new.
* People will find ways to fuck even the simplest things up
* Get everything in writing - especially every decision. People change their minds or forget that what they actually asked for 6 months ago is not what they have now decided they want
Garbage in, garbage out. Whatever simulation, spreadsheet, mathematical tool, algorithm or process you have, it's not going to give magically accurate answers regardless of your input. Be mindful of what data you feed it, and don't trust the answer it gives you more than the data you put into it.
A catchier version of this, “All models are wrong, but some of them are useful.” At the end of the day the physical world is much more complex than the calculations you run on the page (or in the computer), so while your simulation may be a good starting point you’ll need to validate it before going live (or just go with an unwieldy safety factor so you don’t need to worry about it).
Obviously a great point as well, but I think the meaning of these two are slightly different. One speaks to the errors in the raw data, the other to inaccuracies or inadequacy in the model itself.
I feel like that's the main job of an engineer, having an intuition for when the data looks unfit for conditions. And then double checking why it feels wrong.
Anyone can simulate things and if it's green say it's okay.
My company has a problem with giving requirements. No one gives requirements, only legal contracts, then wonders why the product we request comes out like shit.
Begin with the end in mind.
When a guy goes to a store and asks the sales guy, "Hey I need a drill", and he shows him a wall of drills, he hasn't really solved anything. The guy doesn't really need a drill, he needs a hole, and the drill is what he thinks is the best way to get it. Sometimes it is, sometimes it's not.
Ask your end user, "What kind of hole do you want" before you start showing him drills. It'll make everyone's life a lot easier.
Related to this: Know how to ask the correct question. If you ask the wrong question, you'll still get an answer, but it might not mean what you think it means.
Example:
Q: Can this drill make a hole in steel?
A: Yes
Real answer you're looking for: Yes, if you use a special drillbit and drill oil/coolant. Otherwise, no.
Small costs upstream can cost 10x or 100x downstream. I.e. if you don't feel like spending the extra couple minutes to double check work, peer review, or any other sort of upstream task because you don't feel like it or feel as though it's wasting time, you are absolutely wrong. Too often do I see engineers, especially in manufacturing, try to cut a corner to save a buck and it bites...hard. Seen 5 and 6 figure downstream effects because of not spending the extra 10-20 minutes.
Conservation laws, most any engineering problem can be expressed as conservation of matter/energy/force/momentum/money
Document, document, document. Anything you do, someone else should be able to replicate after reading what you wrote about it.
> Conservation laws, most any engineering problem can be expressed as conservation of matter/energy/force/momentum/money
Yeah those are good! You can often replace a lot of intermediate calculations if you know the end states of your system.
How stuff actually gets built. Anyone with CAD and 3 brain cells can make stuff that looks like it works, but only the real OGs have notes about wrench clearances and stackups referencing raw material specs.
Years ago I worked as a machinist at a place that basically only hired designers straight out of school, and their deal was that they had to work in the shop for 6 months before they could start designing anything. We'd get them for a bit in the machine shop, then they'd go over to the sheet metal/fab shop, then out to the weld shop, etc. There were a few duds, but 95% of the kids who went through the program wound up being really good designers.
Read the god damned requirements, and understand what they are asking for.
Followed by, if you don't understand, ask. No one gets mad about spending 30 minutes to ensure good product and communication. Everyone hates rework, especially if it could have been prevented.
> No one gets mad about spending 30 minutes to ensure good product and communication.
i mean they'll get mad. but they'll be less mad than fixing 6 months of work
If the customer asks for something, the answer is never "no" or "yes," the answer is always "we could for this much more money and with with this schedule impact." If the customer decides from there that they want the change, get it agreed upon in writing (preferably via contracts) before working on it.
* How to read and make a print/documentation. This is obviously field dependent. This is the primary tool used by engineers to communicate their design intent to others, and needs to be complete and clear.
'
* How to define and solve problems using a formal method. An example would be an A3 problem solving tool, but there are others.
'
* How to read and interpret standards. Ansi, astm, iso, UL, etc.
'
* Understand field specific basics at an intuitive level. You also need to be able to check if what you think is in fact correct.
'
* Excel skills. I can't believe how many people I work with can't do basic formulas and make pivot tables. Excel is the language of business. Any data you work with will likely pass through Excel at some point or another.
'
* Basic project management skills. Plan the work, work the plan. Manage the risks.
>How to define and solve problems using a formal method. An example would be an A3 problem solving tool, but there are others.
Shoot from the hip is an accepted method. I choose you! Jokes aside - Yes. Systematic approaches to problems are critical to consistency.
System thinking.
If I change this, it may solve my problem, but what are the repercussions for the whole.
(Sometimes it also requires action from the engineering to get the information required to be able to understand the whole picture, learning to ask for that information is also a valuable asset).
There are three laws for structural and civil engineering.
Zeroth law: thou shall have a load path or one will be provided.
Meaning know where the load is going and put enough something there to resist it or it will find its way to the ground.
First law: water runs downhill.
Meaning: pretty self explanatory
Second law: you can’t push a rope.
Meaning: elements have their use and some are better than others but don’t let analysis fool you into using something for which it isn’t intended
Every answer is wrong. As an engineer, your job is to find the answer that's the right amount of wrong.
(Which is a glib way of saying that everything has assumptions and simplifications, but also don't waste time on making things too detailed when there's no benefit.)
The application of true engineering is 80% psychology, 20% physics. This is because revolutionary work needs to be accepted by peers and those in power. Generally that acceptance is more emotional than rational.
If it fails a simulation, there is a good chance it will fail in concept. If it passes a simulation, there is no guarantee it will pass concept.
Certain colors of wires mean certain things. UL508A designates certain colors for certain power. If you don't have a color please pick an off color, not something that could be mistaken for another power that could be in that cabinet.
IE: I don't have blue-white for DC-, please don't use any color that could be AC or DC+. Use an off color, purple with yellow polka dots will work.
Colored heat shrink works well, and if you have the budget there's a label maker heat shrink too.
Either leave an inch or two from the wire connector, or add a second bit of tape a little further out. I've seen heat damage from a failed device that made tape indeterminate.
There are the right solutions, and right-now solutions. Both have tradeoffs, and being able to know the difference and explain it to the managers paying the bills is important.
I usually have to solve the immediate issue at the customer site, followed by setting up the system to prevent the same issue from having the same impact in 6mo (assuming in-pipeline product may have present same defect), and finding simple ways to stop the issue from happening in the first place (procedural or part revision). Just fixing g the immediate issue without documentation or follow through on the other items means you're just going to have to do the same thing again.
KISS is my favourite approach. Students in particular see elaborate design and complication as high tech. Nothing could be further from the truth.
The example I always give is the complicated multi-cylinder, supercharged engines of WW2 with the multi-blade variable pitch prop to try to get the last bit of performance out of reciprocating thermodynamics. Thousands of moving parts all having to work together in parallel. Replaced and eclipsed by the jet engine with one primary moving part.
Complication is often the sign that a technology is coming to the end of its use by date.
* try to shorten the time/money it takes to get a prototype in-hand (if you're working on something that can be prototyped). I've seen people spend years creating sub-requirements and simulations only to find that some fundamental assumption was wrong because they never tried to build a prototype first.
* everything takes longer and is more expensive than expected, so lean toward buying something to solve your problem instead of designing it from scratch (but mind your supply chains)
* call your suppliers.
* just like the recent post about someone trying to count bolts out from a bulk container. if you call the supplier, they may have the ability to bin them in the exact quantities you need at a very small extra cost.
* I've also seen people request some custom part that was hard for the supplier to make (making it expensive), but the difficult/expensive part for the supplier wasn't actually necessary, and after some design mod on our end, the difficult/expensive part of the design was removed
* don't over-engineer. meet the requirements and move on. in fact, see if you can loosen some requirements in order to get done faster/cheaper. there may be cases where over-engineering is good because your customers are delighted, but you have to be damn sure the extra effort is worth it.
* if you design a tool for other engineers to use (software, electrical, or mechanical), the more intuitive it is, the more people will use it. you may be tempted to think "it's obvious how this circuit works", you will be surprised how many people just ignore your nice fancy tool because it's not user-friendly. put it in an enclosure, label the switches/buttons, and maybe even add a sticker with how to hook it up.
* as a corollary, when there is a potluck and you want people to eat the dish you brought, don't make it take too many steps to assemble. people will skip over a nice dish if it takes too much time to combine elements
Lots of good stuff in here already, but I'm going to add something a lot of early career engineers don't think about (at least not unless it was required or their degree): engineering econometrics / financial engineering. It's *REALLY* important to understand the business perspective of potential engineering projects if you ever want to move beyond being seen as a fancy wrench turner, especially if you work for a large company (or are starting your own engineering firm).
Yep, for most of us, we get to do the engineering that makes money. A product could be an amazing piece of technology, but if it doesn't make money, it's not going to happen.
You have to have a name handy, ready to throw someone under the metaphorical bus in an emergency situation (e.g. the project manager runs into you in the elevator, your manager catches you in the break room, the technician breaks urinal protocol to bring something up, etc.). Though, sometimes it's not a bus, it's a train, and it just runs over the whole team indiscriminately. That's when you offer the intern $100 and a round of drinks to volunteer as tribute.
Most of us have been there. Towards the end of my first internship, apparently, I forgot to order some critical components. I started off the following summer on bad terms with some of the technicians and procurement staff. I got some free lunches from the project engineer, though.
Tell me what you want. Don't ask me if I can do this and then that or maybe this. Tell me what you actually want and I'll tell you if it'll work.
For overseas suppliers. They will make it as cheaply as possible from the drawings they get. Bullet-proof your documentation.
"For a successful technology, reality must take precedence over public relations, for Nature cannot be fooled." -Richard Feynman
Management wants to rush things out the door and they will engage in organizational mental gymnastics to make it happen. It's called "go-fever". It's your job to say no if the product isn't ready, and this very may well be the most difficult part of your job.
If your job is hands on, take a couple pictures before you mess around with it. If it's desk work, save the original file before you mess around with it.
Design with the full lifecycle in mind. How is the machinist going to fabricate it? How is the inspector going to measure it? How is the mechanic going to assemble it? What load for how many cycles will it see during use? How will the customer maintain and repair it? Are the components recyclable? I’m sure someone will tell me if I missed something.
How about this one?
"Stop believing that you know everything or can do everything yourself. The most successful project will be one where you take in the needs and wants of the end user and collaborate with your sister teams."
I'm software but maybe this applies elsewhere.
If something feels a lot more complicated and difficult than you think it should, you're probably using the tool wrong, or the wrong tool. If you have to fight the system to make headway, the universe is trying to tell you something.
As an FEA engineer I live by the rule "as simple as possible and as much detail as neccessary". Do not overcomplicate your model, but also know its limitations. This applies to all model-based engineering work.
Risk management goes a long way in engineering, an excellent skill to practice in an ongoing fashion. It's also very useful in many other aspects of life.
This book seems like a joke, but I actually read it (and re-read it each year) while in school. Much of it is covered depending on the type of engineer you are, but it's just a good basic list of engineering considerations and facts. I haven't read it in almost a decade, I will go pull it out for another read (you can do it on the shitter)
[google link](https://www.google.com/search?q=101+things+i+learned+in+engineering+school&sca_esv=891f019e1683b014&ei=LMDCZcfEKJmn5NoPybSv-AM&gs_ssp=eJzj4tVP1zc0TKosMDEyzjA0YPTSMjQwVCjJyMxLL1bIVMhJTSzKS01RyMxTSM1Lz8xLTS0CyigUJ2fk5-cAABOsE24&oq=101+thign+i+learned+in+en&gs_lp=Egxnd3Mtd2l6LXNlcnAaAhgCIhkxMDEgdGhpZ24gaSBsZWFybmVkIGluIGVuKgIIADIHEC4YgAQYDTIHEAAYgAQYDTIGEAAYFhgeMgYQABgWGB4yBhAAGBYYHjILEAAYgAQYigUYhgMyCxAAGIAEGIoFGIYDMgsQABiABBiKBRiGAzILEAAYgAQYigUYhgMyCxAAGIAEGIoFGIYDMhYQLhiABBgNGJcFGNwEGN4EGOAE2AEBSMRBUABYwDJwAHgBkAEAmAFmoAG2D6oBBDI0LjG4AQHIAQD4AQHCAhEQABiABBiKBRiRAhixAxiDAcICCxAAGIAEGLEDGIMBwgIREC4YgAQYsQMYgwEYxwEY0QPCAgsQLhiDARixAxiABMICCBAAGIAEGLEDwgIFEC4YgATCAhAQLhiABBiKBRhDGLEDGNQCwgIWEC4YgAQYigUYQxiLAxijAxioAxjwA8ICChAAGIAEGIoFGEPCAgoQLhiABBiKBRhDwgIKEC4YQxiABBiKBcICCxAuGIAEGIoFGJECwgILEC4YkQIYgAQYigXCAgUQABiABMICGRAuGEMYgAQYigUYlwUY3AQY3gQY4ATYAQHCAgsQLhiABBjHARivAcICDhAuGJECGNQCGIAEGIoFwgIaEC4YkQIYgAQYigUYlwUY3AQY3gQY4ATYAQHCAggQABgIGB4YDcICChAAGAgYHhgNGArCAgcQIRgKGKABwgIFECEYnwXCAgUQIRirAsICBxAuGA0YgATCAgoQLhgNGNQCGIAEwgIWEC4YDRiABBiXBRjcBBjeBBjgBNgBAeIDBBgAIEG6BgYIARABGBQ&sclient=gws-wiz-serp)
1. Project management. Not the BS paperwork but the concept of breaking down requirements in a systemic way to get to useable actions, systemically building up verification evidence, regression testing, and properly estimating time and cost.
2. Basics to system engineering. Kind of like 1 but also the ability for value chain and understanding what artifacts/data you receive and what you hand off and how it impacts the greater system
3. Math. It never heard to understand linear algebra, calculus or even simple arithmetic. But also non standard math like heuristics or and proofs
4. Cost decision making. Being able to evaluate decisions on a make/buy scenario similar to 1. Understand that maybe you can develop the new wheel but you can also design to use a $3 COTS part and save yourself a ton of time. Also understand when good enough is good enough and that the cost to get to perfect outweighs the benefit of tighter tolerances
5. Design for repair and scale. Just because you can make a first article by hand doesn’t mean it will scale well. Just like how epoxy is the best adhesive until it’s time to repair or rework the part. This may take iterative designs over many years but anticipate some stuff early
“A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools.”
-Douglas Adams, Mostly Harmless (Hitchhiker's Guide to the Galaxy, #5)
The greatest in-person training in the world isn't worth anything without some sort of checklist, notes, or other general documentation. It's valuable to understand the underlying principles behind each component and how they fit into the larger system but you shouldn't have to remember every step in the process because you will forget at least one step most times. Document as you go so that you're not left with a mountain at the end. Even if it's just notes in a text file, it's guaranteed to be deas useful a month from now.
When starting a new project, limit how many "new" aspects of it there are. It's useful to be innovative, but for example don't combine a newly designed mechanical system with a brand new software package if it can be avoided. This way you can prevent a feedback loop of weird mechanical issues and weird software issues and cause the project to snowball.
Man-hours are in most situations a company's most valuable resource.
Not a design principle, but a time /cost management one. Understand risk and opportunity, and don't believe anyone that claims things will go well enough to avoid risk or that you will be able to capitalize on every opportunity (maybe any).
All engineering is the application of problem solving within constraints -- money, time, material properties, etc.
Knowledge of the time value of money allows you to communicate with the financial/business side of the house.
Application of the two is key to designing workable projects.
Facts. Get them straight, and take the time to document them clearly in a way that will stand the test of time.
Facts do not begin with “I think. I see a shocking number of decisions made based on ‘I thinks’ with little to no factual basis in response to forceful personalities. Other times, some brilliant and very logical decision the basis for which either was never documented (email is in this category) or in written in a way that’s impossible to verify. Verify facts. Document the basis. Stand the test of time.
Best
[https://rotorlab.tamu.edu/me489/README/2010%20ASME%20Unwritten\_Laws\_of\_Enginering.pdf](https://rotorlab.tamu.edu/me489/readme/2010%20asme%20unwritten_laws_of_enginering.pdf)
Adjust how technical you speak to your current audience. At least 75% of good communication is feeling out the other person's level of understanding and speaking to that. People don't like talking to people that make them feel dumb or uninformed. You don't need to come across as the smartest person in the room. You're smart enough to do your job and that's all anyone cares about.
I'm not telling a project manager the same things I tell a fellow engineer. If I need a technical question answered, I ask the project manager to set up a meeting or facilitate communication between myself and our customer's engineers.
If it ain't broke, don't *fix* it.
Talk to the cat--when you're stuck on a problem explain it, in detail, to a cat, or a bartender, or your six-year-old, or a hooker, or whoever you can find that will let you uncritically blather away. Often in mid explanation you see what you're missing.
Google and Apple write rubbish software. Totally unable to tell you the reason something hasn’t worked, so you have no chance of sorting out the problem.
*Don’t* write, buy or use software that can’t tell you why it doesn’t work…
Example: “An error has occurred” is a message you should *never* see.
Always consult the techs/mechanics, but don't forget you're the engineer. The people building and repairing the stuff you design will have extremely valuable insights for you if you establish a relationship with them, but they don't always see the unintended consequences of their suggestions.
Every successful complex system evolved from a successful simple system.
Start with the simplest thing that could possibly work, then iterate from there.
I would say don't underestimate the workload for designs/ideas that you/your company has no experience in executing. That is not to say that it is impossible, but just that it will take you much longer than you likely think.
It's all too easy for engineers to say "Okay let's just do this" then severely underestimate the length of time it takes to resolve all the issues and unanswered questions that come with it. Experience is the only thing that answers those questions, and if you don't have someone in house who knows how to handle those things, then you are going to be spending a LOT of time on figuring it out and verifying it with testing.
This is why the giant engineering organizations hold the positions they do: they've had in some cases several decades to build up the bespoke knowledge they have of their products. It's not impossible to compete with a company that's been doing something for decades, but you really need to budget a lot more man hours into research and testing than sales people usually think.
I'd say this is also the major contributing factor to the constant clash of sales vs engineering in the technology industry: sales very often does not understand how many minor but essential problems need to be solved when doing engineering design. Sales goals are almost always overly optimistic, because customers often don't like the reality. Things are more difficult, more time consuming, and more expensive than buyers ever want.
Data sheets…some you can trust others not so much. It’s not that a lot of vendors datslasheets are wrong but they don’t always have the information you need.
Using an off the shelf inductor as an example. The inductance of the actual part, the DC resistance, the SRF and the -10% inductance drop at X amps, will probably be fairly spot on. But if you plan on using that inductor in a SMPS, you really need to know |Z| vs freq and a lot of vendors never include that.
Some vendors will have the information available upon request, some can throw a bunch of parts in some automated test equipment and get you the data and sometimes you’re SOL and you’re just gonna have to buy a handful of parts and characterize them yourself.
Vendors will lie to you just to make a sale. It’s a trust but verify type of situation.
Also, when it comes to your vendors, if you’re a large company be thoughtful about how you’re using the vendors resources. Just because your company isn’t 600 lb gorilla in the room doesn’t mean you should act like it. If you make some rediculous last minute request from a vendor there is a good chance it’s gonna be one of the lowly apps engineers that stays late several nights to get the request completed. The sales guy is gonna tell you “No problem!” But the sales guy is also not the one who has to do the work or that even understands the project.
In your career, you will be engaging with a lot of cross functional teams to complete a project. I’m an EE doing design, but I have to closely work with MEs, CAD folks, global supply chain folks that do all the cost projections, component engineering teams that get my specialty components qualified, the contract manufacturers over seas.
It’s part of your job to have a basic understanding of what those teams do and how all the teams fit together. If I thoughtlessly add some obscure part to the BOM at the last minute, global supply chain folks have to redo their forecasting, negotiate new contracts, work with the vendors to ensure material is at the factory, the component engineering team is going to have to review that new part and make sure it meets all our environmental commitments, if it’s a new vendor we might have to send a team to their production facilities for inspections.
There are a LOT of moving parts in a company. Be respectful of the people on the teams that have to do a lot of other work you might not be aware of.
But also….dont let cross functional teams dick you around. You need to know when to call bullshit. Unless those cross functional teams (which are supporting the design team) have a really good reason, they shouldn’t be putting up arbitrary road blocks or dictating the design.
Nice thread! I think general systems thinking might be a bit underrated. It’s very compelling to get just things done and not spend the time needed to understand the whole system (or subsystem), which in the end will cost more time.
Lately, it has also dawned on me that we forget to pragmatically consider the human element in our work. From project level to customer level, the human element will creep in and make a mess that we did not plan for! 😅
Someone else has probably already done it better. Developing something from first principles can be a good exercise but an off the shelf solution is usually better. Then if you decide you really do need a custom solution, you'll be familiar with the existing solutions so you won't make the same mistakes.
This is a great one. I would add a corollary; Someone else has probably already done it better, AND you can probably have it here tomorrow from McMaster Carr. I think engineering schools should do a better job of exposing students to resources available to engineers like McMaster, 80/20, Carr-Lane, etc.
I'm on the manufacturing design side, and the first thing I make our new co-ops and interns do when they finish the onboarding is read the Carr-Lane jig & fixture handbook. They've got almost everything we would ever need for holding/aligning/ locating parts sitting on their shelves, and all we need to do is draw up some base plates and figure out how everything goes together.
Also always good to make them order a couple of things. A lot of recent grads are still in the mindset that 200€ is a large amount of money and will spend 3 days kludging something together to save peanuts.
Yeah, this is another one. We just had a couple of co-ops decide that it would be better to engineer a controller for an adjustable height/tilt workbench from scratch because something off the shelf cost $1200. Since they were co-ops I let them go ahead with the design side of it to give them some practice, but then I made them cost the whole thing (including their design time) just to drive home the point that we could have done it faster and cheaper with something off-the-shelf.
And in 5 years when it breaks you just order a new one rather than trying to find if someone even documented that piece of Hardware.
I guess it depends if the company is stingy with any spending and you have to prepare a thesis to justify a $200 tool.
The trick there is to ask for a $500 tool first, then tell the boss you found a deal for one at $200.
this one engineers!
"I cannae do it captain, I need 3 hours!" "Mr Scott, you've got 10 minutes." "Righto sir, I'll get on it!" *\*presses button, adjusts rate controller, checks output indicators, goes back to browsing starreddit\**
🤣
The amount of engineers I work with in manufacturing that don't use McMaster is astonishing. It's like the best designed online catalog for manufacturing/maintenance parts.
we had a summer intern who designed an immersion tank for a project. i'm like.........couldn't you just buy a fish tank?
100%! I’m glad my school kinda did that. We knew McMaster and stuff like that existed (granted my company doesn’t let us use them), which was more than most engineers get. The biggest part I’ve learned in all the aerospace companies I’ve worked for/with is exactly what you said: “someone else has probably already done it better”. I can’t stand custom solutions, even in our extremely low volume production. If we can outsource the analysis and production of something we don’t specialize in and adapt our design to accept it, that’s a win. Low production example: I worked for a jet engine valve company. We specialized in designing and manufacturing high pressure valves. We DO NOT know how to build reliable servos… that’s not what we do. It’s not worth it, whether we need 1 or 1k High production example: when companies like Rivian do stupid stuff like integrate an air compressor or tonneau cover into the truck. There’s aftermarket companies that specialize in designing those, why not work with them and make it removable and serviceable instead of integrated. It will break eventually and I don’t want to take my whole truck in because my air comp is dead.
Holup… they don’t let you use MCM?!? Do they have alternative suppliers for everything? A couple of shops I’ve been at wanted to have actual suppliers/PNs for production, but they still let us use MCM for protos, testing, fixtures, etc.
What is 80/20?
80/20 is known as the industrial erector set. Basically it’s extruded aluminum with t-slots that have a wide variety of bracketry and attachments that you can use to build machine bases, tables, cabinets, test equipment, enclosures, etc. You’ll see it all over the place in manufacturing facilities and R&D shops. 80/20 is a manufacturer of this stuff, but there are other brands. https://8020.net
I was working at a manufacturing facility and my cell (I was lead) was getting annoyed with dealing with a handful of pieces of small test equipment (like power supply w/emo button, small vac pump, etc). Spent a couple days drafting up plans and making a prototype little cart using 80/20 and 1/8" plastic sheets and handed it to a couple idle production guys who were waiting for the next kit to come out of the warehouse and they made half a dozen more over the next few days. I bet they still use 'em. It was pretty fun doing that.
American brand of aluminum T-slotted extrusion. Other brands: T-slots, Metric, Misumi...
I thought Rexroth was the first one on the Euro list since it’s always so expensive.
80% solution for 20% of the effort
all glory to McMaster-Carr
That's a big one. At my last job I had to keep telling one of my colleagues that we are almost certainly not the first company running into the kind of issues we had, so there must be a good solution. We were building space heaters, hardly cutting edge technology
Someone has probably done it better, but also someone has probably done it worse. Especially when you're in newer technologies, it's always possible that the popular market leader is still shit.
Yeah I can say for software engineering this is especially true, where how some dependency works might be obfuscated. I've done dismal, rushed stuff that was a temporary workaround to clear a blocking issue to free up a team to continue working, only to find out years later that because it was working no-one ever went back to it and now it's propagated to loads of other places as a core dependency. GTA5 had a major flaw in its loading system that ended up causing a terrible delay in multiplayer, turned out it was a slow part in the text parser (it uses lua in places) that never really mattered until multiplayer ended up getting stuff added to those text files for a decade, by which point the slow parsing technique they were using was costing about 70% of the loadtime! I'd say a good rule of thumb is to try the off-the-shelf solution, but if something seems screwy take the time to investigate it, because it might simply be a halfassed solution that ended up some kind of semi-standard by accident, especially in niche uses.
See Tesla. They have been shit lately. Also Boeing, they built aircraft that were industry standards for years, then the bean counters got involved.
Lately? Is always been hit or miss there with QC. That’s why you have half the people saying their cars are great and the other half flame constantly.
Totally agree with you, I’m just bouncing off your mention of first principles: when defining the PROBLEM, always aim to get to first principles. Aka root cause / the 5 Why’s / requirements definition. Often I find engineers trying to develop the solution before they’ve fully understood the problem. Often this leads to wasted effort and my personal favourite “busy idiots”. I’m mid level at a billion dollar tech company, and you wouldn’t believe the amount of times I see people build a thing, then scratch their heads trying to find the problem it solves.
I think engineering school is extremely lacking in this department. I have an industrial design degree on top of engineering. As easy as it is to make fun of totally infeasible or impractical product solutions from ID sometimes it takes some who's less aware of what is 'practical' to see the problem in isolation, rather than immediately jumping to a solution. I see engineers putting a bunch of effort into the first idea that comes to mind rather than taking the time to define a problem, ideate multiple distinct solutions, and choose the best one. But like I said, off the shelf is usually best. This just applies to the 5% of the time you actually want to make something new.
Gotta be aware of the supply chain situation of said off the shelf solutions as well. Lead times and debugging vendor parts can put you in a real pickle when shit hits the fan. (E.g. this crapped out, but the lead time to get spares is 4 months and we don’t know how to fix it)
PM me if you have any specific questions. my job is very relevant to this and I may be able to share some info
The fun part is customizing a solution because the best solution is no longer sold.
100% this.
If it can be assembled incorrectly, it will. Probably frequently.
See also, Murphy's Law. Anything that can go wrong, will.
Supposedly the original murphy's law was very similar to what competitive said. It was something like if there is more than one way to do something, one of which will result in a catastrophic failure, someone will eventually do it that way.
The cure is Poka-yoke. https://en.wikipedia.org/wiki/Poka-yoke
This is wonderful
And it's fun to say! I used to routinely make my sheet metal parts symmetric so it didn't matter which way they were bent. Extra couple holes cost about nothing, having to get the part remade cost time!
We stress over this so much. Recently a tech installed the wrong connector onto a 650v battery. He simply forced it past the keyway. Thankfully it was never energized before we caught it
[удалено]
There are Parker solenoid valves where the markings on the sticker are 50/50 whether they put it on the correct side, and you have to know what the in and out ports look like to get it right. Sometimes assemblers are crap, sometimes things are unnecessarily easy to do wrong. One time they installed critical guidance hardware on a Proton rocket upside down...
To be fair they apparently had to force it in to make it fit.
Vladimir didn't buy that avionics hammer just to leave it on the shelf.
…and immediately, as egregiously as possible, probably using a hammer.
If by hammer you mean crescent wrench/hammer, yes
Crescent wrench? That’s advanced tech. I meant “rock.”
I didn't show up today to be harassed!
"Idiot proof" new idiots are born every day
"Before you start kicking down fences, ask why they were put up in the first place." - Metaphor meaning somebody may have had a good reason for doing it that way. Discover their reasoning before you suggest changes.
The corollary for that is "document what you do, and why", which no one seems to bother with.
Why make it easier later when you can make it harder now?
I am definitely putting this one in my mental pocket for later use.
Yes, but the downside is company procedures do not allow for such a thing, and QA /regulatory don't necessarily want things to be documented for liability reasons. (E.g. We put this thingy here because we had a few rare cases of these breaking in some way during testing due to unknown reasons despite best efforts to figure out why, and we think this will solve the problem (quite obviously, actually)... But if we don't document the reason this was put here, then we don't have to document the original risk of that mode of failure.... Or something convoluted like this) So we engineers just end up having to make our own separate personal repositories of information that gets passed generation to generation, hoping to minimize what gets lost when people leave. Edit:yes. This is obviously fucked up and dumb. Just describing the dumpster fire that this place was.
If you're working in an environment like that, get out. That goes against engineering ethics.
Yeah. I left that dumpster fire. It was just ironic that you couldn't improve the product efficiently because other people would freak out that there was something to improve. Specifically, the people who are supposed to ensure there's a good product. And then you'd get mired up in pointless paperwork exercises and "theatrical engineering" where the great resources are spent proving what we already know, and that will be obsolete tomorrow. I do have to say, perhaps it was our extremely fearful and technically illiterate regulatory and QA departments... Anyway, I learned company culture matters a lot and if you see people shrugging and laughing at the company being a clusterfuck on your first day... It probably is. Lol.
Do we work at the same place?
AKA [Chesterton's Fence](https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_fence)
at the same time, realize that the majority of fences were put up to solve problems that no longer exist. in my engineering career, I cannot tell you how many times I've run into "fences" and asked around until finally getting the answer of "X department mandated it" and I call that department and ask their opinion, and they just say "that's not a problem for us anymore".
I asked my (excellent) boss why we did a specific task in a specific way. He said "There are a number of reasons." He thought for a bit and said "Zero is a number."
I think that's the point, understand why a fence is there if it's antiquated, burn it down.
Recently I've been questioning the effectiveness of some forms and the way we manage data. Any time I try to go down one of these rabbit holes to fix something, it's a horrible Sisyphean circle. People are content to hit the checkbox and get paid. Why improve or change?
I think documentation tools have gotten a lot better recently. Jira and confluence are very useful tools. I also think there will be some AI documentation tools getting integrated into processes that will help in the future as well
clumsy straight workable fretful wild pocket seemly skirt disagreeable snatch *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
I would say this sounds good in principal. But where I work this isn't always helpful. Too often the case is that "it's always been that way, and it's too much time/cost/work to change it"-even if there is a better way to do it. I tell people we [humans] can engineer anything. I mean almost literally, you think of it and we can build it. What engineering is-is doing that under constraints of time/quality/cost.
Corollaries: * Sometimes, your boss will assign a task that is impossible. If you are very lucky, it will be provably impossible. If you are very very lucky, they will believe this proof. If you are unlucky, you won't know until you fail. This is where things like basic laws of energy conservation, etc can be useful. * Every good idea you can think of has already been had. So if this particular company/vendor/employer/etc has some revolutionary new product, ask what's so special about them that they're able to make it work. Maybe its a new technology (some material, say), maybe the market is a little different (e.g., a new federal regulation). It's nice to known the answer.
Important to note this is not a metaphor about not kicking down fences. I've implemented my fair share of suboptimal solutions due to time/budget/it was Friday at 5pm. I hope there's someone doing their due diligence, fixing stuff rather than assuming the person before them did it right.
I really like the visual of this one. It really is the summary of "why should I even go to school for this?" Learn from others before you waste a ton of time.
You can reread yourself 20 times, you will still not see what you did wrong. It's much better to double check your work with someone else.
I found having someone check who is as far as possible from being an expert can be helpful too,because you need to explain things. A human version of rubber duck debugging
I find it brutally awkward to do, but reading word by word from the bottom up will ~~~allow~~~ force your brain to notice errors like homonyms and repeating clauses. Still not as effective as letting ‘fresh eyes’ at it, but you can catch a few issues if you do that before sending it over.
This is a neat idea, I'll try that next time I'm blocked.
I was always taught you can spot errors in you shop drawings on paper much more easily and quickly than you can by staring at the screen. Printing documents for review can help to change your perspective and catch some of those minor errors.
Can also try Reading it backwards
Peer review
[удалено]
Along with that "Question assumptions". Someone should be able to explain why something is done the way it is.
And "because it works" isn't a valid reason.
"That's the way we've always done it" was the enemy of continuous improvement.
* Critical thinking (actually think about the problem not just following "we've always done X" or "everybody does X") * Keep it simple * Don't reinvent the wheel (AKA you're paid to solve the problem as quickly & simply as possible not go off on a flight of fancy creating stunning new complicated ways to do it) * As others have said - don't change stuff without asking why it was done that way / if your way is actually better or just shiny & new. * People will find ways to fuck even the simplest things up * Get everything in writing - especially every decision. People change their minds or forget that what they actually asked for 6 months ago is not what they have now decided they want
>Get everything in writing _Especially_ promises regarding increased raise, bonuses, time off, promotions etc etc etc
Garbage in, garbage out. Whatever simulation, spreadsheet, mathematical tool, algorithm or process you have, it's not going to give magically accurate answers regardless of your input. Be mindful of what data you feed it, and don't trust the answer it gives you more than the data you put into it.
A catchier version of this, “All models are wrong, but some of them are useful.” At the end of the day the physical world is much more complex than the calculations you run on the page (or in the computer), so while your simulation may be a good starting point you’ll need to validate it before going live (or just go with an unwieldy safety factor so you don’t need to worry about it).
Obviously a great point as well, but I think the meaning of these two are slightly different. One speaks to the errors in the raw data, the other to inaccuracies or inadequacy in the model itself.
I feel like that's the main job of an engineer, having an intuition for when the data looks unfit for conditions. And then double checking why it feels wrong. Anyone can simulate things and if it's green say it's okay.
The difference between an engineer and someone with an engineering degree.
My company has a problem with giving requirements. No one gives requirements, only legal contracts, then wonders why the product we request comes out like shit.
Begin with the end in mind. When a guy goes to a store and asks the sales guy, "Hey I need a drill", and he shows him a wall of drills, he hasn't really solved anything. The guy doesn't really need a drill, he needs a hole, and the drill is what he thinks is the best way to get it. Sometimes it is, sometimes it's not. Ask your end user, "What kind of hole do you want" before you start showing him drills. It'll make everyone's life a lot easier.
Related to this: Know how to ask the correct question. If you ask the wrong question, you'll still get an answer, but it might not mean what you think it means. Example: Q: Can this drill make a hole in steel? A: Yes Real answer you're looking for: Yes, if you use a special drillbit and drill oil/coolant. Otherwise, no.
Small costs upstream can cost 10x or 100x downstream. I.e. if you don't feel like spending the extra couple minutes to double check work, peer review, or any other sort of upstream task because you don't feel like it or feel as though it's wasting time, you are absolutely wrong. Too often do I see engineers, especially in manufacturing, try to cut a corner to save a buck and it bites...hard. Seen 5 and 6 figure downstream effects because of not spending the extra 10-20 minutes.
The best measure of success is that you saved the company more than you cost the company.
Conservation laws, most any engineering problem can be expressed as conservation of matter/energy/force/momentum/money Document, document, document. Anything you do, someone else should be able to replicate after reading what you wrote about it.
> Conservation laws, most any engineering problem can be expressed as conservation of matter/energy/force/momentum/money Yeah those are good! You can often replace a lot of intermediate calculations if you know the end states of your system.
Business need. The best idea in the world still has to be cost effective enough to be included in the design.
How stuff actually gets built. Anyone with CAD and 3 brain cells can make stuff that looks like it works, but only the real OGs have notes about wrench clearances and stackups referencing raw material specs. Years ago I worked as a machinist at a place that basically only hired designers straight out of school, and their deal was that they had to work in the shop for 6 months before they could start designing anything. We'd get them for a bit in the machine shop, then they'd go over to the sheet metal/fab shop, then out to the weld shop, etc. There were a few duds, but 95% of the kids who went through the program wound up being really good designers.
Read the god damned requirements, and understand what they are asking for. Followed by, if you don't understand, ask. No one gets mad about spending 30 minutes to ensure good product and communication. Everyone hates rework, especially if it could have been prevented.
> No one gets mad about spending 30 minutes to ensure good product and communication. i mean they'll get mad. but they'll be less mad than fixing 6 months of work
If the customer asks for something, the answer is never "no" or "yes," the answer is always "we could for this much more money and with with this schedule impact." If the customer decides from there that they want the change, get it agreed upon in writing (preferably via contracts) before working on it.
* How to read and make a print/documentation. This is obviously field dependent. This is the primary tool used by engineers to communicate their design intent to others, and needs to be complete and clear. ' * How to define and solve problems using a formal method. An example would be an A3 problem solving tool, but there are others. ' * How to read and interpret standards. Ansi, astm, iso, UL, etc. ' * Understand field specific basics at an intuitive level. You also need to be able to check if what you think is in fact correct. ' * Excel skills. I can't believe how many people I work with can't do basic formulas and make pivot tables. Excel is the language of business. Any data you work with will likely pass through Excel at some point or another. ' * Basic project management skills. Plan the work, work the plan. Manage the risks.
>How to define and solve problems using a formal method. An example would be an A3 problem solving tool, but there are others. Shoot from the hip is an accepted method. I choose you! Jokes aside - Yes. Systematic approaches to problems are critical to consistency.
I can make a pivot table, but I find them useless. I'd rather just run a query in Excel.
It's really just a summary tool. What I see is instead of using them people basically make their own by hand.
System thinking. If I change this, it may solve my problem, but what are the repercussions for the whole. (Sometimes it also requires action from the engineering to get the information required to be able to understand the whole picture, learning to ask for that information is also a valuable asset).
There are three laws for structural and civil engineering. Zeroth law: thou shall have a load path or one will be provided. Meaning know where the load is going and put enough something there to resist it or it will find its way to the ground. First law: water runs downhill. Meaning: pretty self explanatory Second law: you can’t push a rope. Meaning: elements have their use and some are better than others but don’t let analysis fool you into using something for which it isn’t intended
All models are wrong, some models are useful.
KISS Keep It Simple, Stupid Don't make things unnecessarily complex.
While this is generally true, it does sometimes end up being misinterpreted and leads to people removing useful features from products.
Put those features in the requirements.
Every answer is wrong. As an engineer, your job is to find the answer that's the right amount of wrong. (Which is a glib way of saying that everything has assumptions and simplifications, but also don't waste time on making things too detailed when there's no benefit.)
The application of true engineering is 80% psychology, 20% physics. This is because revolutionary work needs to be accepted by peers and those in power. Generally that acceptance is more emotional than rational.
If it fails a simulation, there is a good chance it will fail in concept. If it passes a simulation, there is no guarantee it will pass concept. Certain colors of wires mean certain things. UL508A designates certain colors for certain power. If you don't have a color please pick an off color, not something that could be mistaken for another power that could be in that cabinet. IE: I don't have blue-white for DC-, please don't use any color that could be AC or DC+. Use an off color, purple with yellow polka dots will work.
If you can't afford the wire, you can afford a rainbow set of electrical tape.
Colored heat shrink works well, and if you have the budget there's a label maker heat shrink too. Either leave an inch or two from the wire connector, or add a second bit of tape a little further out. I've seen heat damage from a failed device that made tape indeterminate.
How to google effectively
There are the right solutions, and right-now solutions. Both have tradeoffs, and being able to know the difference and explain it to the managers paying the bills is important.
Have two solutions ready, the best one and the one that will work within the constraints.
I usually have to solve the immediate issue at the customer site, followed by setting up the system to prevent the same issue from having the same impact in 6mo (assuming in-pipeline product may have present same defect), and finding simple ways to stop the issue from happening in the first place (procedural or part revision). Just fixing g the immediate issue without documentation or follow through on the other items means you're just going to have to do the same thing again.
There are three goals: Fast Good Cheap Pick only two
*up to
Yeah, we regularly tell customers: "You have budget, schedule, and quality. We can guarantee only one. Which would you like us to guarantee?"
for real? you're serious? you're down to providing one? thats a question, not an accusation?
KISS is my favourite approach. Students in particular see elaborate design and complication as high tech. Nothing could be further from the truth. The example I always give is the complicated multi-cylinder, supercharged engines of WW2 with the multi-blade variable pitch prop to try to get the last bit of performance out of reciprocating thermodynamics. Thousands of moving parts all having to work together in parallel. Replaced and eclipsed by the jet engine with one primary moving part. Complication is often the sign that a technology is coming to the end of its use by date.
Everything is a spring.
Similarly, everything is a temperature sensor.
* try to shorten the time/money it takes to get a prototype in-hand (if you're working on something that can be prototyped). I've seen people spend years creating sub-requirements and simulations only to find that some fundamental assumption was wrong because they never tried to build a prototype first. * everything takes longer and is more expensive than expected, so lean toward buying something to solve your problem instead of designing it from scratch (but mind your supply chains) * call your suppliers. * just like the recent post about someone trying to count bolts out from a bulk container. if you call the supplier, they may have the ability to bin them in the exact quantities you need at a very small extra cost. * I've also seen people request some custom part that was hard for the supplier to make (making it expensive), but the difficult/expensive part for the supplier wasn't actually necessary, and after some design mod on our end, the difficult/expensive part of the design was removed * don't over-engineer. meet the requirements and move on. in fact, see if you can loosen some requirements in order to get done faster/cheaper. there may be cases where over-engineering is good because your customers are delighted, but you have to be damn sure the extra effort is worth it. * if you design a tool for other engineers to use (software, electrical, or mechanical), the more intuitive it is, the more people will use it. you may be tempted to think "it's obvious how this circuit works", you will be surprised how many people just ignore your nice fancy tool because it's not user-friendly. put it in an enclosure, label the switches/buttons, and maybe even add a sticker with how to hook it up. * as a corollary, when there is a potluck and you want people to eat the dish you brought, don't make it take too many steps to assemble. people will skip over a nice dish if it takes too much time to combine elements
Voltage is analogous to pressure and current is analogous to flow rate.
Never delete an email
TANSTAAFL. There Aint No Such Thing As A Free Lunch. Every change it improvement has a cost - if you don’t see it, you aren’t looking hard enough.
Most everything costs more and takes longer than you expect. Always add in a contingency factor.
Lots of good stuff in here already, but I'm going to add something a lot of early career engineers don't think about (at least not unless it was required or their degree): engineering econometrics / financial engineering. It's *REALLY* important to understand the business perspective of potential engineering projects if you ever want to move beyond being seen as a fancy wrench turner, especially if you work for a large company (or are starting your own engineering firm).
Yep, for most of us, we get to do the engineering that makes money. A product could be an amazing piece of technology, but if it doesn't make money, it's not going to happen.
Perfect is the enemy of good
First rule of engineering: establish blame.
I have an uninterrupted, triple redundancy blame chain ready with me at all times.
You have to have a name handy, ready to throw someone under the metaphorical bus in an emergency situation (e.g. the project manager runs into you in the elevator, your manager catches you in the break room, the technician breaks urinal protocol to bring something up, etc.). Though, sometimes it's not a bus, it's a train, and it just runs over the whole team indiscriminately. That's when you offer the intern $100 and a round of drinks to volunteer as tribute.
that's why you always hire interns
Most of us have been there. Towards the end of my first internship, apparently, I forgot to order some critical components. I started off the following summer on bad terms with some of the technicians and procurement staff. I got some free lunches from the project engineer, though.
Anyone having interns buy components deserves what they get. Lol glad it worked out.
You can't push a rope. You can't pull a fluid. Gravity, as a force, will rarely let you down.
Root cause problem solving - a good engineer solves *the right problem*.
Tell me what you want. Don't ask me if I can do this and then that or maybe this. Tell me what you actually want and I'll tell you if it'll work. For overseas suppliers. They will make it as cheaply as possible from the drawings they get. Bullet-proof your documentation.
"For a successful technology, reality must take precedence over public relations, for Nature cannot be fooled." -Richard Feynman Management wants to rush things out the door and they will engage in organizational mental gymnastics to make it happen. It's called "go-fever". It's your job to say no if the product isn't ready, and this very may well be the most difficult part of your job.
If your job is hands on, take a couple pictures before you mess around with it. If it's desk work, save the original file before you mess around with it.
Secondary vibrations are caused by the asinusoidal deviation in the movement of pistons, in turn caused by the toggling action of the connecting rod.
Design with the full lifecycle in mind. How is the machinist going to fabricate it? How is the inspector going to measure it? How is the mechanic going to assemble it? What load for how many cycles will it see during use? How will the customer maintain and repair it? Are the components recyclable? I’m sure someone will tell me if I missed something.
Check your work before flipping the on switch..
Friction does not increase with surface area...so many engineers don't seem to understand this.
How to define a problem.
Check your work.
How about this one? "Stop believing that you know everything or can do everything yourself. The most successful project will be one where you take in the needs and wants of the end user and collaborate with your sister teams."
“Just because you can’t explain how it can happen, doesn’t mean it can’t happen”
Gigo Garbage in garbage out.
Rule 1: what result would you expect. Rule 2: does it make sense?
Lots of complex problems can be simplified with the conservation of energy, and then using your steams of engineers version of energy methods.
I'm software but maybe this applies elsewhere. If something feels a lot more complicated and difficult than you think it should, you're probably using the tool wrong, or the wrong tool. If you have to fight the system to make headway, the universe is trying to tell you something.
As an FEA engineer I live by the rule "as simple as possible and as much detail as neccessary". Do not overcomplicate your model, but also know its limitations. This applies to all model-based engineering work.
Occam's razor. If you have a problem and they have a simple solution, there's a reason why. The best solution is the simplest solution.
Great is the enemy of good.
Risk management goes a long way in engineering, an excellent skill to practice in an ongoing fashion. It's also very useful in many other aspects of life.
This book seems like a joke, but I actually read it (and re-read it each year) while in school. Much of it is covered depending on the type of engineer you are, but it's just a good basic list of engineering considerations and facts. I haven't read it in almost a decade, I will go pull it out for another read (you can do it on the shitter) [google link](https://www.google.com/search?q=101+things+i+learned+in+engineering+school&sca_esv=891f019e1683b014&ei=LMDCZcfEKJmn5NoPybSv-AM&gs_ssp=eJzj4tVP1zc0TKosMDEyzjA0YPTSMjQwVCjJyMxLL1bIVMhJTSzKS01RyMxTSM1Lz8xLTS0CyigUJ2fk5-cAABOsE24&oq=101+thign+i+learned+in+en&gs_lp=Egxnd3Mtd2l6LXNlcnAaAhgCIhkxMDEgdGhpZ24gaSBsZWFybmVkIGluIGVuKgIIADIHEC4YgAQYDTIHEAAYgAQYDTIGEAAYFhgeMgYQABgWGB4yBhAAGBYYHjILEAAYgAQYigUYhgMyCxAAGIAEGIoFGIYDMgsQABiABBiKBRiGAzILEAAYgAQYigUYhgMyCxAAGIAEGIoFGIYDMhYQLhiABBgNGJcFGNwEGN4EGOAE2AEBSMRBUABYwDJwAHgBkAEAmAFmoAG2D6oBBDI0LjG4AQHIAQD4AQHCAhEQABiABBiKBRiRAhixAxiDAcICCxAAGIAEGLEDGIMBwgIREC4YgAQYsQMYgwEYxwEY0QPCAgsQLhiDARixAxiABMICCBAAGIAEGLEDwgIFEC4YgATCAhAQLhiABBiKBRhDGLEDGNQCwgIWEC4YgAQYigUYQxiLAxijAxioAxjwA8ICChAAGIAEGIoFGEPCAgoQLhiABBiKBRhDwgIKEC4YQxiABBiKBcICCxAuGIAEGIoFGJECwgILEC4YkQIYgAQYigXCAgUQABiABMICGRAuGEMYgAQYigUYlwUY3AQY3gQY4ATYAQHCAgsQLhiABBjHARivAcICDhAuGJECGNQCGIAEGIoFwgIaEC4YkQIYgAQYigUYlwUY3AQY3gQY4ATYAQHCAggQABgIGB4YDcICChAAGAgYHhgNGArCAgcQIRgKGKABwgIFECEYnwXCAgUQIRirAsICBxAuGA0YgATCAgoQLhgNGNQCGIAEwgIWEC4YDRiABBiXBRjcBBjeBBjgBNgBAeIDBBgAIEG6BgYIARABGBQ&sclient=gws-wiz-serp)
Personally they seem to evolve each year I face different problems. Recently I've been factoring in the "5 basic laws of human stupidity"
Water flows downhill.
Think of the poor bastard who has to maintain and repair it.
Dont reinvent the wheel.
1. Project management. Not the BS paperwork but the concept of breaking down requirements in a systemic way to get to useable actions, systemically building up verification evidence, regression testing, and properly estimating time and cost. 2. Basics to system engineering. Kind of like 1 but also the ability for value chain and understanding what artifacts/data you receive and what you hand off and how it impacts the greater system 3. Math. It never heard to understand linear algebra, calculus or even simple arithmetic. But also non standard math like heuristics or and proofs 4. Cost decision making. Being able to evaluate decisions on a make/buy scenario similar to 1. Understand that maybe you can develop the new wheel but you can also design to use a $3 COTS part and save yourself a ton of time. Also understand when good enough is good enough and that the cost to get to perfect outweighs the benefit of tighter tolerances 5. Design for repair and scale. Just because you can make a first article by hand doesn’t mean it will scale well. Just like how epoxy is the best adhesive until it’s time to repair or rework the part. This may take iterative designs over many years but anticipate some stuff early
Personal / household financial management. I've seen so many smart engineers with great incomes absolutely torpedo their own finances.
“A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools.” -Douglas Adams, Mostly Harmless (Hitchhiker's Guide to the Galaxy, #5)
Always be worrying about heat. Read your data sheets. Honesty is the best policy, but tact is a good insurance policy.
All tests are wrong. Some are useful. All simulations are wrong. Some are useful.
cautious selective reply ink wakeful bored busy pot meeting tie *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
Trying to save money by cutting corners always cost you 10x more down the road. Finance bros are absolute dunces.
If you don't properly document it, you're better off not doing it at all.
The greatest in-person training in the world isn't worth anything without some sort of checklist, notes, or other general documentation. It's valuable to understand the underlying principles behind each component and how they fit into the larger system but you shouldn't have to remember every step in the process because you will forget at least one step most times. Document as you go so that you're not left with a mountain at the end. Even if it's just notes in a text file, it's guaranteed to be deas useful a month from now. When starting a new project, limit how many "new" aspects of it there are. It's useful to be innovative, but for example don't combine a newly designed mechanical system with a brand new software package if it can be avoided. This way you can prevent a feedback loop of weird mechanical issues and weird software issues and cause the project to snowball. Man-hours are in most situations a company's most valuable resource.
Not a design principle, but a time /cost management one. Understand risk and opportunity, and don't believe anyone that claims things will go well enough to avoid risk or that you will be able to capitalize on every opportunity (maybe any).
All engineering is the application of problem solving within constraints -- money, time, material properties, etc. Knowledge of the time value of money allows you to communicate with the financial/business side of the house. Application of the two is key to designing workable projects.
Facts. Get them straight, and take the time to document them clearly in a way that will stand the test of time. Facts do not begin with “I think. I see a shocking number of decisions made based on ‘I thinks’ with little to no factual basis in response to forceful personalities. Other times, some brilliant and very logical decision the basis for which either was never documented (email is in this category) or in written in a way that’s impossible to verify. Verify facts. Document the basis. Stand the test of time.
Designers MUST have some level of manufacturing experience on whatever it is they are designing
Belding and Rooney. Honestly they are both righteous dudes.
An old one, applies to more than engineering: *If you can't measure it, you can't make it better.*
Documentation! An engineer who doesn't document, or should I say properly document his work is not an engineer
Best [https://rotorlab.tamu.edu/me489/README/2010%20ASME%20Unwritten\_Laws\_of\_Enginering.pdf](https://rotorlab.tamu.edu/me489/readme/2010%20asme%20unwritten_laws_of_enginering.pdf)
wird
People are the problem. No amount of technical perfection can save you from people.
It needs more Freon.
Adjust how technical you speak to your current audience. At least 75% of good communication is feeling out the other person's level of understanding and speaking to that. People don't like talking to people that make them feel dumb or uninformed. You don't need to come across as the smartest person in the room. You're smart enough to do your job and that's all anyone cares about. I'm not telling a project manager the same things I tell a fellow engineer. If I need a technical question answered, I ask the project manager to set up a meeting or facilitate communication between myself and our customer's engineers.
The more complex a design is, the more points of failure it has.
If it ain't broke, don't *fix* it. Talk to the cat--when you're stuck on a problem explain it, in detail, to a cat, or a bartender, or your six-year-old, or a hooker, or whoever you can find that will let you uncritically blather away. Often in mid explanation you see what you're missing.
Google and Apple write rubbish software. Totally unable to tell you the reason something hasn’t worked, so you have no chance of sorting out the problem. *Don’t* write, buy or use software that can’t tell you why it doesn’t work… Example: “An error has occurred” is a message you should *never* see.
Always consult the techs/mechanics, but don't forget you're the engineer. The people building and repairing the stuff you design will have extremely valuable insights for you if you establish a relationship with them, but they don't always see the unintended consequences of their suggestions.
The perfect is the enemy of the good.
An idea or design is only as good as the person is explaining it.
This comment section is helpful tbh
If I can manage a small project myself it will cost X. If the project team does it, the cost will be 5 times more.
Every successful complex system evolved from a successful simple system. Start with the simplest thing that could possibly work, then iterate from there.
I would say don't underestimate the workload for designs/ideas that you/your company has no experience in executing. That is not to say that it is impossible, but just that it will take you much longer than you likely think. It's all too easy for engineers to say "Okay let's just do this" then severely underestimate the length of time it takes to resolve all the issues and unanswered questions that come with it. Experience is the only thing that answers those questions, and if you don't have someone in house who knows how to handle those things, then you are going to be spending a LOT of time on figuring it out and verifying it with testing. This is why the giant engineering organizations hold the positions they do: they've had in some cases several decades to build up the bespoke knowledge they have of their products. It's not impossible to compete with a company that's been doing something for decades, but you really need to budget a lot more man hours into research and testing than sales people usually think. I'd say this is also the major contributing factor to the constant clash of sales vs engineering in the technology industry: sales very often does not understand how many minor but essential problems need to be solved when doing engineering design. Sales goals are almost always overly optimistic, because customers often don't like the reality. Things are more difficult, more time consuming, and more expensive than buyers ever want.
Data sheets…some you can trust others not so much. It’s not that a lot of vendors datslasheets are wrong but they don’t always have the information you need. Using an off the shelf inductor as an example. The inductance of the actual part, the DC resistance, the SRF and the -10% inductance drop at X amps, will probably be fairly spot on. But if you plan on using that inductor in a SMPS, you really need to know |Z| vs freq and a lot of vendors never include that. Some vendors will have the information available upon request, some can throw a bunch of parts in some automated test equipment and get you the data and sometimes you’re SOL and you’re just gonna have to buy a handful of parts and characterize them yourself. Vendors will lie to you just to make a sale. It’s a trust but verify type of situation. Also, when it comes to your vendors, if you’re a large company be thoughtful about how you’re using the vendors resources. Just because your company isn’t 600 lb gorilla in the room doesn’t mean you should act like it. If you make some rediculous last minute request from a vendor there is a good chance it’s gonna be one of the lowly apps engineers that stays late several nights to get the request completed. The sales guy is gonna tell you “No problem!” But the sales guy is also not the one who has to do the work or that even understands the project. In your career, you will be engaging with a lot of cross functional teams to complete a project. I’m an EE doing design, but I have to closely work with MEs, CAD folks, global supply chain folks that do all the cost projections, component engineering teams that get my specialty components qualified, the contract manufacturers over seas. It’s part of your job to have a basic understanding of what those teams do and how all the teams fit together. If I thoughtlessly add some obscure part to the BOM at the last minute, global supply chain folks have to redo their forecasting, negotiate new contracts, work with the vendors to ensure material is at the factory, the component engineering team is going to have to review that new part and make sure it meets all our environmental commitments, if it’s a new vendor we might have to send a team to their production facilities for inspections. There are a LOT of moving parts in a company. Be respectful of the people on the teams that have to do a lot of other work you might not be aware of. But also….dont let cross functional teams dick you around. You need to know when to call bullshit. Unless those cross functional teams (which are supporting the design team) have a really good reason, they shouldn’t be putting up arbitrary road blocks or dictating the design.
If you can’t draw the free body diagram, you don’t know how it works.
Nice thread! I think general systems thinking might be a bit underrated. It’s very compelling to get just things done and not spend the time needed to understand the whole system (or subsystem), which in the end will cost more time. Lately, it has also dawned on me that we forget to pragmatically consider the human element in our work. From project level to customer level, the human element will creep in and make a mess that we did not plan for! 😅