I have made a career change from IT software developer to software developer in mechatronics. Though I am familiar and confident with the programming aspect of the job scope, I am not yet completely familiar with the mechanical system especially and also some of the electrical systems.

My managers know I am new to this field and have given the first month to get used to the machines and the environment and to read the documentation. Mostly I am concentrating on learning. I know the best idea is to learn the unknown things quickly by asking my superiors and quzzing myself. But sometimes, when I see the things I do not know, I become demotivated. How can I be successful and motivated in this situation?

You can take this as a generic question, though what I have asked here is a specific domain related question.

  • Buy you a small present every time you accomplish something hard. And when you're finished, buy something big and celebrate! Next time, thanks to inertia of mind, you'll treat the learning process as something pleasant
    – superM
    Aug 29, 2012 at 6:43

4 Answers 4


Being motivated is overrated. You can and should do your job whether you feel motivated or not. So don't let it stop you because you feel unmotivated when you don't know something. That is just an excuse.

I've switched careers several times. The key to successful career switching is to:

  • Talk to people about what you don't know and in what order you need to learn things. Then make a plan prioritizing the learning.
  • Find out the sources of information that you need to learn what you need to learn. Know your own learning style and seek out the best resources for that style.
  • Observe others while they learn and work with them directly if you can early on. During the observation phase, write down any questions you have about what the person did. Ask them after the task was finished if you are just observing. When you ask questions, you not only want to know the how but the why. Look for key phrases to tell you there is more to know, things like "well most of the time we do..." Ok that tells you there are exceptions, so now ask about the exceptions, how you identify them and what you do when they happen. Look for decision points and how they are handled through all branches of the decisions.
  • Dig in with small tasks as soon as humanly possible. You will learn more from doing than reading or asking questions.
  • Now what is critical about starting doing the unfamiliar work is that you ask someone who is competent in the field to review your work before you finalize it. Luckily you are in the programming field, so you can ask for a code review even if they don't do this as a standard practice.
  • Don't get upset if they find that you are doing something wrong and ask you to change it. You are learning, you should expect that you won't get everything right the first time. Even if you are upset, do not let the other person know it. You want them to have a positive impression of you and you need them to be willing to help you learn. So don't get huffy or snotty or whiny. Attitude is critical to job success but even more so as you change careers.
  • Don't expect to get the biggest, most interesting tasks while you are learning. In fact, ask for some of the tasks that people are not particularly found of doing to start with. Your goal is to make yourself useful as early as you can and taking away some of the drudge work is one way to do that. And you can learn a surprising amount from that work too.
  • Ask questions, but learn from what you asked and don't ask the same thing repeatedly. Be aware that helping you is taking time away from someone else's day and be mindful of their time. So try to look things up first before you ask. And ask the right people. If you are assigned a mentor, you know who to ask; otherwise, ask your boss directly who you should address questions about XYZ to. If possible, get him to introduce you to that person and tell them that he has asked you to come to him for advice. Many programmers in particular hate to be interrupted, so make sure you set up a time for asking questions. Then stick to that unless the question is a showstopper on a task you have to complete that day.
  • Take notes. If there is little or no documentation, take the time to create it as you learn. It will help solidify your learning and may help the next new person. If there is documentation, still take notes. You learn more from reading and writing notes than just from reading.

I pre assume that you are not the only person in the company that switched from a different domain, so first find out those persons in your group/company who previously have gone through the same phase and discuss the things/problem with them, that how they tackle the situation and what are the hurdles you are going to face during your learning process. Talk to your senior officials as well making them feel that you are actually paying your serious efforts to grasp the concepts as soon as possible and best of luck with your new career.


The trick to not getting overwhelmed is to not try to learn everything at once. Start with what you know and slowly build on it. Write down questions in deeper and deeper detail. Keep notes so you can explore details without risking losing the big picture.

For myself, knowing almost nothing about mechatronics, I would start something like this:

  • Web search says it deals a lot with actuators
    • What specific actuators does our company use?
    • What do I need to know in order not to hurt myself with an actuator, keep it from catching fire, etc.?
    • Who's the best person to answer my questions about actuators?
    • Where is the written documentation?
    • Where is the code?
      • How do I write the "hello, world" of actuators?
      • How does the code actually talk to the hardware?
        • What's a CAN bus?
      • How does the code enforce real time constraints?
      • How does the code deal with sensor noise, manufacturing tolerances, etc.?
        • What is a PID controller?
          • How do I tune one correctly?
          • How do I determine my sampling rate?
          • How do I implement a PID controller?
            • What is a multiply-accumulate operation?
              • How do I tell the software to do one?
The order you answer the questions is up to you, but the point is to decompose the questions until they are bite-sized enough for you to understand, then to combine the answers back into the big picture. If you don't have enough background knowledge to answer yet, either dig deeper until you do, or get the general idea and make a note to come back to it later.


As my career has continued, I've enjoyed being able to mix work I know how to do with trying new things. For example, I find that testing is often an easier place to start than adding a new feature, because in testing something, I get to learn how it works. So I'll volunteer to do very guided tests, so I can learn and yet contribute. Then, where I can, I'll offer to optimize things that are problem domain independant, for example, automating test scripts.

Also - rather than irritate myself and those around me by asking questions constantly, I'll write myself a question list as I read. Then I can prioritize and ask a bunch of questions at once. I make up goals like finding 10 good questions, and then getting answers - so I can feel sucessful, even while learning.

Also - I mark sucess as the progressive difficulty of answering my questions - I like to know I can move from the obvious quetsions that are easy to answer to ones that take some thought and time to explain, so I can know I'm getting deeper into the area. Looking for signs that my questions are thoughtful and intelligent motivates me because it tells me that I'm starting to pick up on the nuances of the work.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .