Comments on: Code fast http://imprompt.us/2009/code-fast/ Computer Science and Teaching and Other Ancillary Things Sat, 24 Jul 2010 12:23:13 +0000 hourly 1 http://wordpress.org/?v=3.0 By: jamesladd http://imprompt.us/2009/code-fast/comment-page-1/#comment-16796 jamesladd Mon, 04 Jan 2010 01:17:39 +0000 http://imprompt.us/2009/code-fast/#comment-16796 When coding professionally I start with Tests (Test Driven Development) and I write a list of potential tests, in the form of shoulds. For example, if coding a stack I might have: should not allow pop of empty stack, which becomes a test shouldNotAllowPopOfEmptyStack or more specifically shouldThrowExceptionWhenPopOfEmptyStack()<br><br>When I have a reasonable list of tests I choose a starter test to code first, and start there.<br><br>To make the list requires thought and some design.<br><br>If you were to ask for the list then you could see evidence of the thought/design and you can compare this to the submitted code which should show if the tests were followed or just made up.<br><br>"Avoiding programming until you can see the whole answer clear as day is foolish, but students do it all the time".<br>I think writing a list of tests first may help with this, especially as they can iterate over their solution and improve it with the tests as a safety net so they wont have to re-work or throw out the existing code. This appears to me to address theirs and your concerns.<br><br>Rgs, James. When coding professionally I start with Tests (Test Driven Development) and I write a list of potential tests, in the form of shoulds. For example, if coding a stack I might have: should not allow pop of empty stack, which becomes a test shouldNotAllowPopOfEmptyStack or more specifically shouldThrowExceptionWhenPopOfEmptyStack()

When I have a reasonable list of tests I choose a starter test to code first, and start there.

To make the list requires thought and some design.

If you were to ask for the list then you could see evidence of the thought/design and you can compare this to the submitted code which should show if the tests were followed or just made up.

“Avoiding programming until you can see the whole answer clear as day is foolish, but students do it all the time”.
I think writing a list of tests first may help with this, especially as they can iterate over their solution and improve it with the tests as a safety net so they wont have to re-work or throw out the existing code. This appears to me to address theirs and your concerns.

Rgs, James.

]]> By: Peter Boothe http://imprompt.us/2009/code-fast/comment-page-1/#comment-16795 Peter Boothe Sun, 03 Jan 2010 06:34:01 +0000 http://imprompt.us/2009/code-fast/#comment-16795 I agree. This wasn't meant to advocate typing faster, so much as being willing to explore and type *sooner* - i.e. before you are sure what the ideas being expressed are. Which leads to coding faster, even if one types at the same speed. Students spend their time, they claim, thinking, but I see no evidence that the time they spend "thinking" wouldn't be better-spent experimenting. Avoiding programming until you can see the whole answer clear as day is foolish, but students do it all the time. I agree. This wasn't meant to advocate typing faster, so much as being willing to explore and type *sooner* – i.e. before you are sure what the ideas being expressed are. Which leads to coding faster, even if one types at the same speed. Students spend their time, they claim, thinking, but I see no evidence that the time they spend “thinking” wouldn't be better-spent experimenting. Avoiding programming until you can see the whole answer clear as day is foolish, but students do it all the time.

]]> By: jamesladd http://imprompt.us/2009/code-fast/comment-page-1/#comment-16794 jamesladd Sun, 03 Jan 2010 05:08:24 +0000 http://imprompt.us/2009/code-fast/#comment-16794 Have you watched -- where -- the students spend their time?<br>Typing faster could be a premature optimization.<br><br>I think the problem is more basic than is being explored. Have you watched — where — the students spend their time?
Typing faster could be a premature optimization.

I think the problem is more basic than is being explored.

]]> By: Adrian http://imprompt.us/2009/code-fast/comment-page-1/#comment-16793 Adrian Sun, 03 Jan 2010 01:02:45 +0000 http://imprompt.us/2009/code-fast/#comment-16793 "The computer is a bicycle for the mind." – Alan Kay “The computer is a bicycle for the mind.” – Alan Kay

]]> By: Lindsey Kuper http://imprompt.us/2009/code-fast/comment-page-1/#comment-16786 Lindsey Kuper Wed, 30 Dec 2009 22:54:32 +0000 http://imprompt.us/2009/code-fast/#comment-16786 Yeah. I use the REPL <em>constantly</em> when I teach. I have a plan for what I want to show, but I usually end up flying by the seat of my pants for at least part of the time. If a student asks a question that I don't know the answer to, I can whip up a quick example and we can find out the answer together. So, if nothing else, they're learning that exploratory programming is a worthwhile problem-solving technique. Yeah. I use the REPL constantly when I teach. I have a plan for what I want to show, but I usually end up flying by the seat of my pants for at least part of the time. If a student asks a question that I don't know the answer to, I can whip up a quick example and we can find out the answer together. So, if nothing else, they're learning that exploratory programming is a worthwhile problem-solving technique.

]]> By: Always Be Exploring — Trevor Burnham http://imprompt.us/2009/code-fast/comment-page-1/#comment-16785 Always Be Exploring — Trevor Burnham Tue, 29 Dec 2009 23:53:25 +0000 http://imprompt.us/2009/code-fast/#comment-16785 [...] This post by math/?CS prof Peter Boothe caught my eye: What I am claiming here is not just that if you code faster, you will get your solution written faster. I am claiming if you code faster, you will get your solution done MUCH faster. The speedup is greater than linear. [...] [...] This post by math/?CS prof Peter Boothe caught my eye: What I am claiming here is not just that if you code faster, you will get your solution written faster. I am claiming if you code faster, you will get your solution done MUCH faster. The speedup is greater than linear. [...]

]]> By: tdw http://imprompt.us/2009/code-fast/comment-page-1/#comment-16784 tdw Fri, 25 Dec 2009 07:46:06 +0000 http://imprompt.us/2009/code-fast/#comment-16784 Practice is the single most important thing. I believe that learning to think programmatically / algorithmically is at least as big as shift as learning to think literately (see <a href="http://www.amazon.com/Orality-Literacy-Technologizing-Word-Accents/dp/0415027969" rel="nofollow">Orality and Literacy</a>, as opposed to being illiterate). Becoming fully literate takes years, with regular / daily practice. And yet we attempt to turn out proficient programmers in 4 years, with students having only maybe 50 assignments ever. Could you have claimed to be a good reader having only read 50 books ever? (Counting CS1/See Spot Run.) Practice is the single most important thing. I believe that learning to think programmatically / algorithmically is at least as big as shift as learning to think literately (see Orality and Literacy, as opposed to being illiterate). Becoming fully literate takes years, with regular / daily practice. And yet we attempt to turn out proficient programmers in 4 years, with students having only maybe 50 assignments ever. Could you have claimed to be a good reader having only read 50 books ever? (Counting CS1/See Spot Run.)

]]> By: tdw http://imprompt.us/2009/code-fast/comment-page-1/#comment-16783 tdw Fri, 25 Dec 2009 07:42:01 +0000 http://imprompt.us/2009/code-fast/#comment-16783 Many profs can't. <br><br>During the years that I taught at a 1st/2nd tier university (top 50 in CS), I tried to code live whenever possible. Very shortly after I did this I realized that most profs don't code live, and possibly don't code, and that we are trying to teach a whole generation of students to be proficient programmers <b>without ever showing them what proficiency looks like</b>. Which isn't to say the point is to show off, but to demonstrate that (a) it can be quick and (b) even "good" programmers make mistakes and (c) code can/should be malleable. Your "progress" on an assignment is very rarely the amount of code you've written, and very often the amount of the hidden details of that you've figured out. Many profs can't.

During the years that I taught at a 1st/2nd tier university (top 50 in CS), I tried to code live whenever possible. Very shortly after I did this I realized that most profs don't code live, and possibly don't code, and that we are trying to teach a whole generation of students to be proficient programmers without ever showing them what proficiency looks like. Which isn't to say the point is to show off, but to demonstrate that (a) it can be quick and (b) even “good” programmers make mistakes and (c) code can/should be malleable. Your “progress” on an assignment is very rarely the amount of code you've written, and very often the amount of the hidden details of that you've figured out.

]]> By: links for 2009-12-24 « Blarney Fellow http://imprompt.us/2009/code-fast/comment-page-1/#comment-16782 links for 2009-12-24 « Blarney Fellow Fri, 25 Dec 2009 01:31:53 +0000 http://imprompt.us/2009/code-fast/#comment-16782 [...] Code fast (tags: programming education productivity lisp teaching) [...] [...] Code fast (tags: programming education productivity lisp teaching) [...]

]]> By: Daily Digest for December 24th | Reading Muzaki http://imprompt.us/2009/code-fast/comment-page-1/#comment-16781 Daily Digest for December 24th | Reading Muzaki Thu, 24 Dec 2009 09:42:46 +0000 http://imprompt.us/2009/code-fast/#comment-16781 [...] Lessons from teaching CS 1: Code fast [...] [...] Lessons from teaching CS 1: Code fast [...]

]]>