Answers.Body: <p>While sometimes it may be hard to step back from a particularly interesting student project, you just have to remember that your role on the project is just as vital as theirs: A teacher.  As a teacher, your job is to explain and teach so that they can actually create an implementation. Even though you don't touch the code, the project couldn't be completed without you.</p>
  
  <p>It may also be helpful to step back during the design phase, because if you haven't been responsible for the design, you feel less like the project is your baby. Also, maybe start your own projects. If you are getting engaged in everything that your students do, then maybe you should become invested in some new project of your own to serve as a distraction from what your students are doing.</p>
  
  <p>It is OK it <em>guide</em> the student to a solution, and even guide very closely. It's good to get the student to understand how their code could be better by simply asking questions about them. Questions are good, because they help the students understand what is going on and the help you as a tool to guide them. If you simply confine yourself to asking questions, even very specific ones, like "Why wouldn't you put the code between lines 23 and 27 into it's own method?", because that's better than telling them how to do it or doing it yourself.</p>
  
  <p>It may also be helpful to you to remember that the maintainer of the project will be the student, and so they <em>have</em> to know how it works. If they don't, although the project may look good when it leaves your workshop, it will fall apart because the projects owner won't be able to maintain the code when inevitably it has to be changed.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-05-28T11:03:57.473Z
Answers.Text: I have my own projects, but I'm certainly not working on them during class time.
Answers.UserDisplayName: Scimonster
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-05-28T11:01:26.517Z
Answers.LastActivityDate: 2017-05-28T11:10:17.493Z
Answers.LastEditDate: 2017-05-28T11:10:17.493Z
Answers.UserDisplayName: thesecretmaster
Answers.Body: <p>I think this an essential and main part of teaching programming and cs (and teaching in general). The ability to hold the answer and guide the student to it.</p>
  
  <p>What I do is try to follow the thought process of the student. When working with them to help them find the problem, I ask various questions (usually "what do <em>you</em> thing is causing this?" etc.) and by their answers it's possible to see what sentences would guide them to the solution. </p>
  
  <p>This method works great (that sound out of the sky but it's based on student feedback) as it allows the student to feel that they found it on their own. I find that they also learn to spot issues on their own afterwards. </p>
  
  <p>Additionally, it's worthwhile remembering that you are the instructor, and not the student. And that the project is a student's project, so keeping that in mind often helps with holding back from doing the work yourself.</p>
  
  <p>However when all else fails, showing the students how you might do it could be a last (<strong>last</strong>) resort. Just be sure to explain every step you're doing, so that the student understands. I cannot express enough how bad this last resort is. But if it gets to that, make sure you're not doing their work, but rather show them something similar</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-05-28T11:03:17.753Z
Answers.Text: I really like your answer, but I disagree with the last paragraph. You should _never_ write code for your student. You can say out loud what has to be done and why, but _never_ write the code yourself.
Answers.UserDisplayName: thesecretmaster
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-05-28T11:03:47.907Z
Answers.Text: @thesecretmaster right, I was occupied for a moment so I couldn't edit it
Answers.UserDisplayName: ItamarG3
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-05-28T11:05:57.843Z
Answers.Text: @thesecretmaster there. Much better. I agree completely, but I couldn't put my thoughts into words properly
Answers.UserDisplayName: ItamarG3
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-05-28T11:01:41.193Z
Answers.LastActivityDate: 2017-05-28T11:05:19.343Z
Answers.LastEditDate: 2017-05-28T11:05:19.343Z
Answers.UserDisplayName: ItamarG3
Body: <p>I run a workshop with a few students. They often do large projects alone that they inevitably run into trouble with. That's completely normal, it's why they need some help in the workshop.</p>
  
  <p>As the instructor, I usually spot the issue and solution pretty quickly. I try and nudge the student in the correct direction, but they don't always get it. After a while, I become personally invested in the project, and I may end up just implementing the fixes I suggest myself (while they watch), and because they aren't responsible for the implementation, they gain less that than if I had let them do it. This happens especially when I help them with the initial design and architecture of the program, as I end up feeling a little like it's mine too.</p>
  
  <p>How can I make myself pull back a little and not do the work for them?</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-05-30T14:39:44.987Z
Comments.Text: You have done step-1 admitting that you have a problem, are powerless to fix. Step-2: Came to believe that a Power greater than ourselves could restore us to sanity. Step-3: Made a decision to turn your will and our lives over to the care of a higher-power. That is trust that things will go well (on average better), if you don't do it. (see http://www.alcoholics-anonymous.org.uk/About-AA/The-12-Steps-of-AA for more help) ☺These steps have helped me in a lot of things.
Comments.UserDisplayName: ctrl-alt-delor
Tags: <social-context>
Title: How to avoid getting emotionally attached to my students' projects?
ThreadText: # How to avoid getting emotionally attached to my students' projects?
  
  (Asked by: username_0 on 2017-05-28)
  
  I run a workshop with a few students. They often do large projects alone that they inevitably run into trouble with. That's completely normal, it's why they need some help in the workshop.
  
  As the instructor, I usually spot the issue and solution pretty quickly. I try and nudge the student in the correct direction, but they don't always get it. After a while, I become personally invested in the project, and I may end up just implementing the fixes I suggest myself (while they watch), and because they aren't responsible for the implementation, they gain less that than if I had let them do it. This happens especially when I help them with the initial design and architecture of the program, as I end up feeling a little like it's mine too.
  
  How can I make myself pull back a little and not do the work for them?
  
  **Tags:** social-context
  
  > **Comments:**
  > **username_1**: You have done step-1 admitting that you have a problem, are powerless to fix. Step-2: Came to believe that a Power greater than ourselves could restore us to sanity. Step-3: Made a decision to turn your will and our lives over to the care of a higher-power. That is trust that things will go well (on average better), if you don't do it. (see http://www.alcoholics-anonymous.org.uk/About-AA/The-12-Steps-of-AA for more help) ☺These steps have helped me in a lot of things.  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_3 on 2017-05-28. Score: 5 | Accepted answer
  
  I think this an essential and main part of teaching programming and cs (and teaching in general). The ability to hold the answer and guide the student to it.
  
  What I do is try to follow the thought process of the student. When working with them to help them find the problem, I ask various questions (usually "what do *you* thing is causing this?" etc.) and by their answers it's possible to see what sentences would guide them to the solution.
  
  This method works great (that sound out of the sky but it's based on student feedback) as it allows the student to feel that they found it on their own. I find that they also learn to spot issues on their own afterwards.
  
  Additionally, it's worthwhile remembering that you are the instructor, and not the student. And that the project is a student's project, so keeping that in mind often helps with holding back from doing the work yourself.
  
  However when all else fails, showing the students how you might do it could be a last (**last**) resort. Just be sure to explain every step you're doing, so that the student understands. I cannot express enough how bad this last resort is. But if it gets to that, make sure you're not doing their work, but rather show them something similar
  
  > **Comments:**
  > **username_2**: I really like your answer, but I disagree with the last paragraph. You should _never_ write code for your student. You can say out loud what has to be done and why, but _never_ write the code yourself.  
  > **username_3**: @username_2 right, I was occupied for a moment so I couldn't edit it  
  > **username_3**: @username_2 there. Much better. I agree completely, but I couldn't put my thoughts into words properly  
  
  ---
  
  ### Answer by username_2 on 2017-05-28. Score: 2
  
  While sometimes it may be hard to step back from a particularly interesting student project, you just have to remember that your role on the project is just as vital as theirs: A teacher. As a teacher, your job is to explain and teach so that they can actually create an implementation. Even though you don't touch the code, the project couldn't be completed without you.
  
  It may also be helpful to step back during the design phase, because if you haven't been responsible for the design, you feel less like the project is your baby. Also, maybe start your own projects. If you are getting engaged in everything that your students do, then maybe you should become invested in some new project of your own to serve as a distraction from what your students are doing.
  
  It is OK it *guide* the student to a solution, and even guide very closely. It's good to get the student to understand how their code could be better by simply asking questions about them. Questions are good, because they help the students understand what is going on and the help you as a tool to guide them. If you simply confine yourself to asking questions, even very specific ones, like "Why wouldn't you put the code between lines 23 and 27 into it's own method?", because that's better than telling them how to do it or doing it yourself.
  
  It may also be helpful to you to remember that the maintainer of the project will be the student, and so they *have* to know how it works. If they don't, although the project may look good when it leaves your workshop, it will fall apart because the projects owner won't be able to maintain the code when inevitably it has to be changed.
  
  > **Comments:**
  > **username_0**: I have my own projects, but I'm certainly not working on them during class time.  
  
  ---
  
  