TITLE: Make Your Code Say What You Say When You Describe It
AUTHOR: Eugene Wallingford
DATE: December 04, 2019  2:42 PM
DESC: 
-----
BODY:
<A HREF="https://twitter.com/@marick">
   Brian Marick</A>
recently retweeted
<A HREF="https://twitter.com/RonJeffries/status/1015659653068414976">
   this old tweet</A>
from Ron Jeffries:

<BLOCKQUOTE><EM>
You: Explain this code to me, please.   <BR/>
They: blah blah blah.                   <BR/>
You: Show me where the code says that.  <BR/>
They: &lt;silence&gt;                   <BR/>
You: Let's make it say that.
</EM></BLOCKQUOTE>

 I find this strategy quite helpful when writing my own code.  If
 I can't explain any bit of code to myself clearly and succinctly,
 then I can take a step back and work on fixing my understanding
 before trying to fix the code.  Once I understand, I'm a big fan
 of creating functions or methods whose names convey their meaning.

 This is also a really handy strategy for me in my teaching.  As
 a prof, I spend a fair amount of time explaining code I've written
 to students.  The act of explaining a piece of code, whether
 written or spoken, often points me toward ways I can make the
 program better.  If I find myself explaining the same piece of
 code to several students over time, I know the code can probably
 be better.  So I try to fix it.

 I also use a gentler variation of Jeffries' approach when working
 directly with students and their code.  I try whenever I can to
 help my students learn how to write better programs.  It can be
 tempting to start lecturing them on ways that their program could
 be better, but unsolicited advice of this sort rarely finds a
 happy place to land in their memory.  Asking questions can be more
 effective, because questions can lead to a conversation in which
 students figure some things out on their own.  Asking general
 questions usually isn't helpful, though, because students may not
 have enough experience to connect the general idea to the details
 of their program.

 So:  I find it helpful to ask a student to explain their code to
 me.  Often they'll give me a beautiful answer, short and clear,
 that stands in obvious contrast to the code we are looking at out.
 This discrepancy leads to a natural follow-up question:  <EM>How
 might we change the code so that it says that</EM>?  The student
 can take the lead in improving their own programs, guided by me
 with bits of experience they haven't had yet.

 Of course, sometimes the student's answer is complex or rambles
 off into silence.  That's a cue to both of us that they don't
 really understand yet what they are trying to do.  We can take a
 step back and help them fix their understanding -- of the problem
 or of the programming technique -- before trying to fix the code
 itself.
-----