Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lessons from teaching CS 1: Code fast

imprompt.us

Post reply on HN
Print view View original

31–40 of 40 posts

Re: Lessons from teaching CS 1: Code fast

#31

Post by jules »

Kliment wrote: post #30
jules wrote: post #28

Earlier quoted context omitted.

> nonlinear effects Can you explain this? If you are a slow programmer and just did exactly the same as the fast programmer, just slower, how can that be a nonlinear slowdown?

At some point trying something else is slower than figuring it out "dry" on paper and coding a pre-thought solution. Thus the nonlinearity. If trying is faster, you can try before you know exactly what you are trying,and figure it out as you try.

So the slowdown is less than linear then. If you do it the stupid way and still try it out it's linear. So if trying it out on paper is faster...

Re: Lessons from teaching CS 1: Code fast

#32

Post by mbrubeck »

jules wrote: post #28
pmb wrote: post #4

Earlier quoted context omitted.

What I was getting at was that increased speed in coding has nonlinear effects n your time-to-solution and that students should code sooner --- before they have the solution in hand --- rather than waiting until they think they know the right answer. Coding for classes should be done quickly and exploratively. But because students either can't code fast or won't code before they have the whole solution mapped out, th…

> nonlinear effects Can you explain this? If you are a slow programmer and just did exactly the same as the fast programmer, just slower, how can that be a nonlinear slowdown?

The point is that the slow programmer won't do just exactly the same thing as the fast programmer. Speed can make a qualitative difference; it affects what you are willing to do, not just how long you take to do it.

Re: Lessons from teaching CS 1: Code fast

#33

Post by pmb »

btilly wrote: post #27
rdtsc wrote: post #19

This is like asking an un-experienced driver to drive fast. Or an un-exprerience scuba diver to go deeper. I remember that I didn't code fast in my CS1 classes. The reason was because it was scary. The compiler and all syntax errors seemed cryptic. Now one of the goals of the class should be to make students not afraid of trying things out. To get there they have to understand the tools and the basics. Having a good…

One intermediate solution is to ask people to code everything out in pseudo-code. Think about what it would do. Then when they are happy about it comment it all out, and below each line of pseudo-code write real code doing the same thing. This lets you do exploratory programming, and also generates verbose comments for the TA to look at. (This strategy is discussed in Code Complete .)

That's true. But it (generally) doesn't let you discard your wrong ideas quickly, which is where the approach I was trying to describe gets most of its benefit. What you describe is much more akin to a waterfall model with a bunch of pseudocode and design up front but without an automated tool (the computer) actually able to run your program and tell you if it is going well.

Re: Lessons from teaching CS 1: Code fast

#34

Post by pmb »

jules wrote: post #31
Kliment wrote: post #30

Earlier quoted context omitted.

At some point trying something else is slower than figuring it out "dry" on paper and coding a pre-thought solution. Thus the nonlinearity. If trying is faster, you can try before you know exactly what you are trying,and figure it out as you try.

So the slowdown is less than linear then. If you do it the stupid way and still try it out it's linear. So if trying it out on paper is faster...

Something is wrong with your logic, both because I can't follow it and because it contradicts all the "anecdata" I have collected during my career.

Re: Lessons from teaching CS 1: Code fast

#35

Post by jules »

pmb wrote: post #34
jules wrote: post #31

Earlier quoted context omitted.

So the slowdown is less than linear then. If you do it the stupid way and still try it out it's linear. So if trying it out on paper is faster...

Something is wrong with your logic, both because I can't follow it and because it contradicts all the "anecdata" I have collected during my career.

The logic is simple. Suppose that a fast programmer can do some task in time t. We have a slow programmer who programs twice as slowly. In the worst case all of time t spent by the fast programmer was spent programming which is what the slow guy is slow at. In that case our slow programmer will take 2t, a linear amount of time. If the slow programmer had an alternative strategy he would only use it if it reduced the time to complete the task. Therefore the time is linear at worst.

Note that even if the slow guy is 1000 times slower it's still linear.

Please explain why the logic isn't right. Could it be that the logic is right but that slow programmers tend to do things on paper first, which is not the best strategy?

Re: Lessons from teaching CS 1: Code fast

#36

Post by prewett »

pmb wrote: post #17
mbrubeck wrote: post #15

Earlier quoted context omitted.

Reading the post again, it seems to me it isn't about raw speed in producing a finished product; it's about the ability to explore a problem space by writing small throw-away trials, before you know how the result should look. Physical speed is just one part of this; I'd say it's really about fluency. Do you use code as a medium for thought and expression, or do you have a separate step where you translate your ideas…

Yes! That is the kind of speed and skill to which I was referring. The ability to use code as a medium for thought and exploration rather than just viewing it as a final product.

Maybe I'm one of the slow coders, but for sizable problems, I find that thinking about the problem on paper speeds things up greatly: I don't waste a bunch of time re-writing my half-written class as I discover it's not what I want. (Not writing in C++ helps) I'm thinking of things that require a few classes here, rather than a large algorithm.

Re: Lessons from teaching CS 1: Code fast

#37

Post by pasbesoin »

What this (title) makes me think of is having and environment/tools that don't get in your way. Not so much a large step (e.g. a significant compile), but the small actions you're constantly taking.

A UI (editor, file manager, etc) that doesn't hesitate while it composes menus or context. "Intellisense" (whatever your flavor, if any) and references that are immediate.

When I work on a slower system, such small pauses accumulate into a "mental stutter" that changes the level of my overall performance. It isn't that I don't think -- a lot -- but that when I manage to form something in my head, I want to get it down with a minimum of of interference and distraction. Those pauses can be the "thousand cuts" of the death of that inspiration.

Perhaps that's one reason I still prefer to design on paper. There's nothing between me and my ideas except the speed of the pencil, and my ability to flip between pages (that have strong visual landmarks).

Re: Lessons from teaching CS 1: Code fast

#38

Post by btilly »

pmb wrote: post #33
btilly wrote: post #27

Earlier quoted context omitted.

One intermediate solution is to ask people to code everything out in pseudo-code. Think about what it would do. Then when they are happy about it comment it all out, and below each line of pseudo-code write real code doing the same thing. This lets you do exploratory programming, and also generates verbose comments for the TA to look at. (This strategy is discussed in Code Complete .)

That's true. But it (generally) doesn't let you discard your wrong ideas quickly, which is where the approach I was trying to describe gets most of its benefit. What you describe is much more akin to a waterfall model with a bunch of pseudocode and design up front but without an automated tool (the computer) actually able to run your program and tell you if it is going well.

That depends on which wrong ideas you're thinking about.

Actually writing down pseudo-code is good at flushing out hidden assumptions, points of confusion, etc. I've found that tracing through pseudo-code can help identify bottlenecks and design flaws. And it is all much cheaper than a real program. So you get to discard a lot of wrong ideas quickly.

However coding up a test program and being able to run through cases quickly on a computer catches slightly different classes of mistakes. You might not catch a logic error in your code, but you are more likely to figure out how an external API works.

I think that both skills are valuable, and both let you discard wrong ideas quickly. They just catch different kinds of wrong ideas. :-)

Re: Lessons from teaching CS 1: Code fast

#39

Post by pmb »

jules wrote: post #35
pmb wrote: post #34

Earlier quoted context omitted.

Something is wrong with your logic, both because I can't follow it and because it contradicts all the "anecdata" I have collected during my career.

The logic is simple. Suppose that a fast programmer can do some task in time t. We have a slow programmer who programs twice as slowly. In the worst case all of time t spent by the fast programmer was spent programming which is what the slow guy is slow at. In that case our slow programmer will take 2t, a linear amount of time. If the slow programmer had an alternative strategy he would only use it if it reduced the…

Because slow programmers don't program first. They program last, and do "big design up front" on paper. This is because the cost of a bad idea is hours wasted, and despite the logical coherence of various "expected value" arguments, students are loathe to risk having wasted multiple hours doing the wrong thing. Because humans' internal risk functions and utility evaluation functions are not linear and bayesian, people who code slowly also code differently, and those differences further slow them down with the goal of having less wasted time. In an effort to reduce their variance, they unknowingly increase their time-to-solution.

Re: Lessons from teaching CS 1: Code fast

#40

Post by jules »

pmb wrote: post #39
jules wrote: post #35

Earlier quoted context omitted.

The logic is simple. Suppose that a fast programmer can do some task in time t. We have a slow programmer who programs twice as slowly. In the worst case all of time t spent by the fast programmer was spent programming which is what the slow guy is slow at. In that case our slow programmer will take 2t, a linear amount of time. If the slow programmer had an alternative strategy he would only use it if it reduced the…

Because slow programmers don't program first. They program last, and do "big design up front" on paper. This is because the cost of a bad idea is hours wasted, and despite the logical coherence of various "expected value" arguments, students are loathe to risk having wasted multiple hours doing the wrong thing. Because humans' internal risk functions and utility evaluation functions are not linear and bayesian, peopl…

That sounds right. I still do that when I'm working with a new programming language/library that I can't yet use well...
Post reply on HN