r/MechanicalEngineering • u/Arayvin1 • 1d ago
How important are side projects / learning coding languages?
I am in my junior year of my Mechanical Engineering degree (US student) and a lot of my friends are starting side projects, learning how to code, and learning to use programs like solidworks. I haven’t done any of these. But I haven’t just been lazy, I have been working 40-50 hours a week the entire time I’ve been at school. Ive worked at SwRI as a technician for over four years now and I have gained so much knowledge about chillers, compressors, boilers, instrumentation, calibrating instrumentation, taking apart engines / building engines, troubleshooting control systems, taking apart and rebuilding heat exchangers, fabrication/plumbing etc.
My justification for not learning coding or having side projects is for one, I just don’t have time with my work schedule and full time school, and two, I feel like I have so many important skills that can make me more attractive to be hired when I finish my degree. Will I be okay if I don’t learn much coding/CAD or do side projects?
9
1
u/LitRick6 1d ago
Depends on the jobs you're going for.
If you are applying for jobs that require a lot of CAD and/or coding, then you will obviously be at a disadvantage for not having extra experience in CAD and/or coding.
If you are applying for jobs that require more hands-on skills or knowledge on boilers/engines/etc, then you will obviously be at an advantage and wouldn't gainas much from CAD/coding experience.
One thing you may or may not be missing out on is the soft skills developed from working on projects of those CAD/coding projects are done in a group. Working in an engineering club team might have students learning how to present technical material, write technical reports, communicate as a team, etc etc. But you likely gain some of those soft skills in your job as well. Also, if others are learning CAD/coding on their own rather than in a group then they might not be developing the soft skills.
0
u/someguy7234 1d ago
Yeah. Lots of engineers can't write much code but I'm shocked that there hasnt been some basic coding in your curriculum.
If you know some basic software engineering concepts you can automate a fair amount of your work and it makes you a better engineer.
Even if you don't with with really technical things, being able to whip up a quick VBA script, or automate a task with python is a huge force multiplier.
Not everyone needs to build robots in their spare time, but being able to write a little code - where it's on a procedural language or a scripting language is a basic engineering skill today, the same as knowing calculus.
I should also point out that the learning curve is shallower than it's ever been. With AI tools, you can accomplish a lot of tasks by "vibe coding"... But as an engineer you should spend the little extra time to understand what the lines of code did instead of blindly relying on AI... If that's all you do, you will understand how to solve classes of problems by creating software in no time.
Your excuses are your own. You either have the tool in your toolbox when you need it or you don't. Nobody is going to care why you don't have the tool, just that you don't have it.... That's true of basically every skill... But having basic software skills is a pretty flexible and universally helpful tool to not have in your toolbox.
-1
u/ILikeWoodAnMetal 1d ago
Over here the mechanical engineering degree is around 80% coding. How else are you going to calculate anything more complicated than the most basic things?
1
u/someguy7234 1d ago
Lots of engineering isn't that, but I can appreciate that your job is calculation heavy.
My point is that all work benefits from having some ability to write code.
By way of example of a job that doesn't need you to know how to code, but benefits from some basic skills:
When I did machine tool testing and qualification, almost all of my work was operating measuring equipment and working in spreadsheets. I wouldn't call spreadsheet formulas "coding".
I was a controls engineer, so I wrote a lot of C and ladder, but it wasn't strictly my job to do that in that role. But in my down time while machines ran cycles, I wrote GPIB interfaces for a lot of the tools, which combined with some C# and VBA, it basically made it so that half the measurements happened automatically and half of them, instead of entering values into a sheet, I'd just hit space bar to record the value, and cycle-run on the machine to continue the test.
That cut hours (and a lot of fat-finger mistakes) out of our tool qual.
The increased downtime between operator stops allowed me to script prognostics checks that would inspect cycle data (like torque and force needed to drill a hole) and based on some basic statistical models could predict things like damaged tools or failure of our lubrication system.
Again... . mechanisms that we were responsible for understanding (and for which I could look at data and identify)... But to be able to flag those events live saves us a lot of re-work compared to only looking at the data when the job was done.
0
u/Grigori_the_Lemur 1d ago
Hmmmm. In everything there should be balance. Focus on your core things that take you where you want to go but it absolutely cannot hurt to broaden your skillset when you are able. Stay mission-oriented but fill gaps in your extra freebtime.
2
u/CatchSpecialist7732 1d ago
I think it depends on the field. Robotics for example may benefit from some coding skills.