[totemandtoken]

I was a mechanical engineer before I shifted to software development (so kind of the opposite of you) and I think you need actual, full on college level schooling to be a mechanical engineer in most cases.

The stuff you're focusing on - basically manufacturing techniques - is a very small part of engineering in general. I didn't see any mention of CAD or FEA work, but even assuming you do know some of that or can access that type of learning you still are missing a lot of what makes an engineer an engineer.

The biggest difference I see between software developers and mechanical engineers is a way of thinking. I realize that sounds very woo, but it's very obvious to me and to other mechanical engineers I've spoken to.

For example, around my area there are schools that give out "Mechanical Engineering Technologist" degrees, which are quicker, less math intensive engineering degrees. Often times speaking to METs, I notice how they don't see connections between certain phenomenon or see why certain physical phenomenon happen in one circumstance but not another.

This isn't to discourage you. I think one very easy step you could do if you haven't already is pick up Fusion360 (it's free for hobbyists I believe) and try to simulate making a simple project. I would hesitate in calling this "mechanical engineering" but I think it would get you along in your goals.

Sorry for the long rambling message, the interplay between software and traditional engineering is something I think about quite a bit...

[DanTheManPR]

> The biggest difference I see between software developers and mechanical engineers is a way of thinking. I realize that sounds very woo, but it's very obvious to me and to other mechanical engineers I've spoken to.

As a fellow trained ME, yes, it seems obvious to me as well. A good school and program will have you spending several years in intensive study and thought about the fundamentals and wider implications of the physical principles and mathematics of machines and systems. If you can then follow that up with a few years of good hands-on professional experience with the subject of your study, it's going to give you a level of insight into the workings of the physical world that is difficult to achieve just through direct experience.

Which is not to say that you can't succeed in manufacturing without an engineering degree. It's pretty common for experienced machinists/welders/etc. to break out of a career cul-de-sac and go into business for themselves and engage in some effective and knowledgeable engineering in the process.

But there's no shortcut. You either do the schooling, or you earn the experience. Otherwise, you're not even going to be realizing the mistakes you're making.

[nick889996544]

I think mechanical engineers require or develop a more pragmatic attitude. Do-overs in the mechanical realm are often more time consuming or expensive than those in software. And practical experience comes with a lot of learning.

[DanTheManPR]

Beyond the expense and time, mistakes can also be very dangerous. I take a lot of pride in designing industrial machines that are not only effective at their task, but safe to build and operate. The products that I've had a hand in are touched by a lot of people, and it's my responsibility to make sure that the energies being transformed by the machine are not unleashed in ways that are harmful to people. Laziness or lack of care on my part will get people hurt.

[hef19898]

Fully agree. Even if I am not a full mechanical engineer I am an industrial one by training. And over half of my studies was equivalent to what the mechanical engineers did as well. And somehow that affects how think about the world and stuff, engineering thinking of sorts.

I am im supply chain management now, and compared to others in thay domain that are really good SCMs but not engineers, thinking like an engineer makes things easier sometimes.

I also agree on using the old hands on the shop floor when it comes to manufacturing and machining parts, engineering / design for manufacturing is something a lot of engineers struggle with. Also goes for maintenance and what not. And the good engineers listen carefully to that kind of feed-backband actually search it. This was one something my profs pointed out to us all the time as being an important part of our future jobs. Obviously, some people are better at that then others.

[digdugdirk]

I'd actually suggest a slightly different tact. The initial commenter seemed to want to learn how to make things. To me, that sounds like they want to be a skilled machinist (in the general sense) instead of a ME.

Some of the most brilliant people I've ever met are gruff old dudes in a machine shop. They don't use CAD because they can hold an entire design in their head. You ask them about a change to a part, and they tell you why three other parts need to be modified if you want to make that change.

These "old school" types (in my experience) actually have a deeper understanding for the interplay of physical phenomena in a design. They might not know the specifics of the underlying reasoning for said phenomena, but they can absolutely tell you what the outcome will be and how to avoid it.

How'd they get started? Apprenticeships, usually. But how did they get good? They made stuff. A lot of stuff. Eventually you'll get good at it.

Just keep doing what you're doing. And wear your PPE. And try not to chop any fingers off.

[switchbak]

I read this as the OP was wanting to dip their toe into "making", not to do some self-directed learning such that they'd call themselves a MechE. Schooling would be great of course, but if your goals are very modest, I think what the OP has in mind might be fine too.

It'd be like telling someone fooling with Python that they need to take a full CS degree otherwise they'll fail to appreciate the beautiful mathematical underpinnings of functional programming. That might be true, but that's also not the goal.

Edit: clarification

[DalekBaldwin]

Yes, I was implying "to do stuff like the author of the article does" ( https://lcamtuf.coredump.cx/rstory/ ), coming from a very similar situation as him -- as a software engineer with an already broad general scientific and technical background, in a small apartment, getting into the concrete particulars of designing and building cool mechanical projects on a small scale and budget.

[totemandtoken]

I mean, the last few lines I wrote still stand if that's what you want to do. I would learn some CAD software, download a few files and try to cnc or 3D print something. Even in that link, I saw a screenshot of some CAD software.

I personally use a Sainsmart 3020. It's relatively cheap and pretty small. For my goals, it gets what I want done. I used to have an Ender 3 Pro for 3D printing but had to give that up. If you want to get into the business of manually using a lathe or something, more power to you, but why when we live in an era of desktop manufacture? But regardless of what equipment you use, you need something that can inspect, possibly edit, and transfer the design file to the equipment i.e. CAD.

[cpp_frog]

Can I ask you a couple of questions? I am in a patricular situation, I'm a mathematician who does FEM and I think my training has been too abstract. My most recent work involves programming custom code in C++ for the study of buckling of thin shells (finite element method, continuum mechanics, differential geometry of shells, and all under the umbrella of functional analysis). Still the region I live in has virtually no relevant positions for FEA, which prompts me to ask:

(1) I've been thinking of getting a certification in ANSYS or Abaqus (it's relatively cheap). Would it help if I get some certs, or would it be enough to have expertise in several open source finite element programs? - think deal.ii, PETSc, MFEM, MOOSE, FreeFEM, FEniCS and the like. I really like to use the latter because apart from being free, they give me more freedom and I can use them with parallel computing on UNIX machines.

(2) Regarding manufacturing and machines/machining, any book or resources that stood out? I'm most familiar with the Machinery's Handbook.

(3) For design, did you use a tablet? I've been looking into buying one and use it for design, preferably with FOSS. Any recs?

Thank you for your comments,

M.

[s1artibartfast]

>Regarding manufacturing and machines/machining, any book or resources that stood out? I'm most familiar with the Machinery's Handbook.

I went to a top tier school for MechE and Materials, and would recommend two intro books: Engineering Mechanics Statics by Meriam and Kriage and Shigley's Mechanical engineering Design in that order . If you fully understand the contents of these book, it probably puts you in the top 10% of mechanical engineering graduates.

For a broader education, you can read Fundamentals of Heat and Mass transfer by Incropera, DeWitt, Bergmann & Lavine as well as Fundamentals of Fluid Mechanics by Munson, Young & Okiishi.

Understanding these two books will probably as well will probably put you in the top 1% of grads.

If you have a strong background in mathematics, these mostly deal with applications of linear algebra and differentials, so the value is understanding the applications.

From there, you can branch out. If applicable, Ogata's Modern Control Engineering and Tongu's Principles of vibration

Most undergraduates dont really understand these due to the heavy application of Laplace and Fourier transforms, but are relevant if you want to build complex machines.

[digdugdirk]

Excellent overview. I'd also add "Marks' Standard Handbook for Mechanical Engineers" to the front of the list. Its a great way to dip your toe into the breadth of the field and will serve as a nice reference book on your shelf later if you keep going with it.

[buescher]

I started down the path to be a materials scientist and wound up in embedded hardware, so take my opinions with a big grain of salt.

For self-learning, I don't know if anyone would work through the problems in a statics textbook. Shigley looks good. Thanks for that recommendation.

For heat transfer, I eventually wound up on the bibliography from Hot Air Rises and Heat Sinks by Tony Kordyban, which is more focused on cooling electronics. I have Holman's Heat Transfer on my shelf as a result and I can recommend it for self-learning. One big advantage to Holman: he shows how to set up common thermal problems in Excel in an appendix. I would consider recommending a good continuum mechanics book in the place of a fluid mechanics book - I liked Yuan-Cheng Fung's First Course in Continuum Mechanics but I haven't looked at it or anything else in its domain for a while.

Ogata is a good controls text. I don't know if any of them are good for self-learning. I tried and had to take a class to wrap my head around feedback control. Tongue looks interesting. Thanks for the recommendation.

[kragen]

Kraige?

[s1artibartfast]

It is a really simple book and not particularly academic, but you have to start somewhere.

It is basically the equivalent of a picture book, with 200 pages of free body diagrams, which may be helpful to someone if they aren't used to thinking in terms of beams, forces, and moments.

The entire books' contents is probably covered in pages of Shigley's, and perhaps for some people that is enough..

[kragen]

I mean, you meant "Kraige" rather than "Kriage", right? I wasn't deprecating the book.

[s1artibartfast]

Ah yes, it was hard for me to tell the difference even reading the spellings side by side.

That said, it is definitely the weakest of the suggestions. The rest are serious books that a professional might refer back to. On the other hand you should really never need to refer back to a statics text, and it could be switched out for any number of options.

[Prcmaker]

If you can get access to student or lite versions of some FEA software, start using them. I've found few places have cared about my software certifications, and more than I can adjust to their software package of choice. Some places will have higher requirements, but not all.

Machinery handbook rocks, but it is far from perfect. It's great for machining, it doesn't cover all of mechanical engineering. I've leaned hard on Roarks formula handbook through my career. A materials reference book goes a long way too. More recently referring frequently to degarmos manufacturing book.

I've used a cheap-ish Windows laptop for almost all of my research and design. CAD can suffer as assemblies get large, I turn fancy rendering off as it is mechanical engineering, not making prettying renders. FEA can eat resources fast. I've pushed to a beefier desktop as required. I've done some CAD on a tablet, but I hate the form factor for it.

[HeyLaughingBoy]

> Regarding manufacturing and machines/machining

There's an MIT course on OpenCourseware that's called (roughly) "How to make (almost) anything" and also "FUNdamentals of Machine Design." (or something like that!) I think they're by Richard (?) Slocum. I started a long time ago and cherry picked the parts I cared about. Slocum's writing is very entertaining and he's easy to follow along with.

As you can tell, my memory isn't that great :-)

[iancmceachern]

For #2 check out the YouTube series "the secret life of components"

[naasking]

> The biggest difference I see between software developers and mechanical engineers is a way of thinking. I realize that sounds very woo, but it's very obvious to me and to other mechanical engineers I've spoken to.

I'd say it depends whether the software engineer learned core computer science. That's maths heavy and teaches you equational reasoning, which similar to the skills used in solving systems of equations that govern physical systems.

[Rokid]

> The biggest difference I see between software developers and mechanical engineers is a way of thinking.

Can you give an example? Myself being a mechanical engineer who also turned to software development, the people I talk to from SW are used to dealing with large matrices and semi-complex math. Sure they don't know about modal analysis or Navier–Stokes equations, but the lack of a certain way of thinking I cannot recognize.

[totemandtoken]

As the other comment and a few others have iterated, software guys don't have as much of a "measure twice, cut once" mentality. It's not so much about the math or technical knowledge, it's more of a mentality.

Let me put it this way - I've seen many times software engineers laugh when they encounter a funny bug or an output they didn't expect. I don't think I've ever seen an ME laugh when something breaks.

[Rokid]

Ah now I see what you mean, and I fully agree :)

[nick889996544]

(I'm not the parent commenter) in my opinion more along the lines of thinking behind "move fast and break things" vs "measure twice cut once".