Mixing
How can I successfully change job fields?
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
8
down vote
favorite
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.
software-industry new-job motivation
edited Sep 7 '12 at 21:42
gnat
3,23273066
asked Aug 29 '12 at 3:33
jingli
1,13531430
add a comment |Â
up vote
8
down vote
favorite
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.
software-industry new-job motivation
edited Sep 7 '12 at 21:42
gnat
3,23273066
asked Aug 29 '12 at 3:33
jingli
1,13531430
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 '12 at 6:43
add a comment |Â
up vote
8
down vote
favorite
up vote
8
down vote
favorite
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.
software-industry new-job motivation
edited Sep 7 '12 at 21:42
gnat
3,23273066
asked Aug 29 '12 at 3:33
jingli
1,13531430
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.
software-industry new-job motivation
edited Sep 7 '12 at 21:42
gnat
3,23273066
asked Aug 29 '12 at 3:33
jingli
1,13531430
edited Sep 7 '12 at 21:42
gnat
3,23273066
edited Sep 7 '12 at 21:42
gnat
3,23273066
edited Sep 7 '12 at 21:42
gnat
3,23273066
3,23273066
asked Aug 29 '12 at 3:33
jingli
1,13531430
asked Aug 29 '12 at 3:33
jingli
1,13531430
asked Aug 29 '12 at 3:33
jingli
1,13531430
1,13531430
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 '12 at 6:43
add a comment |Â
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 '12 at 6:43
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 '12 at 6:43
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 '12 at 6:43
add a comment |Â
4 Answers
4
active
oldest
votes
up vote
4
down vote
accepted
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.
edited Sep 7 '12 at 21:46
gnat
3,23273066
answered Aug 29 '12 at 16:09
HLGEM
133k25227489
add a comment |Â
up vote
6
down vote
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.
answered Aug 29 '12 at 3:47
swapnesh
1,2841928
add a comment |Â
up vote
3
down vote
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?
- What is a multiply-accumulate operation?
- What is a PID controller?
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.
answered Aug 29 '12 at 18:10
Karl Bielefeldt
10.5k31830
add a comment |Â
up vote
2
down vote
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.
answered Aug 29 '12 at 20:48
bethlakshmi
70.4k4136277
add a comment |Â
StackExchange.ready(function ()
$("#show-editor-button input, #show-editor-button button").click(function ()
var showEditor = function()
$("#show-editor-button").hide();
$("#post-form").removeClass("dno");
StackExchange.editor.finallyInit();
;
var useFancy = $(this).data('confirm-use-fancy');
if(useFancy == 'True')
var popupTitle = $(this).data('confirm-fancy-title');
var popupBody = $(this).data('confirm-fancy-body');
var popupAccept = $(this).data('confirm-fancy-accept-button');
$(this).loadPopup(
url: '/post/self-answer-popup',
loaded: function(popup)
var pTitle = $(popup).find('h2');
var pBody = $(popup).find('.popup-body');
var pSubmit = $(popup).find('.popup-submit');
pTitle.text(popupTitle);
pBody.html(popupBody);
pSubmit.val(popupAccept).click(showEditor);
)
else
var confirmText = $(this).data('confirm-text');
if (confirmText ? confirm(confirmText) : true)
showEditor();
);
);
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
4
down vote
accepted
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.
edited Sep 7 '12 at 21:46
gnat
3,23273066
answered Aug 29 '12 at 16:09
HLGEM
133k25227489
add a comment |Â
up vote
4
down vote
accepted
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.
edited Sep 7 '12 at 21:46
gnat
3,23273066
answered Aug 29 '12 at 16:09
HLGEM
133k25227489
add a comment |Â
up vote
4
down vote
accepted
up vote
4
down vote
accepted
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.
edited Sep 7 '12 at 21:46
gnat
3,23273066
answered Aug 29 '12 at 16:09
HLGEM
133k25227489
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.
edited Sep 7 '12 at 21:46
gnat
3,23273066
answered Aug 29 '12 at 16:09
HLGEM
133k25227489
edited Sep 7 '12 at 21:46
gnat
3,23273066
edited Sep 7 '12 at 21:46
gnat
3,23273066
edited Sep 7 '12 at 21:46
gnat
3,23273066
3,23273066
answered Aug 29 '12 at 16:09
HLGEM
133k25227489
answered Aug 29 '12 at 16:09
HLGEM
133k25227489
answered Aug 29 '12 at 16:09
HLGEM
133k25227489
133k25227489
add a comment |Â
add a comment |Â
up vote
6
down vote
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.
answered Aug 29 '12 at 3:47
swapnesh
1,2841928
add a comment |Â
up vote
6
down vote
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.
answered Aug 29 '12 at 3:47
swapnesh
1,2841928
add a comment |Â
up vote
6
down vote
up vote
6
down vote
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.
answered Aug 29 '12 at 3:47
swapnesh
1,2841928
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.
answered Aug 29 '12 at 3:47
swapnesh
1,2841928
answered Aug 29 '12 at 3:47
swapnesh
1,2841928
answered Aug 29 '12 at 3:47
swapnesh
1,2841928
answered Aug 29 '12 at 3:47
swapnesh
1,2841928
1,2841928
add a comment |Â
add a comment |Â
up vote
3
down vote
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?
- What is a multiply-accumulate operation?
- What is a PID controller?
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.
answered Aug 29 '12 at 18:10
Karl Bielefeldt
10.5k31830
add a comment |Â
up vote
3
down vote
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?
- What is a multiply-accumulate operation?
- What is a PID controller?
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.
answered Aug 29 '12 at 18:10
Karl Bielefeldt
10.5k31830
add a comment |Â
up vote
3
down vote
up vote
3
down vote
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?
- What is a multiply-accumulate operation?
- What is a PID controller?
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.
answered Aug 29 '12 at 18:10
Karl Bielefeldt
10.5k31830
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?
- What is a multiply-accumulate operation?
- What is a PID controller?
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.
answered Aug 29 '12 at 18:10
Karl Bielefeldt
10.5k31830
answered Aug 29 '12 at 18:10
Karl Bielefeldt
10.5k31830
answered Aug 29 '12 at 18:10
Karl Bielefeldt
10.5k31830
answered Aug 29 '12 at 18:10
Karl Bielefeldt
10.5k31830
10.5k31830
add a comment |Â
add a comment |Â
up vote
2
down vote
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.
answered Aug 29 '12 at 20:48
bethlakshmi
70.4k4136277
add a comment |Â
up vote
2
down vote
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.
answered Aug 29 '12 at 20:48
bethlakshmi
70.4k4136277
add a comment |Â
up vote
2
down vote
up vote
2
down vote
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.
answered Aug 29 '12 at 20:48
bethlakshmi
70.4k4136277
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.
answered Aug 29 '12 at 20:48
bethlakshmi
70.4k4136277
answered Aug 29 '12 at 20:48
bethlakshmi
70.4k4136277
answered Aug 29 '12 at 20:48
bethlakshmi
70.4k4136277
answered Aug 29 '12 at 20:48
bethlakshmi
70.4k4136277
70.4k4136277
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f3539%2fhow-can-i-successfully-change-job-fields%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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 '12 at 6:43