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

Stanford study shows success of different programming styles in CS class

ed.stanford.edu

Post reply on HN
Print view View original

11–20 of 53 posts

Re: Stanford study shows success of different programming styles in CS class

#11

Post by tarpherder »

VMG wrote: post #8
partition wrote: post #3

What was interesting is that the higher-performing group (Alpha) was stuck less often that the lower-performing group (Gamma). Is this the next programming motto after "Don't Repeat Yourself"? Don't Get Stuck! Now how does one avoid getting stuck while programming? I still get stuck a lot, but these really helped: - Test what you write as quickly as you can. - Hold it in your head! Or you won't have a clue what all y…

> What was interesting is that the higher-performing group (Alpha) was stuck less often that the lower-performing group (Gamma). Which may just be correlated with high performance, not necessarily the cause. If you make "don't get stuck" a motto, you can easily imagine people skipping over difficult problems and not thinking about a good solution.

I share your concern that this will result in a lot of sloppy solution to lots of little problems which in turn results in one big mess of sloppy-but-it-works solutions which can be a big problem (but doesn't have to be). However, even when working out a good solution I think it's important not to get stuck. Make sure you are making some sort of progress; it's okay that it takes time but it is not okay if someone is just moving in circles instead of inching closer to the solution. Basically if something takes "too long" to get working, try a different approach or come back to it at a later time to try again. I quite like the "Don't get stuck" motto if we look at it that way.

Re: Stanford study shows success of different programming styles in CS class

#12

Post by bjwbell »

VMG wrote: post #8
partition wrote: post #3

What was interesting is that the higher-performing group (Alpha) was stuck less often that the lower-performing group (Gamma). Is this the next programming motto after "Don't Repeat Yourself"? Don't Get Stuck! Now how does one avoid getting stuck while programming? I still get stuck a lot, but these really helped: - Test what you write as quickly as you can. - Hold it in your head! Or you won't have a clue what all y…

> What was interesting is that the higher-performing group (Alpha) was stuck less often that the lower-performing group (Gamma). Which may just be correlated with high performance, not necessarily the cause. If you make "don't get stuck" a motto, you can easily imagine people skipping over difficult problems and not thinking about a good solution.

"don't get stuck" reminds me of the feynman method of problem solving:

1. Write down the problem. 2. Think very hard. 3. Write down the answer.

Rich Hickey's Hammock Driven Development, https://www.youtube.com/watch?v=f84n5oFoZBc, is IMO very good for actually not getting stuck in a bad place problem solving.

Re: Stanford study shows success of different programming styles in CS class

#13

Post by datenwolf »

partition wrote: post #3

What was interesting is that the higher-performing group (Alpha) was stuck less often that the lower-performing group (Gamma). Is this the next programming motto after "Don't Repeat Yourself"? Don't Get Stuck! Now how does one avoid getting stuck while programming? I still get stuck a lot, but these really helped: - Test what you write as quickly as you can. - Hold it in your head! Or you won't have a clue what all y…

> Test what you write as quickly as you can.

Until you run into that one problem where you can't test between the small steps, because you need the whole thing to be up (to some degree) and working for any test to work.

Operating system kernels would be an example of that: The best test for a *nix OS kernel is, if it can run a shell. You need all the essential syscalls to do something sensible and if any of the required parts doesn't work the whole thing fails.

Another example would be refactoring a complex library into something more manageable. If you keep working in small, testable steps you can move only along the gradient, bordered by "can execute" and "doesn't execute". So you'll be able to reach only a local extremum. Now if you're in the fog and don't know where to go, that's fine. And for most development this is exactly how it happens. But sometimes you can see that summit on the other side of that rift and you know you have to take a leap to get over there.

I spent the past 3 weeks doing exactly that, refactoring a code base. I knew exactly where I wanted to go, but eventually it meant working for about a week on code without being able to compile, not even think of testing it, because everything was moving around and getting reorganized. However now I'm enjoying the fruits of that week; a much cleaner codebase, easier to work with and I even managed to eliminate some Voodoo code nobody knew why it was there, except that it made things work and things broke if you touched it.

> - Hold it in your head! Or you won't have a clue what all your code, together, is doing.

Or, sometimes it's important to get it out of your head, take a week or two off and look at it again with a fresh mind and from a different angle. Often problems seem only hard because you're approaching them from that one angle and you're so stuck with wanting to get it done, that you don't see the better way.

Instead you should write code in a way that it's easy to get back into it.

> - To get started, ask yourself, what is the simplest thing that could possibly work?

And then wonder: What would it take to make this simple thing break. Make things as simple as necessary but not simpler.

Re: Stanford study shows success of different programming styles in CS class

#14

Post by VLM »

partition wrote: post #3

What was interesting is that the higher-performing group (Alpha) was stuck less often that the lower-performing group (Gamma). Is this the next programming motto after "Don't Repeat Yourself"? Don't Get Stuck! Now how does one avoid getting stuck while programming? I still get stuck a lot, but these really helped: - Test what you write as quickly as you can. - Hold it in your head! Or you won't have a clue what all y…

My interpretation of that part of the article was "refactor early and reimplement often"

That grabs in the concept of switching between planning and experimenting modes with the end result of not getting stuck.

I may be biased in having learned this stuff a long time ago so when I get stuck its from getting hopelessly backed into a corner at which point the best solution is pretty much start over differently, and first semester programmers might get trapped a little more easily, like they don't even know common ancient anti-patterns so they don't even know where to start looking when debugging.

Reading between the lines it almost sounded like the A level programmers wrote their tests first (which is usually easy) then wrote code to pass the tests (usually not too awful) then they were done, whereas the lower grade level programmers wrote the code first, then tried to debug (and debugging is always harder than test writing or coding)

Re: Stanford study shows success of different programming styles in CS class

#16

Post by brudgers »

nerdy wrote: post #4

Begs the question: "Is there a 'right' way to think about programming problems?" My knee-jerk reaction would be "No! Everyone learns and thinks differently"-- but being able to put programming styles into buckets and correlate final grades from it suggests otherwise, doesn't it?

I think the emphasis is more about the way people think about solving programming problems than the way they think about the problem itself. An analogy is that two people may differ in their mental models at the level of syntactic sugar rather than Turing completeness.

Re: Stanford study shows success of different programming styles in CS class

#17

Post by random_coder »

partition wrote: post #3

What was interesting is that the higher-performing group (Alpha) was stuck less often that the lower-performing group (Gamma). Is this the next programming motto after "Don't Repeat Yourself"? Don't Get Stuck! Now how does one avoid getting stuck while programming? I still get stuck a lot, but these really helped: - Test what you write as quickly as you can. - Hold it in your head! Or you won't have a clue what all y…

It's also likely that these guys had already programmed before coming to the class. We all tend to get stuck when programming something for the first time. Second and third times are much smoother experiences.

Re: Stanford study shows success of different programming styles in CS class

#18

Post by mironathetin »

VMG wrote: post #8
partition wrote: post #3

What was interesting is that the higher-performing group (Alpha) was stuck less often that the lower-performing group (Gamma). Is this the next programming motto after "Don't Repeat Yourself"? Don't Get Stuck! Now how does one avoid getting stuck while programming? I still get stuck a lot, but these really helped: - Test what you write as quickly as you can. - Hold it in your head! Or you won't have a clue what all y…

> What was interesting is that the higher-performing group (Alpha) was stuck less often that the lower-performing group (Gamma). Which may just be correlated with high performance, not necessarily the cause. If you make "don't get stuck" a motto, you can easily imagine people skipping over difficult problems and not thinking about a good solution.

"If you make "don't get stuck" a motto, you can easily imagine people skipping over difficult problems and not thinking about a good solution."

It is also important to define, what "getting stuck" means. For the research the alpha performers where the ones who fulfilled the goal quickest. If you switch the point of view from the teachers to the learning student, instead of fulfilling the requested goal quickest, you might follow an interesting problem that you discovered on the way. Is that getting stuck? No! It is following your own path of learning which is a very effective method. It does not look best to the teacher, but it can be very good for the learning student.

Asking your own questions and answering them is an important part of a learning process. It also makes you independent, so you don't simply do most efficiently what someone told you to do.

Re: Stanford study shows success of different programming styles in CS class

#19

Post by atmosx »

nerdy wrote: post #4

Begs the question: "Is there a 'right' way to think about programming problems?" My knee-jerk reaction would be "No! Everyone learns and thinks differently"-- but being able to put programming styles into buckets and correlate final grades from it suggests otherwise, doesn't it?

It might suggest something, but it's just a hint. In order to take that approach as conclusive much more comprehensive studies in to highly diversified environments should take place.

All that leaving aside that it's a social science we're talking so... It's not exactly science as in scientific method. It's just models that (under X circumstances) might or might not apply... Go figure ;-)

Re: Stanford study shows success of different programming styles in CS class

#20

Post by vanderZwan »

partition wrote: post #3

What was interesting is that the higher-performing group (Alpha) was stuck less often that the lower-performing group (Gamma). Is this the next programming motto after "Don't Repeat Yourself"? Don't Get Stuck! Now how does one avoid getting stuck while programming? I still get stuck a lot, but these really helped: - Test what you write as quickly as you can. - Hold it in your head! Or you won't have a clue what all y…

> Hold it in your head! Or you won't have a clue what all your code, together, is doing.

Do you mean to say: if you can't hold it all in your head, you're overcomplicating things? Because if so, I agree.

I just finished giving an introduction to programming course, using Processing. I tried teaching my students to write structured code from the start, splitting functionality into smaller methods as much as sensible. That way they never have to juggle too much functionality in their head at once.

On the first day I had them call built-in methods. Then I introduced the concept of variables and types, then I introduced defining your own methods, and only after that did I move on to booleans, if/else, for-loops and arrays.

It seems to have worked well for getting them to structure their code from the start, using methods more or less the same way you would use chapters, headers, sub-headers and paragraphs to structure a paper.

I know this isn't the best way to program, obviously, but this analogy is (relatively) easy for them to understand and loads better than the ball of muddy spaghetti you often see with people who just start out. It's also probably fairly easy to make the jump to other more advanced forms of code organisation.

I also completely agree with your other two points by the way, I kept repeating similar statements throughout the course:

- By splitting functionality into small methods, it's easy to test if something does what it is supposed to do (and I could easily correct them: "Hey, this method drawBall() is also doing hit detection. That's not what the method is supposed to do, restructure the code!").

- "The computer only does what it is literally instructed to do. What do you literally want to do? What are you literally instructing the computer right now?"

Post reply on HN