
Stanford study shows success of different programming styles in CS class - kornish
https://ed.stanford.edu/news/stanford-study-shows-success-different-learning-styles-computer-science-class
======
ynniv
It sounds like they discovered that some people already knew how to program.

~~~
willvarfar
> 70 students enrolled in an introductory undergraduate course in programming
> methodology

I'm curious about that too; is this course optional? Would people who can
already program take this course?

~~~
khalilravanna
Anecdotally, at my university (graduated 2013 so still a recent experience), a
lot of CS students took the intro to programming course. In fact, it was (and
still is) a requirement for a BS in CS at the school. The only way you could
get out of it was if you had taken AP CS in high school and passed the test
for the credits.

A large majority of my CS friends in that class had all been programming for
either a little bit or quite some time, and the class was mostly a joke for
them. Lectures were optional, and a bunch of friends (including myself) only
attended three classes the entire semester: the first class (where we found
out we didn't need to go to class except for tests) and the mid term and
final.

Of course on the other side of things, I had friends who had never programmed
before and found the course grueling and struggled to pass.

~~~
auxym
Similar experience in my two first-year Matlab classes in mechanical
engineering.

------
inglor
From the actual article (and not the news article): "The results show that
students’ change in programming patterns is only weakly predictive of course
performance"

Not as "juicy" as the website - but then again, it's the actual results :)

------
AustinBGibbons
Hey! I worked on the preliminary efforts of this project in 2012, and was also
a grader for the course. (I'm "Gibbons, A." in the citation list)

Many people are making great points - there's a wealth of uncontrolled
variables (ie some students already know how to program), but it was a
fascinating dataset and I could even see the paradigms play out over the
quarter during discussions with my students, both experienced programmers and
students getting their first exposure to programming.

I would offer as a larger takeaway that work like this has the potential to
vastly increase our understanding of learning and development with the rise of
MOOCs, ipads-in-every-classroom, and of course IDEs that save every
incremental compilation :-)

Oh and as another mention - working with Marcelo and Paulo was awesome, both
are super passionate, intelligent dudes.

------
mellavora
Fantastic! Good steps towards "artificial wisdom". Define wisdom-- skill in a
craft (here: knowing how to think). Using ML to identify "wise" programming
mindsets. Then (presumably) developing educational programs which teach these.

“Educational data mining should not be used to reinforce the existing
ineffective forms of assessment, but to reimagine it completely,” Blikstein
said. “Pre- and post-assessment is a black-box. We do not know much about what
is happening in between.

“Ultimately, this work may help us better understand some forms of human
cognition because you can see what people are doing and how they are thinking
in real time.”

------
the_watcher
>> the authors did not find any correlation between the amount of “tinkering”
— which is often thought to signify lack of programming expertise — and course
performance. However, the authors found that students who changed their
programming style — going from being a “planner” to a “tinkerer,” or vice
versa — were the ones who performed best, suggesting that behavior change
(rather than learning one single behavior) was determinant for course
performance.

Not being flippant: The conclusion here seems to be evidence of an ability to
learn something new, regardless of what, is strongly indicative of
performance.

------
GrinningFool

        > "The discovery of these “sink states,” and how students 
        > got into them, offers opportunities beyond predicting 
        > grades: They open the door for developing systems to 
        > encourage students to go down more fruitful paths before 
        > they become lost in the programming weeds."
    

In the real world, my most valuable learning experiences have been those dead
ends. Because I don't repeat those mistakes - better to make them and learn
from them than to be steered away from them before they happen.

~~~
taeric
Relatedly, I have seen plenty of very smart people that were able to bowl over
these "sink states" completely unaware of just how unmaintainable their
ultimate solution was.

------
markbnj
>> Alpha students, explained co-author Piech, moved efficiently from one point
to another as they wrote code, creating a streamlined program. Beta and gamma
students, on the other hand, wrote themselves into so-called “sink states” in
which their programs slammed into dead ends from which they had to back out
before they could resume progress.

Very interesting, and intuitively right to me. The difference is likely in the
ability to create and maintain a consistent mental model of the program's
structure and behavior during the implementation.

------
kriro
I think data mining editor/IDE use is a pretty useful idea overall and the
"paradigm shift" of constant monitoring which allows immediate teacher
feedback is much needed (not just for programming).

The other interesting approach I read about a while back was using tracing
quiz data to identify "blind spots". A typical example was identifying
students that had problems understanding loop constructs (they would always
assume one iteration for example).

I talked to one of the authors of this paper and he had some interesting ideas
fro CS education in general:
[http://dl.acm.org/citation.cfm?id=2526978](http://dl.acm.org/citation.cfm?id=2526978)

My gut instinct and thinking back to my university days make me think that a
blind spot for recursion may very well be a thing. I'd be pretty interested in
identifying students that struggle with loops and/or recursion and
investigating that further. For example...is there a correlation? If not what
happens if you give a loop-struggler group only recursive tasks and a
recursion-struggler group only loop tasks? Etc.

------
skywhopper
It's not necessarily surprising that they might be able to detect students who
will likely perform poorly in the course overall by monitoring their behavior
early on. But the real challenge is not in determining which students are
struggling, but rather in when and _how_ you should intervene to improve these
students' chances of success.

------
nerdy
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?

~~~
atmosx
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 ;-)

------
convivialdingo
Completely anecdotal, but I vividly remember my own experience learning to
program.

I learned in a vacuum, having nobody around with any software experience. I
was given a PC and then saved up for an Amiga 500 (and later a $500 Lattice C
compiler). My only link to software was through the bookstore and magazines.

Being a nerd, my main motivation at the time (of course) was to make a D&D
game. I remember my first code was in Basic (no subroutines!) so I eventually
learned to create subroutines based on line numbers (100-900 was main, 1000
was map, 1100 was character A, etc)

I managed to make about 50% of a single game before I ran out of memory. So I
then set out to shrink (optimize) what I had made. After reading an article on
dungeon map creation, I figured out that large arrays could replace the hand-
coded drawing I had written. Check.

Ok, so now I start doing everything in arrays and pretty soon my code is
smaller but "fixing stuff" (maintaining code) was stupidly hard. Oh okay, so I
learned then some that data and code should be together rather than global
(encapsulation).

I then needed to create random maps. After struggling with that, I read a
paper on fractals, and implemented my first algorithm.

You can probably guess by now where I'm going with all this... I had crudely
recreated many things by knocking up against hardware and brain limitations
and figuring out how to work around them.

I progressed into Pascal, C, C++, assembly and eventually created my own
assembler and graphical operating system at 16 years old. It was not a thing
of beauty, but it did work. (Time was free, and compilers weren't cheap.)

I think that most people learn programming by failing, hitting traps, finding
limits, crashing, burning and trying again. The only real identifier of
outcomes, in the long term, is the willingness to continue trying and learning
from mistakes.

So from my point of view, the outcomes of the paper are arbitrary in the long
term. I would definitely had been a "Gamma" programmer. I hit every problem,
and got terribly stuck. It took years for me to progress, learn good practices
and become a proficient developer.

------
partition
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 your code,
together, is doing.

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

~~~
VMG
> 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.

~~~
bjwbell
"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](https://www.youtube.com/watch?v=f84n5oFoZBc),
is IMO very good for actually not getting stuck in a bad place problem
solving.

~~~
partition
Wow, this was a big wake-up call. It's ironic because I am in research and I
always did a lot of theory and problem definition up front for whatever I did,
but I am now in this "reckless rapid prototyping" phase where if I get some
idea I have to try it out RIGHT NOW, stepping back be damned. Ironically it
results in getting stuck more than I would have wanted!

I guess this is the fourth tip?

\- Step away from the computer

