From an early age, girls may opt out of Computer Science (CS) for not fitting the CS stereotypes of being male, asocial and technology-oriented. These stereotypes might be strengthened by children's books on programming, but little is known about this. Therefore, this paper explores the gender, social interactions and interests of characters illustrated in ten popular extracurricular Scratch and Python children's books. We found more masculine than feminine characters in all but one book. Furthermore, nearly half of the characters are illustrated alone, and 15% are interacting with computers & robots. Over two-thirds of the characters fit at least one stereotypical trait. With this paper, we aim to create awareness of stereotypes in CS books among creators, publishers and buyers. Making and using more inclusive CS materials will help close the gender gap.

Even though the field of Computer Science (CS) affects different aspects of society, several groups of society are underrepresented, including women and nonbinary people. Children might have different learning opportunities in CS due to their project preferences. Girls are likelier to work on stories and simple programs in Scratch, whereas boys tend to create games and more complex programs. We explore whether preferences and program implementation differ between genders within a story, game and visual adventure in Hedy, a gradual textual programming language. We analysed 14,233 programs within five Hedy levels created by 2,819 users who turned 10 to 14 in 2023. We found that boys, girls and nonbinary children worked most on the game adventure. Within the individual adventures, gender differences occur in all three adventures in the most elaborate Hedy level analysed. However, for some levels, no gender differences were found. Thus, programming assignments can be created in which children of different genders work on similar programs in terms of size and number of (unique) commands used.

Motivation. Variable naming practices are part of the software developer’s profession, influencing program comprehension and code quality. Yet, little is known about how variable naming practices are taught in beginner courses. Objective. This paper investigates naming beliefs, self-reported teaching practices, and observations regarding variable naming practices of teachers of introductory Python programming courses. Methods. We adopted an in-depth qualitative approach by interviewing ten teachers from secondary education and higher education and developed several themes in order to answer our research questions. Results. Among various opinions and practices, we found that teachers agree on using meaningful names, but have conflicting beliefs about what is meaningful. Moreover, the described teaching practices do not always match teacher’s views on meaningful names, and teachers rarely encourage students to use them. Instead, they express that naming practices should not be enforced and that students will develop them by example. Whereas some teachers report focusing solely on conventions, others deliberately dedicate time for students to engage with naming, create their own guidelines, provide continuous feedback, or include naming exercises on exams. Discussion. Naming practices do not seem to be deliberately taught, even though they influence program understanding and code quality. We also identified inconsistencies in teachers’ self-reported naming practices. As such, we encourage intentional conversations about naming practices in educational settings, specifically linking naming to code quality and readability. We see room for group and peer activities as a means to this end, as well as providing formative feedback dedicated to naming.

Background and Context. Increasing gender diversity in the field of Computer Science (CS) benefits the economy as well as gender equality. However, several obstacles - including underdeveloped CS interests, lack of programming experience, and a misfit with the stereotypes of computer scientists - prevent women from entering the field. Although these barriers develop from an early age, research focused on children is limited. Furthermore, limited work is done within European countries. Objectives. In this study, we research the interest children aged 7 to 14 have in a CS career. Additionally, we look into whether children with different characteristics have a different interest in CS. As such our research question: How does children's interest in a CS career differ based on their a) age, b) gender, c) computer interests, d) programming experience, and e) stereotypical beliefs? Method. We collected data from 200 children in a science museum located in the Netherlands. We gathered data on their gender, age, computer interests, programming experience, stereotypical beliefs and interest in becoming a programmer - as representative of a CS career. We used self-reported closed questions and reduced-length Child Implicit Association Tests. Findings. In general, the participating children are not interested in a CS career. We did find several characteristics related to a higher interest in a CS career: being a boy, having an interest in computers or video gaming, gaining programming experience at home or at an out-of-school activity, and the belief that programmers are social. Implications. To increase the participation of women in CS, we suggest motivating girls more to engage in computer and programming activities - especially out-of-school activities - while ensuring that these activities are gender inclusive.

We report results from a survey on spreadsheet use and experience with textual programming languages (n=49). We find significant correlations between self-reported formula experience, programming experience, and overall spreadsheet experience. We discuss the implications of our findings for spreadsheet research and end-user programming research, more generally.

In recent times, programming is increasingly taught to younger students in schools. While learning programming is known to be difficult, we can lighten the learning experience of this age group by adopting pedagogies that are common to them, but not as common in CS education. One of these pedagogies is Reading Aloud (RA), a familiar strategy when young children and beginners start learning how to read in their natural language. RA is linked with a better comprehension of text for beginner readers. We hypothesize that reading code aloud during introductory lessons will lead to better code comprehension. To this end, we design and execute a controlled experiment with the experimental group participants reading the code aloud during the lessons. The participants are 49 primary school students between 9 and 13 years old, who follow three lessons in programming in Python. The lessons are followed by a comprehension assessment based on Bloom's taxonomy. The results show that the students of the experimental group scored significantly higher in the Remembering-level questions compared to the ones in the control group. There is no significant difference between the two groups in their answers to the Understanding-level questions. Furthermore, the participants in both groups followed some of the instructed vocalizations more frequently such as the variable's assignment (is). Vocalizing the indentation spaces in a for -loop was among the least followed. Our paper suggests that using RA for teaching programming in schools will contribute to improving code comprehension with its effect on syntax remembering.

Microsoft VBA (Visual Basic for Applications) is a programming language widely used by end-user programmers, often alongside the popular spreadsheet software Excel. Together they form the popular Excel-VBA application ecosystem. Despite being popular, spreadsheets are known to be fault-prone, and to minimize risk of faults in the overall Excel-VBA ecosystem, it is important to support end-user programmers in improving the code quality of their VBA programs also, in addition to improving spreadsheet technology and practices. In traditional software development, automatic code inspection using static analysis tools has been found effective in improving code quality, but the practical relevance of this technique in an end-user development context remains unexplored. With the aim of popularizing it in the end-user community, in this paper we examine the relevance of automatic code inspection in terms of how inspection rules are perceived by VBA programmers. We conduct a qualitative study consisting of interviews with 14 VBA programmers, who share their perceptions about 20 inspection rules that most frequently detected code quality issues in an industrial dataset of 25 VBA applications, obtained from a financial services company. Results show that the 20 studied inspection rules can be grouped into three categories of user perceptions based on the type of issues they warn about: i) 11 rules that warn about serious problems which need fixing, ii) 7 rules that warn about bad practices which do not mandate fixing, and iii) 2 rules that warn about purposeful code elements rather than issues. Based on these perceptions, we conclude that automatic code inspection is considerably relevant in an end-user development context such as VBA. The perceptions also indicate which inspection rules deserve the most attention from interested researchers and tool developers. Lastly, our results also reveal 3 additional issue types that are not covered by the existing inspection rules, and are therefore impetus for creating new rules.

Blocks-based programming holds potential for end-user developers. Like all visual programming languages, blocks-based programming languages embody both a language design and a user interface design for the editing environment. For blocks-based languages, these designs are focused on learnability and low error rates, which makes them effective for education. For end-user developers who program as part of their professions, other characteristics of usability, like efficiency of use, will also be important. This paper presents a usability analysis, supported by a user study, of the editor design of current blocks-based programming systems, based on the Cognitive Dimensions of Notations framework, and we present design manoeuvres aimed at improving programming time and effort, program comprehension and programmer comfort.

The popularity of end-user programming has lead to diverse end-user development environments. Despite accurate and efficient tools available in such environments, end-user programmers often manually complete tasks. What are the consequences of rejecting these tools? In this paper, we answer this question by studying end-user programmers completing four tasks with and without tools. In analyzing 111 solutions to each of these tasks, we observe that neither tool use nor tool rejection was consistently more accurate or efficient. In some cases, tool users took nearly twice as long to solve problems and over-relied on tools, causing errors in 95% of solutions. Compared to manual task completion, the primary benefit of tool use was narrowing the kinds of errors that users made. We also observed that partial tool use can be worse than no tool use at all.

When teaching novices programming, misconceptions can occur. Misconception are incorrect beliefs about certain programming concept. For example, some novices think that a variable can hold multiple values, in the case of two consecutive assignment statements, such as x = 5; x = 7. While explaining variables introductory materials often use the metaphor of a box for a variable, which might contribute to the 'multiple values' hypothesis. To investigate this, we design and run a controlled experiment with 496 novice programmers, both children and adults. Half of our participants receive an introductory programming lesson in which we explain a variable as a box, while the other half of participants receive the explanation of a variable as being a label. They are subsequently questioned about their understanding of variables. Our results show that, for the simple questions involving one assignment, the box group performs better. However, for questions involving the misconception - with two consecutive assignment statements - the label group outperforms the box group. This however primarily occurs when considering variables of type string, for integers subjects interpret the statements as numeric values to be added.

Spreadsheets are widely used in industry. Spreadsheets also suffer from typical software engineering issues. Previous research shows that they contain code smells, lack documentation and tests, and have a long live span during which they are transferred multiple times among users. These transfers highlight the importance of spreadsheet comprehension. Therefore, in this paper, we analyze the effect of the organization of formulas on spreadsheet comprehension. To that end, we conduct a controlled experiment with 107 spreadsheet users, divided into two groups. One group receives a model where the formulas are organized such that all related components are grouped closely together, while the other group receives a model where the components are spread far and wide across the spreadsheet. All subjects perform the same set of comprehension tasks on their spreadsheet. The results indicate that the way formulas are located relative to each other in a spreadsheet, influences the performance of the subjects in their ability to comprehend and adapt the spreadsheet. Especially for the comprehension tasks, the subjects perform better on the model where the formulas were grouped closely together. For the adaptation tasks, we found that the length of the calculation chain influences the performance of the subjects more than the location of the formulas itself.