Stanford study shows success of different programming styles in CS class

It sounds like they discovered that some people already knew how to program.

From the actual article (and not the news article): &quot;The results show that students’ change in programming patterns is only weakly predictive of course performance&quot;<p>Not as &quot;juicy&quot; as the website - but then again, it&#x27;s the actual results :)

Hey! I worked on the preliminary efforts of this project in 2012, and was also a grader for the course. (I&#x27;m &quot;Gibbons, A.&quot; in the citation list)<p>Many people are making great points - there&#x27;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.<p>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 :-)<p>Oh and as another mention - working with Marcelo and Paulo was awesome, both are super passionate, intelligent dudes.

Fantastic! Good steps towards &quot;artificial wisdom&quot;. Define wisdom-- skill in a craft (here: knowing how to think). Using ML to identify &quot;wise&quot; programming mindsets. Then (presumably) developing educational programs which teach these.<p>“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.<p>“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.”

&gt;&gt; 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.<p>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.

<p><pre><code> &gt; &quot;The discovery of these “sink states,” and how students &gt; got into them, offers opportunities beyond predicting &gt; grades: They open the door for developing systems to &gt; encourage students to go down more fruitful paths before &gt; they become lost in the programming weeds.&quot; </code></pre> In the real world, my most valuable learning experiences have been those dead ends. Because I don&#x27;t repeat those mistakes - better to make them and learn from them than to be steered away from them before they happen.

&gt;&gt; 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.<p>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&#x27;s structure and behavior during the implementation.

I think data mining editor&#x2F;IDE use is a pretty useful idea overall and the &quot;paradigm shift&quot; of constant monitoring which allows immediate teacher feedback is much needed (not just for programming).<p>The other interesting approach I read about a while back was using tracing quiz data to identify &quot;blind spots&quot;. A typical example was identifying students that had problems understanding loop constructs (they would always assume one iteration for example).<p>I talked to one of the authors of this paper and he had some interesting ideas fro CS education in general: <a href="http://dl.acm.org/citation.cfm?id=2526978" rel="nofollow">http:&#x2F;&#x2F;dl.acm.org&#x2F;citation.cfm?id=2526978</a><p>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&#x27;d be pretty interested in identifying students that struggle with loops and&#x2F;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.

It&#x27;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 <i>how</i> you should intervene to improve these students&#x27; chances of success.

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

Completely anecdotal, but I vividly remember my own experience learning to program.<p>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.<p>Being a nerd, my main motivation at the time (of course) was to make a D&amp;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)<p>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.<p>Ok, so now I start doing everything in arrays and pretty soon my code is smaller but &quot;fixing stuff&quot; (maintaining code) was stupidly hard. Oh okay, so I learned then some that data and code should be together rather than global (encapsulation).<p>I then needed to create random maps. After struggling with that, I read a paper on fractals, and implemented my first algorithm.<p>You can probably guess by now where I&#x27;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.<p>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&#x27;t cheap.)<p>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.<p>So from my point of view, the outcomes of the paper are arbitrary in the long term. I would definitely had been a &quot;Gamma&quot; programmer. I hit every problem, and got terribly stuck. It took years for me to progress, learn good practices and become a proficient developer.

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 &quot;Don&#x27;t Repeat Yourself&quot;?<p>Don&#x27;t Get Stuck!<p>Now how does one avoid getting stuck while programming? I still get stuck a lot, but these really helped:<p>- Test what you write as quickly as you can.<p>- Hold it in your head! Or you won&#x27;t have a clue what all your code, together, is doing.<p>- To get started, ask yourself, what is the simplest thing that could possibly work?