[The following blog post refers to the article found here: https://www.tandfonline.com/doi/full/10.1080/07370008.2018.1539738]

When we started our investigation of the learning benefits of integrating computation within engineering domains, we realized that students experienced difficulties throughout the learning process. As part of a design-based research study in a materials science and engineering course, first-year engineering students were exposed to computational assignments designed to introduce programming concepts as well as disciplinary concepts. Specifically, we confirmed what we had called the transparency paradox: while some students asked for additional transparency to access the underlying models that were represented by some simulations, students struggled to deal with the complexity of programming, mathematical modeling, and disciplinary knowledge together.

We wanted students to be able to manage such complexity, so we needed to provide some form of support. We started to explore alternatives to inform our learning design and we identified that the Cognitive Load Theory could explain how this complexity overwhelmed students; and provided alternatives to support student learning. We decided then to work on a set of worked examples that would help students to develop some understanding of programming and mathematical modeling before they had to approach these problems on their own.

To design these examples, we followed the instructional principles suggested by empirical research, which included dividing the solution in meaningful steps and providing well-aligned multiple forms of representations. We even created a website ( http://cvieira77.wixsite.com/cpmse-ex4-act5 ), that included video-explanations to most of the examples, and integrated the link into their in-class activities. We expected that students would regularly use the examples to learn how to solve those activities. To our surprise, by the end of the semester, __none of the students had used the examples!__

Figure 1 – One of the web-based worked-example with step-by-step solution and video explanation

We were puzzled to understand why, if students struggled with the complexity of the course assignments, they would not use the support we provided. We decided to go back to the instructional principles and found one that we had dismissed before, because it was not clear how we could implement it in the classroom: self-explaining. How can we have evidence of students doing self-explanations of programming code in a classroom context? We came up with the idea of having students write in-code comments to self-explain. Using this common practice in programming would allow us to: (1) make sure students explore the examples; and (2) analyze students’ explanations to identify the *self-explanation effect*.

We believed that looking for the self-explanation effect in programming should not be too different from other areas. Decades of research have shown that students’ effective explanations are connected to principles and laws, while poor explanations are often limited and superficial. What we did not take into account in here is one of the most common challenges instructors face in an introductory programming course: there is always a great diversity of skills and backgrounds from students. One of the findings we describe in this paper called “*Student Explanations in the Context of Computational Science and Engineering Education*” is that this difference on skills and backgrounds had a significant effect on the way students approached the self-explanation activities. Experienced programmers often considered that the code “spoke by itself,” and so they wrote very simple, generally superficial comments. Novice programmers, on the other hand, may have taken these activities as a learning opportunity, and wrote large, comprehensive comments explaining each line of code. Other findings relate to the use of metacognitive knowledge in students’ explanations, where a group of students preferred to explain their own solution instead of explaining the provided example.

Our study opens the door for several opportunities in the classroom: (1) programming instructors can use the commenting strategy to engage students in self-explaining sample code; (2) there is a pedagogical need to find ways to promote higher quality explanations in programming; and (3) there is an opportunity to promote student metacognitive development using written explanations of programming code. As part of the future work, researchers could consider the relationship between prior experience and written explanations in the context of programming when exploring the self-explanation effect.

** **

** **