Towards a Theory of Software Development Expertise

Software development includes diverse tasks such as implementing new features, analyzing requirements, and fixing bugs. Being an expert in those tasks requires a certain set of skills, knowledge, and experience. Several studies investigated individual aspects of software development expertise, but what is missing is a comprehensive theory. We present a first conceptual theory of software development expertise that is grounded in data from a mixed-methods survey with 335 software developers and in literature on expertise and expert performance. Our theory currently focuses on programming, but already provides valuable insights for researchers, developers, and employers. The theory describes important properties of software development expertise and which factors foster or hinder its formation, including how developers' performance may decline over time. Moreover, our quantitative results show that developers' expertise self-assessments are context-dependent and that experience is not necessarily related to expertise.Comment: 14 pages, 5 figures, 26th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE 2018), ACM, 201

Four approaches to teaching programming

Based on a survey of literature, four different approaches to teaching introductory programming are identified and described. Examples of the practice of each approach are identified representing procedural, visual, and object-oriented programming language paradigms. Each approach is then further analysed, identifying advantages and disadvantages for the student and the teacher. The first approach, code analysis, is analogous to reading before writing, that is, recognising the parts and what they mean. It requires learners to analyse and understand existing code prior to producing their own. An alternative is the building blocks approach, analogous to learning vocabulary, nouns and verbs, before constructing sentences. A third approach is identified as simple units in which learners master solutions to small problems before applying the learned logic to more complex problems. The final approach, full systems, is analogous to learning a foreign language by immersion whereby learners design a solution to a non-trivial problem and the programming concepts and language constructs are introduced only when the solution to the problem requires their application. The conclusion asserts that competency in programming cannot be achieved without mastering each of the approaches, at least to some extent. Use of the approaches in combination could provide novice programmers with the opportunities to acquire a full range of knowledge, understanding, and skills. Several orders for presenting the approaches in the classroom are proposed and analysed reflecting the needs of the learners and teachers. Further research is needed to better understand these and other approaches to teaching programming, not in terms of learner outcomes, but in terms of teachers’ actions and techniques employed to facilitate the construction of new knowledge by the learners. Effective classroom teaching practices could be informed by further investigations into the effect on progression of different toolset choices and combinations of teaching approache

Happiness and the productivity of software engineers

Software companies and startups often follow the idea of flourishing happiness among developers. Perks, playground rooms, free breakfast, remote office options, sports facilities near the companies, company retreats, you name it. The rationale is that happy developers should be more productive and also retained. But is it the case that happy software engineers are more productive? Moreover, are perks the way to go to make developers happy? Are developers happy at all? What are the consequences of unhappiness among software engineers? These questions are important to ask both from the perspective of productivity and from the perspective of sustainable software development and well-being in the workplace. Managers, team leaders, as well as team members should be interested in these concerns. This chapter provides an overview of our studies on the happiness of software developers. You will learn why it is important to make software developers happy, how happy they really are, what makes them unhappy, and what is expected regarding happiness and productivity while developing software.Comment: 12 pages, 2 figures. To appear in Rethinking Productivity in Software Engineering, edited by Caitlin Sadowski and Thomas Zimmermann. arXiv admin note: text overlap with arXiv:1707.0043

Finding the traces of behavioral and cognitive processes in big data and naturally occurring datasets.

Today, people generate and store more data than ever before as they interact with both real and virtual environments. These digital traces of behavior and cognition offer cognitive scientists and psychologists an unprecedented opportunity to test theories outside the laboratory. Despite general excitement about big data and naturally occurring datasets among researchers, three gaps stand in the way of their wider adoption in theory-driven research: the imagination gap, the skills gap, and the culture gap. We outline an approach to bridging these three gaps while respecting our responsibilities to the public as participants in and consumers of the resulting research. To that end, we introduce Data on the Mind ( http://www.dataonthemind.org ), a community-focused initiative aimed at meeting the unprecedented challenges and opportunities of theory-driven research with big data and naturally occurring datasets. We argue that big data and naturally occurring datasets are most powerfully used to supplement-not supplant-traditional experimental paradigms in order to understand human behavior and cognition, and we highlight emerging ethical issues related to the collection, sharing, and use of these powerful datasets

Instructional strategies and tactics for the design of introductory computer programming courses in high school

This article offers an examination of instructional strategies and tactics for the design of introductory computer programming courses in high school. We distinguish the Expert, Spiral and Reading approach as groups of instructional strategies that mainly differ in their general design plan to control students' processing load. In order, they emphasize topdown program design, incremental learning, and program modification and amplification. In contrast, tactics are specific design plans that prescribe methods to reach desired learning outcomes under given circumstances. Based on ACT* (Anderson, 1983) and relevant research, we distinguish between declarative and procedural instruction and present six tactics which can be used both to design courses and to evaluate strategies. Three tactics for declarative instruction involve concrete computer models, programming plans and design diagrams; three tactics for procedural instruction involve worked-out examples, practice of basic cognitive skills and task variation. In our evaluation of groups of instructional strategies, the Reading approach has been found to be superior to the Expert and Spiral approaches

Early Developmental Activities and Computing Proficiency

As countries adopt computing education for all pupils from primary school upwards, there are challenging indicators: significant proportions of students who choose to study computing at universities fail the introductory courses, and the evidence for links between formal education outcomes and success in CS is limited. Yet, as we know, some students succeed without prior computing experience. Why is this? <br/><br/> Some argue for an innate ability, some for motivation, some for the discrepancies between the expectations of instructors and students, and some – simply – for how programming is being taught. All agree that becoming proficient in computing is not easy. Our research takes a novel view on the problem and argues that some of that success is influenced by early childhood experiences outside formal education. <br/><br/> In this study, we analyzed over 1300 responses to a multi-institutional and multi-national survey that we developed. The survey captures enjoyment of early developmental activities such as childhood toys, games and pastimes between the ages 0 — 8 as well as later life experiences with computing. We identify unifying features of the computing experiences in later life, and attempt to link these computing experiences to the childhood activities. <br/><br/> The analysis indicates that computing proficiency should be seen from multiple viewpoints, including both skill-level and confidence. It shows that particular early childhood experiences are linked to parts of computing proficiency, namely those related to confidence with problem solving using computing technology. These are essential building blocks for more complex use. We recognize issues in the experimental design that may prevent our data showing a link between early activities and more complex computing skills, and suggest adjustments. Ultimately, it is hoped that this line of research will feed in to early years and primary education, and thereby improve computing education for all

Towards a debugging tutor for object-oriented environments

Programming has provided a rich domain for Artificial Intelligence in Education and many systems have been developed to advise students about the bugs in their programs, either during program development or post-hoc. Surprisingly few systems have been developed specifically to teach debugging. Learning environment builders have assumed that either the student will be taught these elsewhere or thatthey will be learnt piecemeal without explicit advice.This paper reports on two experiments on Java debugging strategy by novice programmers and discusses their implications for the design of a debugging tutor for Java that pays particular attention to how students use the variety of program representations available. The experimental results are in agreement with research in the area that suggests that good debugging performance is associated with a balanced use ofthe available representations and a sophisticated use of the debugging step facility which enables programmers to detect and obtain information from critical momentsin the execution of the program. A balanced use of the available representations seemsto be fostered by providing representations with a higher degree of dynamic linkingas well as by explicit instruction about the representation formalism employed in the program visualisations

Scientific requirements for an engineered model of consciousness

The building of a non-natural conscious system requires more than the design of physical or virtual machines with intuitively conceived abilities, philosophically elucidated architecture or hardware homologous to an animal’s brain. Human society might one day treat a type of robot or computing system as an artificial person. Yet that would not answer scientific questions about the machine’s consciousness or otherwise. Indeed, empirical tests for consciousness are impossible because no such entity is denoted within the theoretical structure of the science of mind, i.e. psychology. However, contemporary experimental psychology can identify if a specific mental process is conscious in particular circumstances, by theory-based interpretation of the overt performance of human beings. Thus, if we are to build a conscious machine, the artificial systems must be used as a test-bed for theory developed from the existing science that distinguishes conscious from non-conscious causation in natural systems. Only such a rich and realistic account of hypothetical processes accounting for observed input/output relationships can establish whether or not an engineered system is a model of consciousness. It follows that any research project on machine consciousness needs a programme of psychological experiments on the demonstration systems and that the programme should be designed to deliver a fully detailed scientific theory of the type of artificial mind being developed – a Psychology of that Machine