Papel de los contextos socializadores en la formación y desarrollo de los

5.2.1 Early Education

Joe went to state school for his early education then joined a state college where he was introduced to computing for the first time. During his A-level studies, Joe took mathematics and further mathematics. Joe went to mathematics classes as an extra activity during the summer and said it was important for him to practice.

Joe studied computing, which he enjoyed a lot. The computing curriculum included programming with Visual Basic and a low-level programming language, then he taught himself Java and Android while he studied databases and basic algorithms, such as quick sort and binary search.

When Joe was asked why he chose to study CS, he was clearly enthusiastic, explaining his motivations, especially when he said, ‘I enjoyed problem solving’. He said the combination of solving mathematical problems, which requires logical thinking and programming skills, was the reason he studied CS.

Figure 5.6 shows that Joe’s performance in the mathematics modules at univer- sity was above the class mean, putting him in the top 10% of the cohort. Joe was the second highest mathematics student among CS participants, as shown in Figure 5.1.

Figure 5.6: Joe’s mathematics module grades compared to the class mean.

Joe’s performance in the programming module assessments was above the class av- erage except for his performance in the Witter project, where he performed below the class mean (Figure 5.7). Joe’s overall grades for both programming modules were above the class average as shown in Figure 5.8. Figure 5.5 shows Joe’s average compared to the participants of the programming modules.

5.2.2 Mathematics and Programming

Joe’s perspective about the relationship between mathematics and programming was not about which causes the other, rather it was understanding the aspects that math- ematics and programming have in common. Joe’s view was that both fields shared

Figure 5.7: Joe’s grades in programming

assessments. Figure 5.8: Joe’s overall grades for pro-gramming modules.

similar cognitive aspects, such as logical thinking and reasoning. Thus, he felt that if someone was good at mathematics, it meant that he/she thought logically, which could then be useful in programming. Joe mentioned that when he did his first mathematics module (CS130), logic and algebra were covered. Then, when he progressed into his studies and took the algorithm module (CS126), which involved graphs, he was able to apply mathematics to programming. In addition, the relationship between relational algebra and database modules was obvious to him.

Although Joe could not understand how to apply calculus to programming, he thought that knowing and understanding calculus might make him a better pro- grammer. He said the relationship between mathematics and programming became increasingly obvious once he progressed into his studies.

5.2.3 Attitudes and Personal Traits

5.2.3.1 Learning Style

Joe’s learning style did not fit the typical protocol of attending lectures at university. Joe felt he learnt best through solving problems rather than reading a lot of material, as he found tasks that involve thinking, analysis, and coding engaged him more in learning and stimulated him to do more programming. Joe said, ‘Going to seminars is more

useful’, where seminars are usually a small class that involved analysing and solving problems in a more collaborative environment. During lab sessions, Joe preferred to work individually because he felt he learnt from his mistakes by fixing his code by himself and because working in pairs might make him miss something if the other student fixed his code.

5.2.3.2 Challenging Tasks

When Joe was asked whether he would like to solve challenging tasks or not, he empha- sised that he loved programming specifically because of that aspect of problem solving; the harder the task was, the more engaged he would be. He said that it was not the coding process itself but the enjoyable feeling of satisfaction that came from solving a complicated problem. In addition, Joe suggested that having more tasks at the right degree of difficulty but not so complicated that they might take a lot of time to solve was something that he would enjoy.

5.2.3.3 Communication Skills

Joe spoke quickly when nervous so he could not pronounce his words very well during presentations. Despite this, he thought that his presentation skills were adequate. ‘My presentation skills suffer as a result, but I find them okay’. Joe explained a situation in which he had to present his project during A-level studies. He said that it was not tedious, but rather a long process to get the audience to understand his project and that presenting was a rewarding experience. At the beginning of the interview Joe was nervous, but after some time he became more confident. Despite his speech difficulties, he preferred to communicate orally rather than in writing, as he could quickly rephrase his speech if someone did not understand him. He thought the processes of writing, editing, and rewriting took longer to communicate.

5.2.4 Coding Strategies

Joe’s coding strategy was based in trial and error for assignments. He started by understanding the assignment requirements and the problem that needed to be solved. ‘I try to get an initial idea as fast as possible’, he said. Then, he would code his initial ideas and spend some time fixing the codes, as he felt he learnt from his mistakes. Joe liked to do code optimisation rather than rewriting a new code, which could simplify functions to print values, for example. In addition, Joe used comments on his code frequently, once he finished each section. However, evidence from the Witter project showed that Joe’s code was not clear in some cases and could not always be understood. When error handling, Joe tried to find specific sections of code that he thought were problematic rather than scanning the entire code. He used print lines to track errors. In addition, Joe implemented Java exceptions to debug his Witter code. This strategy was advanced and the recommended method for identifying unexpected events when codes were compiled.

5.2.5 Mental Representation Strategies

When Joe was asked about his general problem-solving strategy, he said his approach to solving problems had changed since he studied the algorithm module (CS126). Instead of the trial-and-error approach that he used to do immediately without considering the data structure and algorithms, Joe instead spent considerable time investigating different algorithms before he solved a problem.

Joe responded that, for large programming assignments, he would break the assignment into subtasks and then prioritise the subtasks to implement the most im- portant methods. Then, he would think about coding classes and functions and think about connections between them to keep progressing.

Joe’s responses to the code-writing problem analyses showed that he understood the problem specifications and translated them into valid responses. For the first problem, array creation, Joe provided a code that was categorised at the second highest

possible SOLO category for the problem (Unistructural) as he missed some program constructs. In the second problem, linear search, Joe provided a valid response that was categorised at the highest possible SOLO category for the problem (Multistructural). For the last problem, recursion, Joe’s response included all required constructs and was categorised as Relational.

5.2.6 Witter

When Joe did the Witter project, he initially spent time thinking about the appro- priate algorithm. He thought that deciding the general algorithm for the assignment was important. Then, he spent some time analysing assignment functionalities and designing a graph to represent how data could be stored, retrieved, and deleted. He then considered which type of data structure he would use to build the project. Joe emphasised that time complexity was very important, and he would consider that in his project, which could be challenging in some cases.

However, Joe’s performance in Witter was the lowest among the participants and was below the class average as shown in Figure 5.7. For the User Store class, Joe implemented a binary tree ordered by date, which could be efficient. However, this approach became inefficient if a new user was added as the tree would need to rebalance every 100 users, which would increase time complexity once the tree expanded. Joe’s approach for the Follower class was an implementation of a two-dimensional array, which provided easy access but did not consider space complexity as the array size needed to be expanded. For the Weet class, Joe decided to implement a hash map that needed a second data structure to store and sort Weets, reducing time complexity. In this approach, finding a specific Weet required the user to search through all Weets, which made Joe’s approach slow. Thus, Joe’s overall approach was not appropriate for this type of problem, considering a large number of users and Weets, which could affect time and space complexity.

5.2.7 Summary

Joe performed better in mathematics modules, being in the top 10%, and his perfor- mance in programming was above the class average, achieving in the top 28%. Joe spent considerable time studying and learning programming, preferring to devote his time to solving complex problems and trying different algorithms. Based on the Wit- ter project evidence, Joe’s approach to programming lacked an understanding of how certain data structures could affect time and space complexity.

Joe’s responses to code-writing problems were not exceptional except his re- sponse to the recursion problem. Joe could understand and implement programming concepts. However, he seemed to need to understand how different data structures and algorithms might affect time and space complexity based on certain problems and considering other factors. During the interview, he mentioned that he tried to solve any problem as quickly as he could, which could sometimes affect performance, as he had to modify his approach to solving problems on many occasions.