Complete Data Analyses for Steve

5.9.1 Early Education

Steve was a second-year DM student. He attended a state school, studying a variety of GCSE subjects including mathematics, further mathematics, statistics, and creative art. Steve’s plan was to apply for mathematics for his university degree, which required achieving an A* in both A-level mathematics modules. As Steve achieved an A in one module, the DM degree provided by the Department of Computer Science was offered to him instead.

Steve started learning programming at school when he was 14 years old, ex- ploring computer commands and experimenting with operating system batch files. Eventually, he started programming batch files to solve his mathematics homework. At university, Steve studied two programming modules in the first year: CS118 and CS126. During the second year, Steve studied functional programming and found it very interesting, as he had never done any declarative programming language study.

He thought that the CS118 module was a good introduction to programming basics and performed well in both the coursework and final exam, as shown in Fig- ure 5.23. In addition, Steve performed above the class average in all programming assessments, as shown in Figure 5.23.

Steve found that the CS126 module was very helpful in understanding different types of data structures and algorithms. He performed better in the Witter assignment than in the final exam, yet his overall score was above the class average, as shown in Figure 5.24. He suggested that the CS126 lab sheet problems might become more

interesting if the problems related to a real-life context instead of building general stack or queue implementations. Steve did not have specific preferences for operating systems or IDE, but he thought that Linux provided customisable features, such as an open-source operating system. He thought that including some graphical user interface IDEs might reduce a programmer’s control of the code.

Figure 5.23: Steve’s marks in program-

ming assessments. Figure 5.24: Steve’s overall marks for pro-gramming modules.

5.9.2 Mathematics and Programming

Steve had interesting thoughts about the relationship between mathematics and pro- gramming. He thought that mathematics was independent from programming and that mathematical modules were different from programming modules. He said that the analysis module had rigorous proofs, and he did not think that programming mod- ules implemented analysis concepts. Although CS126 included graphs that needed to be proved, mathematical analysis concepts were not implemented rigorously.

Steve gave an example, explaining how mathematical concepts had been su- perficially implemented in programming. When the runtime for specific algorithms needed to be proved, he said that programmers often used the mathematical approach of ‘hand-waving’ by suggesting that specific operations run in N times because ‘we know it does’ without conducting rigorous proofs. Steve said, ‘A lot of the program- ming modules that I do don’t really intercept with calculus quite distinctly’. However,

he thought that the DM module, which was based on CS concepts, had obvious con- nections and implementations in programming modules. Steve thought that it was not necessary to be good at mathematics to be a good programmer. However, having math- ematical analysis ability might help a programmer to write a more efficient computer program. Steve said that the functional programming module was mathematically oriented, which required a great deal of mathematical ability.

5.9.3 Attitudes and Personal Traits

5.9.3.1 Learning Style

Steve’s general learning style depended on reading and revising material related to specific subjects, whereas Steve’s learning strategy for learning programming and al- gorithms depended on problem analysis and algorithm implementation. He found that he learnt algorithms better when he experimented with code. During the lab, Steve preferred to work on his own, thinking that working in pairs might not guarantee that both students were at the same level. He thought that other students might hold him back from learning more by experimenting with the code and he said, ‘I like to change values, tweak and see how it works’. When Steve faced code bugs, he liked to spend considerable time solving the bugs, and he did not mind doing so until he ran out of options. Then, Steve would seek help.

5.9.3.2 Challenging Tasks

Steve would like to solve challenging tasks, as he found them more intriguing to solve and could learn more from them. Steve mentioned that the CS118 tasks were quite easy, and he had done them before, whereas CS126 included challenging tasks, which he found interesting. He mentioned that he would like to have graded challenging tasks, which are weighted as a small percentage of the lab marks. He thought that the marks were not important, but it gave an indication to measure his performance in a specific area.

5.9.3.3 Communication Skills

Steve thought that his communications skills were good, as he said that one of his hob- bies was role playing games, which involved a lot of verbal communication. However, Steve preferred to communicate in writing rather than in speaking, as he thought that communicating in writing allowed him to develop his arguments better than commu- nicating verbally.

5.9.4 Coding Strategies

Steve described his coding strategies as ‘usually quite bad’, where if he has been given a problem, he liked to think it through for some time before getting a rough idea of what the code could look like. Once he had the idea in his mind, he started implementing it without a clear plan until he reached a point where he could not progress further. Then, he would start over, analysing the problem specifications, designing charts, planning his solution, and implementing his code.

Steve had a constant order when organising his code, starting with constructer, mutator methods, generic methods, and inherited methods at the end. In addition, Steve usually commented on his code, especially if the code was huge, to help remind him of the code explanation, but if he tested some ideas then he omitted comments. Steve would not mind reusing and optimising other code that he already wrote and could be reusable, such as a printing function. Steve usually handled code bugs by fixing them in a linear way, one at time, then he recompiled the code and moved on to fixing the next bug. Based on Witter evidence, Steve implemented Java exceptions, which is a sophisticated and recommended strategy for handling code error.

5.9.5 Mental Representation Strategies

Steve’s general problem-solving strategy depended on breaking down problems into small approachable parts. In addition, he used dynamic programming to solve parts of a problem that contributed to an optimal solution for the whole problem. When

Steve looked into a software application, he usually thought about the application as an entity. Sometimes, he was intrigued by the application features including data structures and algorithms.

Results from analysing Steve’s responses for the code-writing problems had dif- ferent SOLO categorisations for each problem. Although Steve’s response for first problem indicated that he understood the problem specification and translation and could implement his solution, the code had a small bug regarding generating random values. The response did not generate random values including 100, which made the response Unistructural. For the second problem, Steve’s response manifested his abil- ity to understand what was required and to provide a valid code. The response was categorised as Multistructural. Steve’s response to the third problem indicated that he did not understand how to implement recursion, but he managed to include most of the program constructs; thus, his response was categorised as Unistructural.

5.9.6 Witter

Steve described Witter as a ‘tedious’ task, as he encountered technical problems with the provided files that were supposed to create the webpage for Witter. He was not able to test his code to display the Witter information on the webpage instead of using too many print functions, which was the only option for him to test his code.

Despite the technical problem, Steve managed to find a time-consuming alter- native solution for testing his code. He provided a valid approach for all Witter classes achieving an overall grade of 74. Steve’s approach for the User Store included a hash map of an array list. The approach provided a good time complexity, accessing users with Big-O (1) but for the insertion, it depended on the length of the array. Steve mentioned that using some sort of graph for storing followers and follows in the graph edges would be better than using data structures that use nodes. Thus, Steve’s ap- proach consisted of an adjacency matrix that provided fast accessing time, whereas using an adjacency matrix can affect space complexity caused by a sparse matrix. The approach can be improved by implementing, for example, two hash maps instead of an

adjacency matrix. Steve’s approach for the Weet Store class included a hash map of an array list, which provided good time complexity in general, whereas time complex- ity could be improved for some functions, like obtaining a trending topic by including additional structure.

5.9.7 Summary

Steve’s academic performance throughout his early and higher education specifically in programming showed that he had above-average ability among the cohort. He achieved in the top 15%. Throughout Steve’s early and higher education, his mathematical abil- ities were manifested through his high performance. In addition, Steve’s high academic performance indicated his dedication and hard work. Steve was certainly passionate about programming, as he spent his spare time at home programming batch files, solving mathematical problems, and writing source code for games. Witter evidence indicated that Steve’s approach was appropriate according to each specific problem, achieving good time and space complexity. However, his approach was not the optimal solution, and in some cases, the time complexity could have been improved signifi- cantly.