Should I train a colleague to move to a new role despite my reservations? [closed]

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;







up vote
0
down vote

favorite












OK, so this is likely to be part-rant, part-question.



I've never encountered this kind of situation before, so I figured there might be someone out there with some useful advice.



Background: in our department, as in most IT departments, we have analysts and developers. Analysts liase with the business, produce initial specs; developers write code to implement the specs.



The department is divided into small functional teams, with a few analysts and a few developers on each team.



Recruitment is handled by the department overall. There is one recruitment track for incoming developers (with interviews handled by senior developers), and one for incoming analysts.



Around six months ago, we had a guy apply to be a developer. He failed the interview (to be clear, he was interviewed by someone else, not me).



A couple of months later, he then applied to be an analyst. He passed this interview, with different interviewers, and started on our team as a senior analyst (so he is fairly well paid).



Pretty much since the day he started, he talked about how "he wanted to get into development".



From what I've seen (and I've worked fairly closely with him), development is a poor fit for his skills.

He isn't too keen on detail, and he doesn't have a great deal of relevant experience.



He is, however, a good enough analyst. He's built a good relationship with our stakeholders, and he has enough of an overview that he can be effective in his current role.



Our company is very keen that everyone should have a Personal Development Plan, and that the Plan should be followed up.
Our new starter, obviously, seized on this, and made "getting into software development" the core of his Plan.



Our team leader does not have a technical background, but has approved his Plan and asked me to support him in moving into development.
I feel quite conflicted about the whole thing.



Firstly, I think he's good at the job he has, and he adds value by doing it.



Secondly, I feel quite annoyed with the way he has gone about this, and I feel quite annoyed with our team leader in supporting him.

Having applied for the role he has, I think he should spend a decent amount of time doing it, before even thinking about moving on.



Thirdly, to be honest, I feel that training him to be a developer is unlikely to be worthwhile.

We have quite complex and performance-critical systems, and I worry that our development effort will be slowed down permanently if he joins the team.



I have trained / mentored new developers "from scratch" in the past, so I don't have a problem with training anyone, per se, but they had the underlying problem-solving skills and systemic approach we look for in developer interviews.



I just don't see those core skills in the guy I'm being asked to train.



As I will need to work with him in any case going forward, I'm unsure how to move forward with this in a professional way.



For now, I've really just been "busy with other things". But this isn't a long-term solution.



Should I support him, despite my reservations, or should I push back?







share|improve this question











closed as off-topic by Lilienthal♦, gnat, user45590, Richard U, Chris E Aug 17 '16 at 14:27


This question appears to be off-topic. The users who voted to close gave this specific reason:


  • "Questions asking for advice on what to do are not practical answerable questions (e.g. "what job should I take?", or "what skills should I learn?"). Questions should get answers explaining why and how to make a decision, not advice on what to do. For more information, click here." – Lilienthal, gnat, Richard U, Chris E
If this question can be reworded to fit the rules in the help center, please edit the question.








  • 5




    "OK, so this is likely to be part-rant, part-question." Then you should probably fix this so it isn't. "What should I do" is off-topic regardless.
    – Lilienthal♦
    Aug 17 '16 at 8:07










  • Would you rather they move into that role without your input?
    – keshlam
    Aug 18 '16 at 0:06
















up vote
0
down vote

favorite












OK, so this is likely to be part-rant, part-question.



I've never encountered this kind of situation before, so I figured there might be someone out there with some useful advice.



Background: in our department, as in most IT departments, we have analysts and developers. Analysts liase with the business, produce initial specs; developers write code to implement the specs.



The department is divided into small functional teams, with a few analysts and a few developers on each team.



Recruitment is handled by the department overall. There is one recruitment track for incoming developers (with interviews handled by senior developers), and one for incoming analysts.



Around six months ago, we had a guy apply to be a developer. He failed the interview (to be clear, he was interviewed by someone else, not me).



A couple of months later, he then applied to be an analyst. He passed this interview, with different interviewers, and started on our team as a senior analyst (so he is fairly well paid).



Pretty much since the day he started, he talked about how "he wanted to get into development".



From what I've seen (and I've worked fairly closely with him), development is a poor fit for his skills.

He isn't too keen on detail, and he doesn't have a great deal of relevant experience.



He is, however, a good enough analyst. He's built a good relationship with our stakeholders, and he has enough of an overview that he can be effective in his current role.



Our company is very keen that everyone should have a Personal Development Plan, and that the Plan should be followed up.
Our new starter, obviously, seized on this, and made "getting into software development" the core of his Plan.



Our team leader does not have a technical background, but has approved his Plan and asked me to support him in moving into development.
I feel quite conflicted about the whole thing.



Firstly, I think he's good at the job he has, and he adds value by doing it.



Secondly, I feel quite annoyed with the way he has gone about this, and I feel quite annoyed with our team leader in supporting him.

Having applied for the role he has, I think he should spend a decent amount of time doing it, before even thinking about moving on.



Thirdly, to be honest, I feel that training him to be a developer is unlikely to be worthwhile.

We have quite complex and performance-critical systems, and I worry that our development effort will be slowed down permanently if he joins the team.



I have trained / mentored new developers "from scratch" in the past, so I don't have a problem with training anyone, per se, but they had the underlying problem-solving skills and systemic approach we look for in developer interviews.



I just don't see those core skills in the guy I'm being asked to train.



As I will need to work with him in any case going forward, I'm unsure how to move forward with this in a professional way.



For now, I've really just been "busy with other things". But this isn't a long-term solution.



Should I support him, despite my reservations, or should I push back?







share|improve this question











closed as off-topic by Lilienthal♦, gnat, user45590, Richard U, Chris E Aug 17 '16 at 14:27


This question appears to be off-topic. The users who voted to close gave this specific reason:


  • "Questions asking for advice on what to do are not practical answerable questions (e.g. "what job should I take?", or "what skills should I learn?"). Questions should get answers explaining why and how to make a decision, not advice on what to do. For more information, click here." – Lilienthal, gnat, Richard U, Chris E
If this question can be reworded to fit the rules in the help center, please edit the question.








  • 5




    "OK, so this is likely to be part-rant, part-question." Then you should probably fix this so it isn't. "What should I do" is off-topic regardless.
    – Lilienthal♦
    Aug 17 '16 at 8:07










  • Would you rather they move into that role without your input?
    – keshlam
    Aug 18 '16 at 0:06












up vote
0
down vote

favorite









up vote
0
down vote

favorite











OK, so this is likely to be part-rant, part-question.



I've never encountered this kind of situation before, so I figured there might be someone out there with some useful advice.



Background: in our department, as in most IT departments, we have analysts and developers. Analysts liase with the business, produce initial specs; developers write code to implement the specs.



The department is divided into small functional teams, with a few analysts and a few developers on each team.



Recruitment is handled by the department overall. There is one recruitment track for incoming developers (with interviews handled by senior developers), and one for incoming analysts.



Around six months ago, we had a guy apply to be a developer. He failed the interview (to be clear, he was interviewed by someone else, not me).



A couple of months later, he then applied to be an analyst. He passed this interview, with different interviewers, and started on our team as a senior analyst (so he is fairly well paid).



Pretty much since the day he started, he talked about how "he wanted to get into development".



From what I've seen (and I've worked fairly closely with him), development is a poor fit for his skills.

He isn't too keen on detail, and he doesn't have a great deal of relevant experience.



He is, however, a good enough analyst. He's built a good relationship with our stakeholders, and he has enough of an overview that he can be effective in his current role.



Our company is very keen that everyone should have a Personal Development Plan, and that the Plan should be followed up.
Our new starter, obviously, seized on this, and made "getting into software development" the core of his Plan.



Our team leader does not have a technical background, but has approved his Plan and asked me to support him in moving into development.
I feel quite conflicted about the whole thing.



Firstly, I think he's good at the job he has, and he adds value by doing it.



Secondly, I feel quite annoyed with the way he has gone about this, and I feel quite annoyed with our team leader in supporting him.

Having applied for the role he has, I think he should spend a decent amount of time doing it, before even thinking about moving on.



Thirdly, to be honest, I feel that training him to be a developer is unlikely to be worthwhile.

We have quite complex and performance-critical systems, and I worry that our development effort will be slowed down permanently if he joins the team.



I have trained / mentored new developers "from scratch" in the past, so I don't have a problem with training anyone, per se, but they had the underlying problem-solving skills and systemic approach we look for in developer interviews.



I just don't see those core skills in the guy I'm being asked to train.



As I will need to work with him in any case going forward, I'm unsure how to move forward with this in a professional way.



For now, I've really just been "busy with other things". But this isn't a long-term solution.



Should I support him, despite my reservations, or should I push back?







share|improve this question











OK, so this is likely to be part-rant, part-question.



I've never encountered this kind of situation before, so I figured there might be someone out there with some useful advice.



Background: in our department, as in most IT departments, we have analysts and developers. Analysts liase with the business, produce initial specs; developers write code to implement the specs.



The department is divided into small functional teams, with a few analysts and a few developers on each team.



Recruitment is handled by the department overall. There is one recruitment track for incoming developers (with interviews handled by senior developers), and one for incoming analysts.



Around six months ago, we had a guy apply to be a developer. He failed the interview (to be clear, he was interviewed by someone else, not me).



A couple of months later, he then applied to be an analyst. He passed this interview, with different interviewers, and started on our team as a senior analyst (so he is fairly well paid).



Pretty much since the day he started, he talked about how "he wanted to get into development".



From what I've seen (and I've worked fairly closely with him), development is a poor fit for his skills.

He isn't too keen on detail, and he doesn't have a great deal of relevant experience.



He is, however, a good enough analyst. He's built a good relationship with our stakeholders, and he has enough of an overview that he can be effective in his current role.



Our company is very keen that everyone should have a Personal Development Plan, and that the Plan should be followed up.
Our new starter, obviously, seized on this, and made "getting into software development" the core of his Plan.



Our team leader does not have a technical background, but has approved his Plan and asked me to support him in moving into development.
I feel quite conflicted about the whole thing.



Firstly, I think he's good at the job he has, and he adds value by doing it.



Secondly, I feel quite annoyed with the way he has gone about this, and I feel quite annoyed with our team leader in supporting him.

Having applied for the role he has, I think he should spend a decent amount of time doing it, before even thinking about moving on.



Thirdly, to be honest, I feel that training him to be a developer is unlikely to be worthwhile.

We have quite complex and performance-critical systems, and I worry that our development effort will be slowed down permanently if he joins the team.



I have trained / mentored new developers "from scratch" in the past, so I don't have a problem with training anyone, per se, but they had the underlying problem-solving skills and systemic approach we look for in developer interviews.



I just don't see those core skills in the guy I'm being asked to train.



As I will need to work with him in any case going forward, I'm unsure how to move forward with this in a professional way.



For now, I've really just been "busy with other things". But this isn't a long-term solution.



Should I support him, despite my reservations, or should I push back?









share|improve this question










share|improve this question




share|improve this question









asked Aug 17 '16 at 5:55







user56321











closed as off-topic by Lilienthal♦, gnat, user45590, Richard U, Chris E Aug 17 '16 at 14:27


This question appears to be off-topic. The users who voted to close gave this specific reason:


  • "Questions asking for advice on what to do are not practical answerable questions (e.g. "what job should I take?", or "what skills should I learn?"). Questions should get answers explaining why and how to make a decision, not advice on what to do. For more information, click here." – Lilienthal, gnat, Richard U, Chris E
If this question can be reworded to fit the rules in the help center, please edit the question.




closed as off-topic by Lilienthal♦, gnat, user45590, Richard U, Chris E Aug 17 '16 at 14:27


This question appears to be off-topic. The users who voted to close gave this specific reason:


  • "Questions asking for advice on what to do are not practical answerable questions (e.g. "what job should I take?", or "what skills should I learn?"). Questions should get answers explaining why and how to make a decision, not advice on what to do. For more information, click here." – Lilienthal, gnat, Richard U, Chris E
If this question can be reworded to fit the rules in the help center, please edit the question.







  • 5




    "OK, so this is likely to be part-rant, part-question." Then you should probably fix this so it isn't. "What should I do" is off-topic regardless.
    – Lilienthal♦
    Aug 17 '16 at 8:07










  • Would you rather they move into that role without your input?
    – keshlam
    Aug 18 '16 at 0:06












  • 5




    "OK, so this is likely to be part-rant, part-question." Then you should probably fix this so it isn't. "What should I do" is off-topic regardless.
    – Lilienthal♦
    Aug 17 '16 at 8:07










  • Would you rather they move into that role without your input?
    – keshlam
    Aug 18 '16 at 0:06







5




5




"OK, so this is likely to be part-rant, part-question." Then you should probably fix this so it isn't. "What should I do" is off-topic regardless.
– Lilienthal♦
Aug 17 '16 at 8:07




"OK, so this is likely to be part-rant, part-question." Then you should probably fix this so it isn't. "What should I do" is off-topic regardless.
– Lilienthal♦
Aug 17 '16 at 8:07












Would you rather they move into that role without your input?
– keshlam
Aug 18 '16 at 0:06




Would you rather they move into that role without your input?
– keshlam
Aug 18 '16 at 0:06










2 Answers
2






active

oldest

votes

















up vote
6
down vote













To answer your question directly... Yes you should support him if that's part of your job. You should do this regardless of what you believe will be a good fit for this person given their current skills.



The Why



This person appears has the drive to get into development. Employees tend to work rather well if they enjoy what they're doing. Happy employees are productive employees and productive employees means FTE well spent.



Now to address your concerns



If you believe that this employee doesn't have the skills needed for development; then let them know. There's nothing wrong with this; give the employee tasks to do at home if it's something that's simple enough that they can google. Get them to learn the basics before you teach them how to code.



If it turns out that it's something that they just aren't able to learn then you can raise it with your manager and let the manager know that you don't think that they'll be a good fit for the role.



In short; start with the basics. If you're there to mentor this person, then tell them what they need to know prior to being shown how to code/develop. If they can't grasp the basics then so be it; but until you provide someone with the rope, they aren't going to trip themselves up and fall flat. (Who knows, they may even be a great fit)






share|improve this answer





















  • At the best, the would-be developer will surprise you do much better than expected. At the worst, you will have given them a fair shot at what they want.
    – Patricia Shanahan
    Aug 17 '16 at 6:46










  • @PatriciaShanahan Exactly! You don't really lose. You either get what you expected, or you end up with something better than you expected!
    – Rawrskyes
    Aug 17 '16 at 6:47






  • 1




    Plus if your boss tell you to do it, and it's part of your job, then you do it. You can, however, share your doubts. Ideally with the employee themselves, or possibly with your boss, depending on the relationship. But do it nonetheless.
    – bilbo_pingouin
    Aug 17 '16 at 7:02






  • 1




    Finally, if he ends up in your team and not pulling his weight/coping with the rigors of the job, you can easily "manage him out the door" through the performance review system - that's what it's for.
    – toadflakz
    Aug 17 '16 at 13:24

















up vote
2
down vote













So you've already identified the place to start: not good with details. So show them how details matter, and small things become system-crashing stuff. Let them see that details will be part of the job--they might not know.



Developing and coding are two different words for a reason. I know some great coders who can't build a stable system. I know one architect who doesn't code at all, and a few that are mediocre. Don't just teach coding, teach development, the whole picture. At worst, you'll get a much more sympathetic analyst out of it. I wish more analysts had this interest!






share|improve this answer



























    2 Answers
    2






    active

    oldest

    votes








    2 Answers
    2






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes








    up vote
    6
    down vote













    To answer your question directly... Yes you should support him if that's part of your job. You should do this regardless of what you believe will be a good fit for this person given their current skills.



    The Why



    This person appears has the drive to get into development. Employees tend to work rather well if they enjoy what they're doing. Happy employees are productive employees and productive employees means FTE well spent.



    Now to address your concerns



    If you believe that this employee doesn't have the skills needed for development; then let them know. There's nothing wrong with this; give the employee tasks to do at home if it's something that's simple enough that they can google. Get them to learn the basics before you teach them how to code.



    If it turns out that it's something that they just aren't able to learn then you can raise it with your manager and let the manager know that you don't think that they'll be a good fit for the role.



    In short; start with the basics. If you're there to mentor this person, then tell them what they need to know prior to being shown how to code/develop. If they can't grasp the basics then so be it; but until you provide someone with the rope, they aren't going to trip themselves up and fall flat. (Who knows, they may even be a great fit)






    share|improve this answer





















    • At the best, the would-be developer will surprise you do much better than expected. At the worst, you will have given them a fair shot at what they want.
      – Patricia Shanahan
      Aug 17 '16 at 6:46










    • @PatriciaShanahan Exactly! You don't really lose. You either get what you expected, or you end up with something better than you expected!
      – Rawrskyes
      Aug 17 '16 at 6:47






    • 1




      Plus if your boss tell you to do it, and it's part of your job, then you do it. You can, however, share your doubts. Ideally with the employee themselves, or possibly with your boss, depending on the relationship. But do it nonetheless.
      – bilbo_pingouin
      Aug 17 '16 at 7:02






    • 1




      Finally, if he ends up in your team and not pulling his weight/coping with the rigors of the job, you can easily "manage him out the door" through the performance review system - that's what it's for.
      – toadflakz
      Aug 17 '16 at 13:24














    up vote
    6
    down vote













    To answer your question directly... Yes you should support him if that's part of your job. You should do this regardless of what you believe will be a good fit for this person given their current skills.



    The Why



    This person appears has the drive to get into development. Employees tend to work rather well if they enjoy what they're doing. Happy employees are productive employees and productive employees means FTE well spent.



    Now to address your concerns



    If you believe that this employee doesn't have the skills needed for development; then let them know. There's nothing wrong with this; give the employee tasks to do at home if it's something that's simple enough that they can google. Get them to learn the basics before you teach them how to code.



    If it turns out that it's something that they just aren't able to learn then you can raise it with your manager and let the manager know that you don't think that they'll be a good fit for the role.



    In short; start with the basics. If you're there to mentor this person, then tell them what they need to know prior to being shown how to code/develop. If they can't grasp the basics then so be it; but until you provide someone with the rope, they aren't going to trip themselves up and fall flat. (Who knows, they may even be a great fit)






    share|improve this answer





















    • At the best, the would-be developer will surprise you do much better than expected. At the worst, you will have given them a fair shot at what they want.
      – Patricia Shanahan
      Aug 17 '16 at 6:46










    • @PatriciaShanahan Exactly! You don't really lose. You either get what you expected, or you end up with something better than you expected!
      – Rawrskyes
      Aug 17 '16 at 6:47






    • 1




      Plus if your boss tell you to do it, and it's part of your job, then you do it. You can, however, share your doubts. Ideally with the employee themselves, or possibly with your boss, depending on the relationship. But do it nonetheless.
      – bilbo_pingouin
      Aug 17 '16 at 7:02






    • 1




      Finally, if he ends up in your team and not pulling his weight/coping with the rigors of the job, you can easily "manage him out the door" through the performance review system - that's what it's for.
      – toadflakz
      Aug 17 '16 at 13:24












    up vote
    6
    down vote










    up vote
    6
    down vote









    To answer your question directly... Yes you should support him if that's part of your job. You should do this regardless of what you believe will be a good fit for this person given their current skills.



    The Why



    This person appears has the drive to get into development. Employees tend to work rather well if they enjoy what they're doing. Happy employees are productive employees and productive employees means FTE well spent.



    Now to address your concerns



    If you believe that this employee doesn't have the skills needed for development; then let them know. There's nothing wrong with this; give the employee tasks to do at home if it's something that's simple enough that they can google. Get them to learn the basics before you teach them how to code.



    If it turns out that it's something that they just aren't able to learn then you can raise it with your manager and let the manager know that you don't think that they'll be a good fit for the role.



    In short; start with the basics. If you're there to mentor this person, then tell them what they need to know prior to being shown how to code/develop. If they can't grasp the basics then so be it; but until you provide someone with the rope, they aren't going to trip themselves up and fall flat. (Who knows, they may even be a great fit)






    share|improve this answer













    To answer your question directly... Yes you should support him if that's part of your job. You should do this regardless of what you believe will be a good fit for this person given their current skills.



    The Why



    This person appears has the drive to get into development. Employees tend to work rather well if they enjoy what they're doing. Happy employees are productive employees and productive employees means FTE well spent.



    Now to address your concerns



    If you believe that this employee doesn't have the skills needed for development; then let them know. There's nothing wrong with this; give the employee tasks to do at home if it's something that's simple enough that they can google. Get them to learn the basics before you teach them how to code.



    If it turns out that it's something that they just aren't able to learn then you can raise it with your manager and let the manager know that you don't think that they'll be a good fit for the role.



    In short; start with the basics. If you're there to mentor this person, then tell them what they need to know prior to being shown how to code/develop. If they can't grasp the basics then so be it; but until you provide someone with the rope, they aren't going to trip themselves up and fall flat. (Who knows, they may even be a great fit)







    share|improve this answer













    share|improve this answer



    share|improve this answer











    answered Aug 17 '16 at 6:41









    Rawrskyes

    82747




    82747











    • At the best, the would-be developer will surprise you do much better than expected. At the worst, you will have given them a fair shot at what they want.
      – Patricia Shanahan
      Aug 17 '16 at 6:46










    • @PatriciaShanahan Exactly! You don't really lose. You either get what you expected, or you end up with something better than you expected!
      – Rawrskyes
      Aug 17 '16 at 6:47






    • 1




      Plus if your boss tell you to do it, and it's part of your job, then you do it. You can, however, share your doubts. Ideally with the employee themselves, or possibly with your boss, depending on the relationship. But do it nonetheless.
      – bilbo_pingouin
      Aug 17 '16 at 7:02






    • 1




      Finally, if he ends up in your team and not pulling his weight/coping with the rigors of the job, you can easily "manage him out the door" through the performance review system - that's what it's for.
      – toadflakz
      Aug 17 '16 at 13:24
















    • At the best, the would-be developer will surprise you do much better than expected. At the worst, you will have given them a fair shot at what they want.
      – Patricia Shanahan
      Aug 17 '16 at 6:46










    • @PatriciaShanahan Exactly! You don't really lose. You either get what you expected, or you end up with something better than you expected!
      – Rawrskyes
      Aug 17 '16 at 6:47






    • 1




      Plus if your boss tell you to do it, and it's part of your job, then you do it. You can, however, share your doubts. Ideally with the employee themselves, or possibly with your boss, depending on the relationship. But do it nonetheless.
      – bilbo_pingouin
      Aug 17 '16 at 7:02






    • 1




      Finally, if he ends up in your team and not pulling his weight/coping with the rigors of the job, you can easily "manage him out the door" through the performance review system - that's what it's for.
      – toadflakz
      Aug 17 '16 at 13:24















    At the best, the would-be developer will surprise you do much better than expected. At the worst, you will have given them a fair shot at what they want.
    – Patricia Shanahan
    Aug 17 '16 at 6:46




    At the best, the would-be developer will surprise you do much better than expected. At the worst, you will have given them a fair shot at what they want.
    – Patricia Shanahan
    Aug 17 '16 at 6:46












    @PatriciaShanahan Exactly! You don't really lose. You either get what you expected, or you end up with something better than you expected!
    – Rawrskyes
    Aug 17 '16 at 6:47




    @PatriciaShanahan Exactly! You don't really lose. You either get what you expected, or you end up with something better than you expected!
    – Rawrskyes
    Aug 17 '16 at 6:47




    1




    1




    Plus if your boss tell you to do it, and it's part of your job, then you do it. You can, however, share your doubts. Ideally with the employee themselves, or possibly with your boss, depending on the relationship. But do it nonetheless.
    – bilbo_pingouin
    Aug 17 '16 at 7:02




    Plus if your boss tell you to do it, and it's part of your job, then you do it. You can, however, share your doubts. Ideally with the employee themselves, or possibly with your boss, depending on the relationship. But do it nonetheless.
    – bilbo_pingouin
    Aug 17 '16 at 7:02




    1




    1




    Finally, if he ends up in your team and not pulling his weight/coping with the rigors of the job, you can easily "manage him out the door" through the performance review system - that's what it's for.
    – toadflakz
    Aug 17 '16 at 13:24




    Finally, if he ends up in your team and not pulling his weight/coping with the rigors of the job, you can easily "manage him out the door" through the performance review system - that's what it's for.
    – toadflakz
    Aug 17 '16 at 13:24












    up vote
    2
    down vote













    So you've already identified the place to start: not good with details. So show them how details matter, and small things become system-crashing stuff. Let them see that details will be part of the job--they might not know.



    Developing and coding are two different words for a reason. I know some great coders who can't build a stable system. I know one architect who doesn't code at all, and a few that are mediocre. Don't just teach coding, teach development, the whole picture. At worst, you'll get a much more sympathetic analyst out of it. I wish more analysts had this interest!






    share|improve this answer

























      up vote
      2
      down vote













      So you've already identified the place to start: not good with details. So show them how details matter, and small things become system-crashing stuff. Let them see that details will be part of the job--they might not know.



      Developing and coding are two different words for a reason. I know some great coders who can't build a stable system. I know one architect who doesn't code at all, and a few that are mediocre. Don't just teach coding, teach development, the whole picture. At worst, you'll get a much more sympathetic analyst out of it. I wish more analysts had this interest!






      share|improve this answer























        up vote
        2
        down vote










        up vote
        2
        down vote









        So you've already identified the place to start: not good with details. So show them how details matter, and small things become system-crashing stuff. Let them see that details will be part of the job--they might not know.



        Developing and coding are two different words for a reason. I know some great coders who can't build a stable system. I know one architect who doesn't code at all, and a few that are mediocre. Don't just teach coding, teach development, the whole picture. At worst, you'll get a much more sympathetic analyst out of it. I wish more analysts had this interest!






        share|improve this answer













        So you've already identified the place to start: not good with details. So show them how details matter, and small things become system-crashing stuff. Let them see that details will be part of the job--they might not know.



        Developing and coding are two different words for a reason. I know some great coders who can't build a stable system. I know one architect who doesn't code at all, and a few that are mediocre. Don't just teach coding, teach development, the whole picture. At worst, you'll get a much more sympathetic analyst out of it. I wish more analysts had this interest!







        share|improve this answer













        share|improve this answer



        share|improve this answer











        answered Aug 17 '16 at 13:13









        jimm101

        11.6k72753




        11.6k72753












            Comments

            Popular posts from this blog

            Long meetings (6-7 hours a day): Being “babysat” by supervisor

            Is the Concept of Multiple Fantasy Races Scientifically Flawed? [closed]

            Confectionery