|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
|
|
Thread Tools | Rate Thread | Display Modes |
|
|
|
#1
|
||||
|
||||
|
Re: How can I be an effective programming leader?
One technique I use with the students I'm mentoring is to backseat drive. They do all the keyboard/mouse work (we are using Labview, but training is training), and I tell them what to type/click. They ask questions as we go, and it generally works out fairly well. I find that works better than the "I do, you watch" method because it forces me to slow down and explain better and the student gets the hands-on experience to reinforce the information.
Once I'm confident a student has the basics down, I give them a simple feature to implement and verbally talk through the concepts involved. I watch until they get started, then step aside to work on something else or leave the room for a few minutes (and go check on mechanical or something). After a reasonable period, I check on them and answer questions, then when they're ready, we test and debug together. For more complicated concepts, we spend a lot of time in pseudocode/drawings to make sure we really understand what it is we're trying to accomplish before we start coding, which leads to better code. |
|
#2
|
|||
|
|||
|
Re: How can I be an effective programming leader?
Quote:
This can be a very effective way to work for any level of programmers, as the driver typically has to focus a significant amount of attention to typing and progressing; the 2nd body can spend some time reflecting on what was just done, or on what needs to be done, and watching for mistakes. Starting out, your job should be to patiently watch what he's doing, let him ask questions, when you see a mistake or think of a better way to implement, just make a mental note of it and wait until that particular section is completed before pointing things out so that you minimize the interruptions to the writer. |
|
#3
|
||||
|
||||
|
Re: How can I be an effective programming leader?
Ok...I am the lead mentor for team 2980. I have a couple of tools that I use to help my team with programming:
1) Write the parts of the program yourself, and have them (the students go through line by line and annotate each line of code explaining why it is there and what it does. They are not allowed to use code you have written until they show that they understand what it is for and does.) This way you have working code, and you are giving someone else the opportunity to learn from you.) 2) (This is really the backseat method described above) Keep your hands in your pockets to keep yourself from "doing" anything, and tell them...step by step...what to do and why they are doing it. (This is a lot more time consuming than doing it yourself, but it works. Make sure they take notes and input annotations(comments) so that they can look back over the code and know what you were trying to do.) 3) Create and sustain a code bank...Little bits of code that can be copied and pasted, and then modified with notes on what each bit does and how to use it. 4) Have your students write out pseudo code (really have them write comments) then go back and work with them to fill in the actual code. Hope this helps. By using these techniques we have gone from 1 person able to program in Lab View to 4, and the entire team can at least read a lab view program and tell you a bit about what it should do. Edoga |
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|