Modern programming frequently requires the use of APIs (Application Programming Interfaces). Yet many programmers struggle when trying to learn APIs. We ran an exploratory study in which we observed participants performing an API learning task. We analyze their processes using a proposed model of API learning, grounded in Cognitive Load Theory, Information Foraging Theory, and External Memory research. The results provide support for the model of API Learning and add new insights into the form and usage of external memory while learning APIs. Programmers quickly curated a set of API resources through Information Foraging which served as external memory and then primarily referred to these resources to meet information needs while coding.

Many children begin to learn to code in a self-directed context, such as by creating an animation, game or phone app. Recent research has begun to investigate and evaluate the results of this process: children's projects. However, little is known about the different trajectories novices have during the long-term process of self-directed programming learning. Our aim is to identify the existing types of trajectories and be able to determine a specific child's trajectory. If that trajectory does not lead to significant progress or continued motivation, we might be able to nudge them toward a different trajectory.

Coding often relies on Application Programming Interfaces (APIs), yet APIs are hard to learn, use, and debug. Debugging is a notoriously difficult skill, and is made even more challenging by the complexities of APIs. Yet, little work has focused on support for debugging code that relies on an API. In this poster, we present an early design of debugging worked examples to support programmers in debugging an unfamiliar API. In our formative study, novices could access the information through a prototype tool. This works-in-progress presents preliminary data about programmers' use of this tool and the implications for future work.

Though support for learning computing in schools is growing, many children still begin learning to program without formal support in open-ended programming environments. While researchers have evaluated the final code of these types of projects, we know little about how users’ behaviors and usage of support tools relate to understanding. We ran a study where participants had open-ended programming time with access to one of two support tools: suggestions or tutorials. Participants then completed four tasks which required understanding of the suggestion or tutorial content. We did not find an effect of suggestions compared to tutorials on knowledge application, but we did find that many participants who performed better tended to explore more of the interface, code behaviors, and support tools. Our results suggest that future tools for encouraging learning during open-ended programming should likely focus on supporting users who tend to explore less on their own.

In today’s world, learning new APIs (Application Programming Interfaces) is fundamental to being a programmer. Prior research suggests that programmers learn on-the-fly while they work on other project-related tasks. Yet, this process is often inefficient. This inefficiency has inspired research seeking to understand and improve API learnability. While the existing research has provided insight into API learning, we still have a fractured understanding of the process of learning a new API. In this paper, we take the first steps towards developing a theoretical model of API learning by combining predictions from Information Foraging Theory (IFT) to describe information search behavior, Cognitive Load Theory (CLT) to describe learning, and External Memory (EM) to describe how API learners augment their short term memories. Our proposed model is consistent with existing research on barriers to learning APIs and helps to provide explanations for these barriers as well as suggest new research directions.

APIs (Application Programming Interfaces) and code libraries have become highly integrated into the programming process. They allow programmers to reuse large segments of functionalities. However, as free and often open-source commodities, the support for programmers to learn how to use these valuable resources is not always complete. Researchers have repeatedly found that API learning is a highly problematic process with many barriers. However, much of the work on the difficulties using and learning APIs has relied on retrospective descriptions of the process or questions programmers post on forums. Furthermore, these explorations of difficulties in learning APIs have not taken into account theories about learning or information foraging. In this works-in-progress poster, we present an early evaluation of a model that describes API learning using both information foraging and cognitive load theory.

Independent novice programmers in open-ended contexts rely on help systems to support their learning. These help systems are often laboriously hand-authored by experts. This paper describes a semi-automatic process for the creation of a suggestion-based help system. We demonstrate and evaluate the potential utility of our approach within a blocks-based programming environment for children. With less human effort per suggestion, our approach generated a set of suggestions comparable to a hand-authored set and a set of original suggestions. We ran a study to explore the number and types of suggestions children received, accessed, and used. In 30 minutes, children on average received 9 suggestions, accessed 2.6 suggestions, and inserted 0.8 new concepts from suggestions.

Many systems aim to support programmers within a programming context, whether they recommend API methods, example code, or hints to help novices solve a task. The recommendations may change based on the user's code context, history, or the source of the recommendation content. They are designed to primarily support users in improving their code or working toward a task solution. The recommendations themselves rarely provide support for a user to interact with them directly, especially in ways that benefit the knowledge or understanding of the user. This poster presents a vision and preliminary designs for three ways a user might learn from interactions with suggested examples: describing examples, providing detailed relevance feedback, and selective visualization and tinkering.

Programmers, especially novices, often have difficulty learning new APIs (Application Programming Interfaces). Existing research has not fully addressed novice programmers' unawareness of all available API methods. To help novices discover new and appropriate uses for API methods, we designed a system called the Example Guru. The Example Guru suggests context-relevant API methods based on each programmer's code. The suggestions provide contrasting examples to demonstrate how to use the API methods. To evaluate the effectiveness of the Example Guru, we ran a study comparing novice programmers' use of the Example Guru and documentation-inspired API information. We found that twice as many participants accessed the Example Guru suggestions compared to documentation and that participants used more than twice as many new API methods after accessing suggestions than documentation.

There are a variety of learning resources with the potential to support children in learning programming independently. While many of them have been evaluated in laboratory settings, we know little about how children choose to use these resources on their own. We conducted a study organized around a film festival to explore children's open-ended use of four different learning supports: tutorials, code puzzles, in-application documentation and code suggestions. The study began with a workshop to introduce the programming environment and available tools, continued through two weeks of home use, and culminated in a film festival. Results suggest that participants leveraged in-context forms of help most frequently, but valued documentation for question-answering and suggestions for opportunistic learning.

Programmers of all experience levels attempt to leverage code snippets with varying success, often as reminders or to learn new skills. To date, little work has explored the specific elements within code snippets that are challenging for novices. Comparing how novices and experts recall code snippets may expose what code elements programmers focus on and inform new approaches for improving examples for inexperienced programmers. We conducted a study, inspired by past novice-expert studies, in which we asked everyday, occasional, and non-programmers to study and then recall code snippets. The key distinctions and similarities in the types and locations of recalled tokens provide insight for a set of recommendations that could improve the presentation of code snippets.

The frequency of programmers attempting to use code examples has prompted significant research on code examples for text languages. Yet, few systems address issues in novice use of examples in blocks programming languages. Research has begun to explore the difficulties novices have using examples in blocks programming languages. This work addresses one such issue: novices often do not notice or focus on the important elements in examples. This work-in-progress poster presents lessons learned on how to design examples that help novices notice critical elements.

Computer science education has recently begun expanding in middle and high schools, but many students still do not have access to computer science education in a classroom [1]. As a result, many children learn programming outside of formal education using novice programming environments and games such as Scratch [2] and Code.org [3].

Many novice programmers use blocks-based programming environments outside of classrooms, due to a lack of computer science education in schools. Many solutions for supporting learning in these environments are out of the context of the programming environment and the user's project. In this poster, we present a way of expanding novice users' knowledge of a blocks-based programming environment by suggesting examples during open-ended programming.

Both experienced and novice programmers use examples while programming, whether from tutorials, forums, or source code. Novice programmers, however, often find it challenging to use unfamiliar example code. Little is known about the challenges of using examples, making it difficult to design support for novice programmer example use. We ran an exploratory study of novices using examples to complete programming tasks. To analyze programming behaviors, we define the `realization point' as the time when the participants discover the crucial concept in an example. Our results show that participants spent more time after the realization point using the example than they did identifying which part of the example to use. We describe hurdles and strategies, types of tasks behaviors, and finally, implications for supporting example use.

I propose a crowdsourced large-scale feedback system for novice programmers powered by experienced programmers, or code reviewers (who I will refer to as “reviewers”). Reviewers have two jobs: making suggestions to improve novice programs and authoring rules that generalize when a program should receive their suggestion. A rule is a heuristic program that can be run on a novice program to determine whether the system should present the suggestion to the novice programmer. For example, imagine a novice program that contains a certain method call repeated three times in a row. A reviewer might suggest to improve the program by replacing the three identical method calls with a loop. The reviewer would then author a rule that checks whether code in other novice programs also contains repeated lines of code. If the rule determines that a novice program does have repeated code, the system would present the suggestion to the novice programmer to use a loop by showing an example of correct loop usage.

One way to provide feedback to independent novice programmers is by leveraging experienced programmers as code reviewers. To provide this feedback at a large scale, experienced programmers can author heuristic programs, or rules, that automatically determine whether a novice program should receive certain feedback. This work presents the lessons learned from designing a tool to enable rule authoring.

Novice programmers may lack the experience to recognize opportunities to either improve their code or apply unfamiliar programming constructs. Yet, these opportunities are often clear to an experienced programmer. In this paper, we describe an exploratory study investigating 1) the potential value of the suggestions experienced programmers make to novice programmers and 2) the ways experienced programmers envision identifying other programs that would benefit from the same suggestion. The results of our study suggest that experienced programmers make suggestions that can introduce new programming constructs to novice programmers. The participants in our study most commonly made suggestions that improve the code quality of novice programs, rather than changing their output. Furthermore, experienced programmers could often state a simple heuristic rule to use in identifying other novice programs that would benefit from their suggestion. Participants were able to author the rules in pseudocode, mostly using combinations of iteration and comparison to find patterns of problematic code. However, based on a test implementation of a selected set of rules for these suggestions, we conclude that support for improving rules through review and community input will be valuable.

To facilitate long-term engagement in programming for middle school children, we developed the Looking Glass Community. The Community includes both a website and integrated access to community resources within the novice programming environment, Looking Glass. We discuss how we designed the Community to support engagement by providing a source for initial ideas, support for learning new skills, positive feedback, and role models.