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

21–30 of 40 posts

Re: Lessons from teaching CS 1: Code fast

#21

Post by sophacles »

tom_b wrote: post #11

I've been thinking some about the idea of coding fast, or coming up to speed on new languages quickly. From that viewpoint, I'm wondering about what the minimal set of language features you need to have committed to memory to enable you to code fast. These are the pieces of code that without which you can't make even a passing claim of competency in a language. I'm thinking about the crib sheet of functions/definitio…

"I'm pushing towards the idea of internalizing not only the specifics of a language, but the idea of what programming language and tool fits a problem best at any given time."

I've found that anytime something seems crufty, or perhaps like I'm twisting too many rules, or just plain inelegant, I think "there has to be a better way to do this" and its off to the google/documentation/greybeards. If you don't get that feeling yet (it will come) any time something seems hard, explore other people's solutions -- that is more than one, and compare/contrast them on a detailed level. Eventually you'll either start just understanding what the best tool is, or more likely, intuitively knowing that you don't know a good solution and that its time to search. (It's a big field, knowing when you don't know is a good place to be).

Re: Lessons from teaching CS 1: Code fast

#22

Post by pmb »

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…

It applies to all levels, actually. Seniors have this problem too, not just CS1 students.

Re: Lessons from teaching CS 1: Code fast

#23

Post by kscaldef »

mikemainguy wrote: post #6

I agree... personally I think you should not be allowed to code unless you can type somewhere around 60-70 wpm. It is only with extreme mental effort that I can watch someone hunt-and-peck out 5 lines of code fiddling with their mouse and looking for the "n" key or the ";". There should be a minimal period of time between when the code appears in your head and you see it expressed on a screen. If you can't type that…

I completely disagree. The number of problem domains where typing speed is the bottleneck is quite small, and they aren't the interesting problems.

As I spend more time in this business, it becomes clearer and clearer to me that the job of a (senior or above) developer is not to be a typist. It is to assist people in figuring out exactly what their needs are, in a precise sense. Typing the results into a computer is almost incidental.

Re: Lessons from teaching CS 1: Code fast

#24

Post by theBobMcCormick »

After reading the article, it seems like the point isn't so much about coding fast or slow, but that there's a great deal of benefit to being able and willing to do some exploratory coding to try out aspects of your solution before committing to a particular solution approach.

IMHO, this is why fans of "dynamic languages" (an ill defined term, I realize) tend to be so highly enthusiastic about them. For many people, programming in a language like Python, Ruby, etc. is their first real exposure to exploratory, incremental coding.

And those languages are very well suited for that kind of approach, though clearly exploratory coding can be done in pretty much any language.

Re: Lessons from teaching CS 1: Code fast

#25

Post by weaksauce »

theBobMcCormick wrote: post #24

After reading the article, it seems like the point isn't so much about coding fast or slow, but that there's a great deal of benefit to being able and willing to do some exploratory coding to try out aspects of your solution before committing to a particular solution approach. IMHO, this is why fans of "dynamic languages" (an ill defined term, I realize) tend to be so highly enthusiastic about them. For many people,…

I think DVCS can also help here because you have context switches fast using many throwaway topic branches and you can discard a branch that did not work out the way you like. Only pushing the one that worked up after you cleaned up the history a bit. I would guess that a majority of coders that have to work with svn in a corporate environment do not like to go off on branches that may or may not work out for fear of messing up the blessed repository. (that and branching was not the easiest thing to do in subversion.)

Re: Lessons from teaching CS 1: Code fast

#26

Post by bad_user »

I don't like these kind of articles ... yes, such advices are good and doing incremental / exploratory development is something to reflect upon.

BUT ... personally I need clear examples / scenarios / studies. Maybe a school assignment where the progress of two or three students is tracked with a comparison ... which had the best solution, which did it in the least amount of time, which experimented and failed the most, etc ...

Otherwise it just feels like noise.

Re: Lessons from teaching CS 1: Code fast

#27

Post by btilly »

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.)

Re: Lessons from teaching CS 1: Code fast

#28

Post by jules »

pmb wrote: post #4
edw519 wrote: post #3

OP's title is a little too abridged for me. "Code fast" could mean too many different things. Many programmers whose code I maintain look like they adhered to the school of "Don't think, code fast." I would prefer: "Code something small fast." What's "something small"? It could be a just the core of what you propose with no features or embellishments. It could be a subset of the problem at hand. It could be one case…

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?

Re: Lessons from teaching CS 1: Code fast

#29

Post by tom_b »

sophacles wrote: post #21
tom_b wrote: post #11

I've been thinking some about the idea of coding fast, or coming up to speed on new languages quickly. From that viewpoint, I'm wondering about what the minimal set of language features you need to have committed to memory to enable you to code fast. These are the pieces of code that without which you can't make even a passing claim of competency in a language. I'm thinking about the crib sheet of functions/definitio…

"I'm pushing towards the idea of internalizing not only the specifics of a language, but the idea of what programming language and tool fits a problem best at any given time." I've found that anytime something seems crufty, or perhaps like I'm twisting too many rules, or just plain inelegant, I think "there has to be a better way to do this" and its off to the google/documentation/greybeards. If you don't get that fe…

Yeah, I have a lot of "there has to be a better way to do this" thoughts . . .

One of the aspects of software development I'm really interested in is finding drills and ideas that more rapidly build the intuitive response you can trust. The tools of the craft, so to speak.

There is some type of balance to be found in this space, some combination of declarative knowledge (memorization and simple application of different programming languages) and procedural knowledge (experience building up the greater piece of software from that low-level mix).

Thanks for the crufty test idea - nicely sums up what I'm talking about.

Re: Lessons from teaching CS 1: Code fast

#30

Post by Kliment »

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?

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.
Post reply on HN