I'm in a very similar position: I graduated a couple years ago with a MechE bachelor's but now work as a research engineer in a marine robotics lab, including w

I'm in a very similar position: I graduated a couple years ago with a MechE bachelor's but now work as a research engineer in a marine robotics lab, including writing a bunch of code. There's a few of recommendations I'd make: 1) Use Linux in your day-to-day life, and do as much in the command-line as possible. There's no substitute for bash, especially in robotics when you're working with embedded Linux systems all the time. You'll quickly pick up commands you like, and from that scripting things will really help build some experience and give you a good "sandbox" to play in. 2) Most robotics systems end up either being immensely complex, or simpler than you think. Most of the complex systems aren't the same ones used in the rest of the world, since with the exception of self-driving cars and now the NVIDIA Jetson computers, you don't have enough compute to run the complicated stuff. Raw C++ code will probably run fast enough. As a result, a lot of the stuff-you-use-for-web-apps-that-you-might-have-to-scale-to-millions-of-people won't come into play. Instead, doing things like setting static IP addresses or debugging a serial port connection pop up a lot more. 3) Software has a nasty habit of getting complicated sooner than you'd like. As others have mentioned, testing is really, really important. Whatever your preferred language is, I'd suggest you spend a lot of time figuring out your preference for how to easily and repeatedly ask "does this do what I think it does". Unit tests help a lot, as do. Without trying to shove it down your throat, this is one of the reasons why I do a lot of coding in Rust--the package manager and its unit test tooling is all built in and makes checking my assumptions much easier. 4) Probably avoid a bunch of posts written on either LinkedIn, and to a lesser degree, Medium. I'm sure you've seen it in other areas, but coding in particular seems really prone to have pieces written by people whose main goal is to show that they did something, not teach other people how or explain the nitty-gritty you'll need. On the other hand, some people's personal blogs are gold, and I suggest you figure out a way of saving good content in a way that lets you find it again. 5) And finally, try to find some places where you'll feel comfortable asking questions. Some languages or frameworks have forums, other have sub-reddits, others still have Discord/Zulip/etc. chats. It can save you a huge headache to say "hey, I tried doing this thing, I'm stuck here, here's a well-written explanation of everything and my code in a Github repo, plz help".