Psychology of Programming Workshop

Another paper that caught my attention at the recent Psychology of Programming workshop was presented by Matt Jadud from the University of Kent. Matt's research focuses on understanding how novices learn to program and to develop teaching methodologies that take this understanding into account. In his paper, Matt described how he had analysed data collected from an instrumented version of BlueJ, a popular IDE used to teach Java to Computing Science students.

 

Matt presented an excellent analysis of the behavior of students when the IDE reports a compiler error and when students have a syntactically correct program. Matt’s analysis indicated that students prefer to write large amounts of code, and then repeatedly compile their code to find all of the syntax errors in the code. The data indicated that 51% of compilation events occurred less than 30 seconds after the previous event and that the amount of code changed between these events was minimal (along the lines of adding or removing a semi-colon).

 

There was an interesting discussion at the presentation about whether or not the students coding strategy was a good strategy and what things the tool could do to shape students behavior to improve their strategies. The discussion centred around the extent to which guidance in a teaching tool simply conditions students to behave in one way or another. In Visual Studio .Net we do a lot of things to aid developers such as highlighting syntax errors, indicating matching parentheses etc etc. While Visual Studio .Net is not primarily designed to be a teaching tool, are there still some disadvantages to these features even for developers who are not using the tool to learn how to program but to get a job done? Are we at risk of conditioning developers not to pay attention to these details?

Comments

• Anonymous
  April 27, 2004
  That matches my experience in helping newbies. Their view is that the compiler is the test tool, instead of the debugger; that is, if the code compiles, it must be right. So I can imagine that someone would type up their assignment or algorithm in a long mad-coding session, then compile to see if they "got it right."
  This, of course, leads to a deadlock when the code is syntactically correct (it compiles) but it doesn't behave right (it crashes). I can't tell you how many times I've read a post in a message board where someone posts a big block of code and says "the code compiles, why doesn't it work?"
  
  I don't know if a compiler or IDE can fix this on its own. It seems more like it's up to the teacher to teach not only the language, but how to debug problems.
• Anonymous
  April 28, 2004
  Along the lines of IDE's "conditioning developers not to pay attention to details..." I think you make a valid point. In my eight years of programming the most learning occurred after I scrapped all IDE's and started coding (java) strictly using Textpad. It was my blank canvas. The learning curve was steep but it forced me to really think about the coding problem. I almost never wrote more than two or three pages of code and very seldom did I write a function longer than half a page. Part of this was due to the fact that my limited development environment in some ways forced me to simplify my code and really think about my object design. I know a number of "Textpad" developers that feel the same way and I would not have adopted .NET if I could not write code without the IDE. I even saw a guy at Microsoft write his C# demo using vi or emacs. That said, these days, I would rather give up my right arm than give up my Visual Studio .NET
• Anonymous
  April 29, 2004
  The comment has been removed
• Anonymous
  June 16, 2004
  ?? ??
• Anonymous
  July 24, 2004
  ???????????????,??????????????????,??????????????,????????????,??????????