I'm assuming the lockfile should be checked into the repo itself, which presents a bootstrapping problem if you have to run an action to create the lockfile in the first place. They may need to build proper support for running actions locally -- there is the third-party https://github.com/nektos/act tool which might be a starting point, but that's mostly designed so you can debug actions without having to repeatedly push and rerun. Probably they'll need a separate mechanism to statically analyze actions without running them.
> That points to a deficiency in the “composition over inheritance” aphorism: those aren’t the only two games in town. If you have procedures as first-class types (like blocks in Smalltalk, or lambdas in many languages), then you might prefer those over composition or inheritance.
First-class procedures/functions are a form of composition. Requiring a function type behaves like requiring an interface/class type with only one method. (In languages like F#, `Func<_,_>` is literally defined internally as an abstract class with one method, `Invoke`, although there are other mechanisms to auto-inline lambdas when enough static information is available to do so.) In either case, you can place it into a field of an object or data structure, or pass it directly as an argument to a function/method.
High school, at least as far as it serves as a sorting mechanism for top students, follows a kind of Parkinson's law: the number of hoops to jump through increases until it reaches the natural limit of how little sleep the top students can handle.
There were rumblings that my high school, which had plenty of AP classes already, was about to introduce a combination AP/IB curriculum, which absolutely terrified us. I and my AP-taking classmates breathed a huge sigh of relief when it was announced that it would be delayed, and the students in the year below us would be the guinea pigs. They would have to run twice as fast just to stay in place.
Indeed. In my time, it wasn't uncommon to have 6 AP classes a semester along with at least one time-intensive extracurricular. Assuming each class is the equivalent of 3 credit hours, it's the equivalent of an above average number of classes in college (15 being the expected amount, 12 being the minimum to be a full-time student, and 18 considered intensive) while playing a competitive sport.
The best part: Even a decade ago, the above was considered neccesary but not sufficient for admission to a top school. Plenty of people with perfect to near-perfect college entrance exams, Intel International Science and Engineering Fair finalists, etc didn't make the cut. Of the few that did, the majority were the lower Ivy's (Dartmouth and Brown).
There is a book called “Seven checkmarks” in Dutch that argues that succes in the Netherlands is strongly correlated to seven checkmarks to have: male, highly educated parents, white, certain type of elite high school, university educated and one more. Having all the marks, having generally underperformed academically and still coming out on top comparatively I feel there might be some truth in it. It would signal a quite stratified society with a “ruler class” inside a society that thinks of itself as classless for the last 60 years at least. (It’s pretty hard to reason about this being while being under scrutiny.)
Why post this? After reading your comment I thought wouldn’t want to live there or raise children there. But the second thought was, wait - that’s meritocracy in action. Imperfect meritocracy as you point out, but it might still be more equitable not than having seven checkmarks and generally faring worse than those born under a different star. My Rawlsian self thinks grit should be rewarded more than birth, even though testing for grit would probably massively increase burnout.
Thinking even further, I don’t think that societies with “high grit” (Korea, US) are generally considered to treat their children and general society very equitable. Still mentally debating if there is a very socialist argument growing inside of me. That book (read it three months ago) does make me think a lot. It was the first time something ‘near-woke’ made me think so hard. The book mentions the reflective point as well - might I only take it that seriously because it was written by someone from the same “class”? Foundational stuff.
It's difficult to relate this to modern perspectives on software design and architecture because the running example is hard to comprehend. It seems to be an interface to a data structure that may have been useful in certain applications in the context of hardware constraints 50 years ago. It would be great if somebody published an implementation of this example with the variations in C for illustration.
I disagree, I just left a company in which most teams 'modularized' their code in the way Parnas describes as not ideal. What Parnas describes are low level modules that are now mostly provided by languages, but the same applies to 'business' modules. In the org I left, minor changes in a microservice had wildly unexpected consequences due to a mix of lack of information hiding coupled with large data objects. One example: storing a debit in an account would become a credit when loaded back under some circumstances.
The mentality of most developers there was: How can I make the change described in the ticket by touching as little existing code as possible?
Except C is quite a poor example for how to use modules.
TU with opaque pointers can be used for such purposes, and they are, but still fail short of Modula-2, Mesa, CLU and UCSD Pascal, to cite contemporary examples.
Modules either have types as part of their interface, or haven't. I C, the declarations shipped in the interface header represent the interface, and the types declared in it are public types.
C also supports symbols with internal linkage.
What exactly is missing?
> module initialization/shutdown,
What's wrong with initializing objects? Languages such as Rust also rely on factory methods to instantiate objects.
> linking with type checking,
The interface headers define the symbols, which must correspond to the symbols handled by the linker. What's missing?
> namespaces.
That definitely C doesn't support as a first class citizen, but this is nothing that symbol prefixes don't handle.
To me, the most amazing thing is that he says that it is a problem that would take the average programmer a week back then, but today it could probably be coded in 5 minutes in AWK or Perl.
> Is Casey assuming the entire commercial software industry === Uncle Bob?
It's uncharitable to take Casey as making absolute blanket statements like that, but still, it would not be unreasonable for him to single out Uncle Bob in particular.
The Amazon rankings for Bob Martin's "Clean Code":
Best Sellers Rank: #5,338 in Books (See Top 100 in Books)
I think this trend is why they've gone all-in on sex-on-the-beach shows and true crime docuseries. One season can easily be self-contained, and if the viewer gets another, it's just a nice bonus.
Which is disappointing, because there is stuff out there like Wonderfalls - the writers from the beginning understood the premise was so weird that they wrote the first season as self-contained, just in case it was canceled. And it was. And because of how they wrote it, it still works as a one-off thing to watch even now.
As somebody trying to get into mechanical engineering while living in a small urban apartment, this has been an incredible resource... not that I've made much progress along the lines it describes though.
It's tough to plan a path toward growth in these skills without sustaining inordinate expenses at each step. I can't afford to become afflicted with Gear Acquisition Syndrome. I've come close to dropping huge sums of cash on tools before discovering, at the last minute, critical reasons that they could not do what I need for the designs I have in mind. Maybe I'll visit a makerspace? Ah, but every one in my area appears to have gone defunct since Covid year zero.
So the journey up to this point has been:
- A lot of reading: not just faffing around with hobbyist blogspam -- full-on MechE textbooks, learning what really goes into engineering schematic diagrams, all that good stuff
- Getting back up to speed with the pencil-on-paper geometry and math skills I've lost after years of doing all my intellectual work in digital form (at least I can still draw a freehand circle)
- Proto-proto-prototyping: just making some physical objects roughly of the same geometry as what I've designed -- whittling them out of wood, sculpting them out of polymer clay
- Hacking together janky tools: trying to make a crappy mini lathe out of Meccano-clone parts, trying to make a crappy mini lathe out of an electric drill, just to get a basic feel for what's involved
- Apologizing to my wife for all this weird scary stuff in the corner of the apartment
I was a CS major. The only hands-on physical engineering I did in college was cooking a single-transistor chip in a freshman applied physics lab. Basically I feel like someone who has studied everything about the physics of bicycles but has never ridden one. I'm really struggling on how to proceed.
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...
> 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.
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.
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.
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.
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.
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.
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.
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.
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?
>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.
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.
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.
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..
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.
I really appreciate the recommendations. I have enough knowledge of the field to understand that control engineering and vibrational modes are extremely important but not enough to know what's most important to know about them or which books are more reliable or better written.
What do you think about Reuleaux's Kinematics of Machinery and the Machinery's Handbook?
I don't have experience with your kinematics book, and have some limited exposure to machinery's handbook. My impression of the latter is that it is good and highly regarded, but perhaps more on the Practical fabrication side then engineering Theory.
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.
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.
> 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.
> 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.
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.
Take a woodworking class at your community college.
Focus on the serious fundamentals first. I mean like how to hammer a nail into a thing, how to screw things together. Learn the difference between nut+bolt, Truss Head screws, and pan-head screws. Learn when to use each of these things.
Visit Home Depot. Build a damn coffee table.
Focus on the fundamentals. CNC Mill comes after all this IMO on the hierarchy of knowledge. You really should be extremely familiar with fasteners (Glue vs Nuts+Bolts vs Screws vs Nails) before you start designing things that get glued/screwed/snapped together.
--------------
Most things are left unsaid because just building a damn coffee table (or similarly simple / small object) is everything you need to know about beginner level mechanical engineering.
Finding a class (community college) with this basic level of skills really is the bulk of it. Once you've accomplished the basics, it becomes obvious how to use a CNC Mill or 3d printer or whatever these electronic tools are.
Woodworking was also my gateway into CNC and machining metal. The most important lesson it taught me was that every manufacturing process has a system of tools around it. One tool is almost never enough to build anything of quality. Early on, I was very interested in the charm and ingenuity of individual tools. After learning more and working in the field, I realized that building sophisticated things is all about the integration of tool systems into stable, predictable processes. A holistic approach is necessary.
There's a 18 part video series by Dan Gelbart I can recommend where he goes over how to prototype products using a laser cutter and a hydraulic press. If I was setting up a home shop, I'd start there. I have very good access to CNC milling and turning machines, but usually find it cost and time prohibitive to go that route, preferring to laser cut/3D print wherever possible.
https://www.google.com/url?sa=t&source=web&rct=j&url=https:/...
Urban apartment, I'd stick to electronics, pcb, soldering, code.
You want meche career change, just go work in a local cnc machine shop that runs Fusion 360. Then you can have unlimited access to all the tools you could ever want. If you want to be a good designer, I'll sell you my book once it's written.
> Maybe I'll visit a makerspace? Ah, but every one in my area appears to have gone defunct since Covid year zero.
Yes. I miss TechShop, where I did CNC machining. It's not all that difficult. Maybe 100-200 hours to minimal competence.
What's left of the maker movement seems to have been taken over by little old ladies into crafting. Gluing construction paper and macrame, not machining and welding. Activities classes for middle schoolers where they assemble kits, not original work. In the early days of TechShop, it was people making rocket engine nozzles for the X-Prize, and people who commuted to Shenzhen to get their stuff made in volume. Four Bridgeport mills, all going at once.
The problem is that none of them are what I would call "cheap" anymore.
> Activities classes for middle schoolers where they assemble kits, not original work.
Don't look down on this. Assembling an electronics kit is what got a LOT of us greybeards into electronics. Debugging something you put together is non-trivial.
We now have a couple in my city of 300k people, I go for blacksmithing and welding (have to soon to finish something for family that lies there since November...). Or if I need some heavy woodworking machinery, luckily I have quite a bit of smaller machines at home, most of which inheritence of my late grandfather. Time permitting, I like manual work like that, good counterbalance to an otherwise typical office job.
> As somebody trying to get into mechanical engineering
As a career? I'll assume "yes".
Go to college for ME. Not one of the big brand-name schools. The local one that services the regional mechanical engineering industry. Tell them you want a career change. If you're serious about it, they'll bend over backwards to make it as feasible as they can. They'll also be brutally honest about whether you've collectively reached the point of feasibility yet.
I'm saying this as someone who is very outspokenly critical of universities as unnecessary gatekeepers.
A question to answer: is the enjoyment coming from actually being the machinist, or is it coming from assembling something you designed? The answer could be either. But if you just want to bring something you designed to physical fruition and you are limited on space then I would recommend finding machine shops that will make what you design for you. This is what Protolabs, Shapeways, Xometry, etc do. You don't need to actually have a 3D printer or laser cutter or CNC mill to get things built. You can probably find a local fabricator too. I found a guy that made handrails and would do random welding jobs, I used to go to his shop for all sorts of different things. Even if you get the money and space to build out a shop, there's a lot of skill to these crafts and people dedicate their whole career to becoming experts in them.
The goal is the end product, yes. But there's joy to be had in getting there. And more importantly, I know I won't be able to achieve it without a good feedback loop for iterating on my designs, which means doing at least some machining on my own.
For one thing, sketching out variations on a design typically reveals there's a wide space of possible parameters in the spec. In many cases it's obvious that only a small subset will actually be technically feasible (either for machining or for reasonable functionality of the finished artifact or both), but not obvious exactly what that subset will be.
I'm not even talking about what could be revealed by finite element analysis or other formal methods (though I'm not averse to learning those too). I mean the feel, the taste, and the intuition I can't get from just drawing and doing the math. Like Jackie Stewart said, "You don't have to be an engineer to be be a racing driver, but you do have to have Mechanical Sympathy." I have mechanical sympathy for computing systems, for rapidly narrowing down appropriate design spaces in software projects, but I don't yet have mechanical sympathy for mechanical systems.
Similar position here. CS major who went to work software / FAANG pretty much for my 30 year career.
Something about mechanical engineering feels amazing, unlike software getting real tangible /physical/ results from your work. I feel the CS experience gives a very distinct advantage as well here. Software and CAD isn't scary for a CS brain. CnC (additive and subtractive) seems like logical way to do everything, which is what makes cool parts for projects.
I've acquired a few cheap Harbor Freight welders and oxy/acetylene cutting tools, started with small CnC routers to carve soft metals for parts. 3d print what I can't do in metal.
One really easy area to get into for a software dev is robots, look into RoS, an open source robotics OS based on Linux, order some parts from the RoS wiki. And you can get to your own advanced little r2d2 pretty quickly (real-time 3d mapping of your house, arm with gripper control, voice control, image recognition in real time) - most of the software pieces that ME might struggle with are not so difficult for CS folks, and it enables some really cool results!
Hey man, actual Mech-E here. Also general mechanical hobbyist and handyman; not just one of those CAD guys
Just some quick things that may help you point you in the right direction. This is coming the "small scale hobbyist", not indusdrual profesional viewpoint:
-getting better and making actual projects come to fruition is actually a lot like CS. A lot. Somebody can spend all their time reading CS theory, textbooks, MITOWC, whatever. Their technical foundation will be strong, but will struggle when it comes to coding syntax and spesific program/firmware issues. Some get stuck in that mode and are paralyzed to take action
I'd honestly recommend dropping the mech-E textbooks to read just for reading's sake. It will fill you with generic knowledge but not a better builder. Instead I'd be thinking about "what do I want to build"? Kitchen knives? Custom pens? Automotive mods? It does not need to be something you make forever. Just something that seems fun now (just like the pet CS video game project)
Just like CS hacking (in the PG sense), THEN you will start to look up how it's done. Kitchen knives need metal forging? Okay, now its time to look up edu material for that. What tools are needed? Can I custom-make tools to get them cheaper? What edu material is out there for that… rinse and repeat
...just remember 2 things. 1, safety first. 2, a pretty drawing means nothing if you can't manufacture it to your desired specs
-honestly, drafting or 3D modelling, it's all fine. What's important is what allows you to implement your ideas and record them fastest. Also, right tools for the right job
I made a bench for my balcony. Just rough, imprecise measurements, knowing I'd make ad-hoc cuts to size when I had my material
For extreme lightweighted, funtion-over-form stuff or geometrically sensitive stuff, ya, CAD or FEA software will be needed
Just use whatever is appropriate and will allow you to achieve the results you want. Honestly, if you're not making F1 parts, drafting or CAD is fine
-your proto-prototyping is GREAT. This is exactly how you get started into this. Try something out on a small scale, see where you could improve with tooling, materials, methods and process, try again. Want to make a bronze casting? Try plaster casting first. You say you're lost, but you are ahead of 99% of people in all the damn makerspaces or home hobbyists. Trust me :)
-janky tools. Beautiful. For things that don't need to hit specifications (like firm +/- tolerances), this is one of my favourite things to do. I made an air extraction unit with a thrift shop electric leaf blower motor and some scrap hvac conduit. This is a crucially important skill IMO, as mechanical things get expensive. This allows you to go MUCH further with the money invested to try things out
-collecting weird stuff? Get some plastic bins. Lol. Out of sight out of mind
And last tip? When things around you break, try to fix them. That really starts to add to your "mechanical intuition". I'm pretty familiar with hvac, plumbing, general indusdrial fastners, air and fluid power systems. Next time your sink clogs up, don't call the plumber right off the bat. Explore tutorial videos to see if you would be comfortable doing it (and no problem of you're not; i am not with electronics). But at least you start to get very familiar with standard tools, parts, designs, etc. It's almost uncanny how similar many product classes are
Mech eng here as well. This advice is great. I work in a high tech firm, prototyping through in-house production. Stuff breaks and we fix it. We make prototypes with the wrong parts, the wrong tools. We do our design, send out parts for machining, and often end up fixing stuff by hand because of a design oversight (it happens, it's prototyping, not production).
I find when people outside the "handy" diciplines (factory operations, industrial setting eng, skilled trades), they think mfg and engineered components are much more elegant than they really are
Perhaps things like apple, F1, dyson and defence distort that view. They do make their products with "spaceship" technologies. But it's critical to understand they are the exception, not the norm... plus... the treasuries and workforce they can utilize to pull it off
It's hilarious how products like Yeti, cammelback, premium razors are just permutation of very simple products (not knocking them one bit and great marketing). x2 the quality of standard products for x4 the price (and often that's just fine)
Usually products start out a little jank just like software. Red bull and lululemon come to mind. Start small leveraging available things, start local markets, scale from there. Just like FB with Harvard students
High voltage and radiation equipment here. Our products are sleek, or prototypes you literally would not touch with a 10ft pole. Jank is part of the game. If we can run a bunch of sketchy tests for $100s to find a path forward, and do pre production on the order of $1k to $10k, we might justify that $100k purchase down the track. On the other hand, we might find our own method that means the $100k solution is never required. We fail fast when we can and learn what we can.
There are stacks of subsystems that can be tested quickly, janky, yet safely. Safety is always paramount, but a relative term. Safe for an end user, and safe for a prototype engineering test need not be comparable. Similar safety, for sure, similar longevity, ease of use etc., potentially very different.
For tests on prototype subsystems like a cooling system? Totally fair game
Live full production systems? Usually no one will be willing to risk the OSHA or ISO violations where critical failure affects safety. Or, if they do, that company won't last long
Also, to add on to the reading comment - keep an eye out for old (40's->70's in particular) technical books and manuals on topics that interest you. I find they had a way of conveying information that was somewhat lost once video became commonplace.
fixing stuff will teach you everything! i didnt even mean to learn so much about so many topics, but knowing that i could fix it just kinda made it happen. and its mostly fun, when its not incredibly rage inducing lol
I have to get this out of my system. No, your YLOD on your PS3 is most likely not caused by the tokins capacitors, it is the solder bumps on your RSX GPU silicon die. You can't fix those cost effectively, just get a replacement RSX.
Also, reballing the BGA solder balls doesn't fix the solder bumps inside the RSX.
Absolutely. It's like viewing the source code of a launched CS product and become familiar all the python libraries they used
You start to hit the next threshold when you start to become a mad-max salvager. Fan motor controller is broken but the motor is fine? Salvage the motor, chuck the rest!
Whats your goal/motivation? How to proceed would depend a lot on that. Tinkering as a hobby? Making something physical? Understand how things are made? Prototyping an idea for commercialisation? Career change?
It's not exactly an easy read -- whenever I recommend it to someone I also warn them that it contains the most passive sentence in the history of the English language: "Information obtained by a member of group A about the compiler resulting from the further modification of it after about 10 years made it clear that at that later stage the original powerful structure was still visible, but made entirely ineffective by amorphous additions of many different kinds."
Think about all the places you've ever worked, all the organizations you've been part of, where you know how the sausage is actually made, and how that differs from the way the organization portrays itself.
Now think about all the other organizations in the world, whose internal workings you're not privy to.
reply