The one thing about programming (whether pure software or related also to hardware) is that programming is something like the easiest seeming hard activity known to humanity. There's something like a natural illusion in the human mind which makes people believe that changing XYZ in a program is easy, just because it is easy to imagine what it would be like to have the change or just because the program itself is just "brain stuff". Even the programmer himself/herself, after a couple days rest will feel the pull, the plausibility of the argument that change Y should be easy even when the torture of making change X is still weighing on him/her.
Every course I took in the CS, applied math, or EE departments required us to, you know, actually do something. In my POSIX programming class, we wrote lots of programs (malloc, web proxies, and so on). In my graphics class, we wrote renderers (while paper tests covered the algebra of geometry). In my PDE classes, we wrote simulation code in Matlab and saw it run on wave and heat equations.
In mech, though, scarcely any classes had an experimental component. Fluids? Nope. Heat transfer? Negative, barring a baking orb lab and a Reynold's number lab. Machine design? Hah, fat chance--a 25 page report on a fucking bolt was the capstone assignment (alternately, a failure analysis on a gear tooth that chipped in a transmission). Control systems? A few tedious labs more suited to padding out a grad student's paper on teaching engineering than actually, you know, teaching us anything.
The height of this nonsense was a mandatory lab on power generation--one in which we finally got to run a steam powerplant! Except we didn't, and were given the results to run our analysis on instead. Sitting in the campus pub afterwards and grousing into my beer, a facilities guy from the central plant expressed surprise--they'd specifically made sure to have steam run out to make that lab happen. The lab was cancelled because that steam wasn't available, nominally--more likely, the student running it was looking for a way out.
The only good labs we had were an industrial processes lab (machining, welding, and so on), and a strength of materials lab (tension, torsion, and whatnot).
I guarantee that at the end of four years any of our CS or EE kids were substantially better coders--I cannot claim the same for the mechanical engineers I graduated with.
Our final design project was our one true chance to show that we could actually build something, and for many teams that too resulted in failure.
The problem with so much of this is that there are perfectly good ways these things could be taught. Machine design could have you, you know, actually manufacture some cams or build gearboxes. Heat transfer could have you build heat sinks, manage fluid flows, or create exchangers. Control systems could have you build robots or invert pendulums or do any other damn fool cool thing that requires signal transforms.
It's just such a goddamn disappoint.
It's expensive though. A lot of times students have to go fundraise to pay for their projects. My annual donation to the university is now earmarked specifically for supplies for a couple of undergrad DBT courses.
I'd encourage you to get back in touch with your old department and give them your above feedback, I'm sure they'd love to hear from you.
My school definitely focused on practical skill more than yours, with 4 design projects (one was a paper only project) over the course of our degree. We also had a course that was just mechanical engineering labs which covered topics like fluids and heat transfer. Even in courses like Machine Design, the focus was somewhat on design, with all the assignments being miniature design projects where you had to specify real components and justify your choices to the instructor and class. Still students graduated with essentially no practical engineering skills.
You have to take it upon yourself to get the practical experience in your area of interest, be it through co-op jobs and/or student teams. If you don't, the job market is not interested in you.
I think there is going to be some changes coming to traditional engineering education relatively soon. My local professional association seems to be pushing to make the schooling more practical, though nothing major has come of it, just a couple of smaller course changes.
This is why student engineering team projects exist. Solar Car, Formula SAE, Human-Powered Helicopter etc. Also, most mechanical engineering jobs are in fact not hands-on, are not "design this radically new machine" (more like "tweak this design so it meets slightly different requirements"), and certainly not turning a lathe (that's for technicians/machinists). Putting more design experience into an ME curriculum means taking out some of the analysis/theory (it takes a long time to build stuff, that's why engineering and manufacturing are separate departments), which is a disservice to the students heading toward pure research and academia.
I wonder if including things like "turning a lathe" would benefit engineering students. They could in theory design a part to accomplish a certain task (maybe design a fan blade that's unconventional) and analyze it, compare with how it is traditionally done, and so forth.
Either way, one of the best feelings in engineering for me is go draw a 3D rendering for a class and watch it show up as something I can hold in my hand 2 weeks later. No amount of deploying/pushing/launching in software can ever beat that, yet.
Embedded development offers this gratification.
I feel like I'm missing a huge amount of electronics knowledge as soon as I see a discussion about how such and such a trace has been misplaced on a revision of a board or how certain pins could have been better used as an extra SD card reader (ref: the Udoo board)
Is there a less time-intensive way to pick up an understanding of hardware (I'm currently a software guy) than to go an do an ME or EE? I'm certainly not looking for an easy way out but at the moment it feels like trying to go from crawling to supersonic flight.
Going even farther back up the chain there's stuff like this:
Choose a board and see how much mileage you can get out of it.
For the lowest level nuts and bolts, Horowitz and Hill's _Art of Electronics_ is still a classic. Going through the first few chapter exercises will get you thinking in terms of voltages and currents.
I think I'll go back to a breadboard for a while - Art of Electronics looks like what I need right now.
Edit: Egads! $150AUD for that book
In fact, that brings up an idea for a way that hardware is sometimes easier than software. The laws of physics that constrain our designs don't go obsolete every 2 weeks.
That said, if our tuition is north of a hundred grand (as mine was), one wonders that that expense cannot be borne by the institution.
Even building simple structures and predicting their failure would be a worthwhile endeavor.
At least that is my impression.
It sounds like many of these schools do a poor job... which means it's even more important for motivated students to seek out opportunities outside the classroom. College is (largely) what you make of it, not what the default curriculum spoon feeds you.
When I do programming stuff, a large fraction of the time is spent debugging because my program crashed.
I cannot afford my hardware project "crashing" as that may permanently damage a part and thereby pushing back when i can complete the project by a long time (gotta wait for manufacturing). Sometimes I simply don't have the extra money to buy the replacement.. and this is assuming I have the cash to make the first part after I designed it..
Now I know if you're motivated enough you could do this, but when all of these factors combine (time delay in getting parts, destroyed parts, lack of funds), you lose momentum fairly quickly.
The alternative is that you could be right the first time by doing calculations, simulations, what have you. But that means you need a deep understanding of a lot of things to begin with, which is what you're trying to gain.
Incidentally... I'm a hardware engineer. I built large mobile manipulating robots during gradschool, and I routinely build electronics projects at home. I'm well aware of "hardware problems" (and software bugs that cause real physical damage).
To address your comment: learning how to do the fabrication and hardware debugging yourself is a key part of engineering physical goods. Digital fabrication is nice, but it's not the end-all be-all. For robot fabrication, you can't beat cardboard prototyping, 3D printers, laser cutters, drill press, and table saws. For circuit boards, I routinely use a hot-air rework, exacto knifes (to cut traces), and header breakouts for debugging. Nothing ever works the first time. That's why you learn how to design in a way that facilitates debugging. (All of this is so much more approachable with neighborhood hackerspaces / TechShops.)
EDIT: I have no idea how students of "big" engineering go about getting hands-on experience. Building a bridge is a bit different from robotics and electronics. I presume it has many sub-specialties. I suppose this makes coops and internships even more important.
That's stark reality. Nowadays they have too much spherical cow in MechEng curriculum. But that said, you're free to spend your time on internship...
However that is still quite limited given what we learn.
Regardless of whether a system is software or hardware: simple systems are easy, complex systems are hard.
The more complexity, points of interaction and levels of abstraction you add to either type of system the more difficult it becomes for any single person to keep track of it all.
Designing a simple LED light circuit is easy, designing a modern CPU is hard.
This is exactly the oversimplification these posts intended to disprove. The complexity of an airplane or rocket, measured in terms of design components or interacting subsystems or what have you, is miniscule compared to any piece of software that could be written with the same budget. An even more extreme example would be science: after 6 years, the complexity of a PhD's discoveries is microscopic next to the complexity of software that he/she could have written (or did write) in the same time.
The amount of functional complexity achievable per effort invested varies dramatically between fields based on the time and cost of iteration, the time, cost, and power of relevant diagnostic tools, and the availability of domain-specific knowledge.
It's an important fact to keep in mind when judging someone else's work or deciding to switch occupations/markets/fields.
While I suspect that this is probably true. I still would like to pose the question... Are they? Or is it simply because we don't know it, it then seem easy?
Anything in the real world both incurs significant logistical cost as well as many points of unpredictable failure. I've seen thermocouples rated to 1100C catch fire when they hit 600C. Designing a new part for a new idea for a mechanical subsystem can take weeks to make, cost $1000+ easily, and might not work due to very easy to make errors.
So maybe the way to say it is that the abstraction barriers put around non-software parts of a system make them appear less complex, but what we're really saying is that the complexity inside of the box that we're dealing with is smaller.
I think what's happening here is that you know and respect the amount of effort that goes into rocketry and your mind is inferring a level of complexity that matches. Effort(times)skill is one correct way to judge the magnitude of a project, but I argue that complexity of the product bears little relation to either effort(times)skill or the project's success.
Rocketry was a bad example because the scale of a typical rocketry project is so large that dividing by cost (or effort(times)skill) becomes critical to making the comparison.
TL;DR : Sure. MechEng seems easy.
Hardware is hard because one must work within the constraints of reality, software is easy because almost anything imaginable is possible.
Both are fair viewpoints.
Hardware design (in HDLs for example) is very much like software development. There may be a very large number of lines of code (resulting in a very large number of transistors on the chip). Just like a language like C++ that can have many intricacies, the hardware can have many issues that are sometimes hard to nail down during design and simulation.
When thinking that anything imaginable is possible in software while comparing it to hardware, you must keep in mind that the software is ultimately running on the hardware. Anything imaginable is possible still.
-currently working in the aerospace industry
Rarely, but sometimes, i'll encounter a problem and troubleshoot it, and each time I find a bug and fix it, it turns out it was completely unrelated to my problem. Looking hard at the code just makes potential bugs pop up that I hadn't seen before.
It's cases like these that made me realize the iterative software development model of write, test, debug, repeat, was a huge waste of time. If I actually review all my code I catch bugs quicker.
Similar to what the OP is saying, the engineer realized that human powered flight wasn't the problem he was solving, but the process of failing fast and iterating.
The original article says: everyone settled down for a crapy simulation software and implementations are terrible.
so, the conclusion of this piece "there is no way to realistic improve" is way off. Maybe he should get at least a couple years under the belt before trying becoming a pundit.
Its a completely different way to think about things when you can push an update versus doing an expensive manufacturing run.
The lack of funding however... :\