If you make a career of robotics, you will come in contact with a lot of languages, a lot of libraries, and a lot of systems.
The more you know about the fundamentals, the easier it will be to adjust to something new. Likewise, if you focus your learning on whatever project or context is relevant to you at any given moment, it's more likely to stick with you.
In general if you learn only what you need to do the project in front of you, and then take a small amount of time to drill down and understand something about the foundation of what you are doing, you will constantly be leveling up in your robotics knowledge.
Since you're coming from a ME background, I'll assume you are interested in the hardware side of things as well as software.
You should have a basic knowledge of algorithms and numerical analysis. You should know for which calculations you computer will give you erroneous results and how to mitigate them.
You should know that each language has it's own idioms. Many of which come in to, and go out of, fashion with each passing decade. So you need to take the extra step of learning the appropriate idiom for whatever algorithm you are using if you want others to be able to collaborate with you.
You should understand that microcontrollers, processors, homogeneous multi-processor architectures, and heterogeneous multi-processor architectures all require different approaches for solving the same equation or problem. I think it's easiest to start with a microcontroller like an 8 bit Atmel AVR (Arduino's use these), then ARM, x86, GPU's, (maybe OpenCL), and finally distributed systems (ROS middleware is one, limited, example). It all comes down to computation speed vs communication speed vs problem granularity. FPGA's are another style of computing you should know about. Software runs on hardware and roboticists often need to select the right hardware for their software.
You should learn a bit about the internals of operating systems. Start with a small one, preferably a real-time one. They tend to be more modular and digestable. Then dig into at least one big one, Linux or Windows for instance. Learn what an OS does to actually load and run a program, and how to inspect and manage processes.
You should learn a bit about IPC and middleware. It's kind of silly to use ROS if you don't know which situations it's bad for.
You should learn at least one full C/C++ toolchain on the command line. Command lines are more similar across operating systems than graphical environments or IDEs. Most languages and toolchains will touch or interface somehow with a C/C++ one in one way on another.
C is still the dominant low-level language, and C++ is often used in computation intensive (robotics) code. You should know that C and C++ are different languages and that there are different versions.
For C, it's worth reading old code, before the advent of java, when men were men and pointers were an elegant weapon of a more civilized age. The idioms of the time (1980 +/-) led to clear and clean code.
For C++, my favorite robotics code to read is Simbody.
Know that there are different programming paradigms. Learning functional programming is very useful. It's the best/fastest approach for some problems. You can use functional programming in imperative languages, and you can torture your CS friends using imperative programming in a functional language.
There is more that can go in this list. Beyond pointing out that C/C++ is used a lot, I did not recommend languages or libraries or frameworks on purpose. I've learned and used 10's of each, and will continue to learn them on an as needed basis.
This knowledge is fun to apply but its real power is when you are working and interfacing with domain experts. The same way you might use your tribology knowledge figure out what type of bearing to use and specify what you need for a custom one to be made, you can use the above knowledge to read through the kernels of the different physics engines Gazebo can interface with and choose one appropriate for the scenario your are trying to simulate.
Don't stress too much. Be pragmatic. Learn what you need to for the project at hand and then learn a little bit of the foundation or why of what you are doing.