arXiv subjects

Marvin Wyrich

Publications and source records attributed to Marvin Wyrich.

At least 19 recordsLinked to original sources

arXiv2026

Motivations and Barriers to Communicating Software Engineering Research: Insights from Early Career Researchers

Science communication is increasingly becoming a part of modern research careers, involving researchers to disseminate knowledge, engage broader communities, and increase the societal impact of their work. Despite its growing importance, little is known about how early-career software engineering researchers perceive and navigate science communication in practice. In this paper, we investigate how PhD students in software engineering experience science communication. We conducted semi-structured interviews with 18 doctoral candidates from diverse international backgrounds. Using thematic analysis, we examine three interconnected dimensions: motivations, communication channels, and barriers. Our findings reveal a strong tension between aspiration and practice. Participants were highly motivated to engage in science communication due to opportunities for collaboration, professional recognition, broader impact, and advocacy for themselves and their research. However, translating these motivations into action was frequently constrained by social anxiety, uncertainty regarding appropriate audiences and communication venues, limited feedback mechanisms, insufficient institutional guidance, and challenges associated with navigating an increasingly fragmented communication landscape. Our findings highlight the need for tailored, balanced support systems that empower software engineering PhD students to engage in science communication effectively and confidently across diverse cultural and institutional environments. We outline practical implications that offer initial guidance for addressing these challenges in future work.

cs.SE↗

arXiv2026

Predicting Program Comprehension with Foundation Models of Human Cognition

Software engineering depends on the ability of developers to understand code, yet predicting how they do so remains an open challenge despite decades of research. Existing approaches rely either on simplified proxy measures that limit accuracy or on non-trivial measurements requiring elaborate experimental setups that are difficult to scale and apply in practice. In contrast, recent work in psychology suggests an alternative perspective: Instead of modeling task-specific phenomena directly, human behavior can be captured through cognitive regularities learned from large-scale behavioral data. This idea treats complex human behavior as the observable outcome of underlying cognitive processes that manifest consistently across tasks and domains. In this paper, we explore this perspective in the context of program comprehension. We evaluate Centaur, a foundation model trained on 160 general psychological experiments, on 9 previously published program-comprehension studies. We assess how well its predicted response distributions align with human response data and compare Centaur's performance to its base model, Llama 3.1. To better understand the source of its performance, we conduct ablation studies to isolate the contribution of different sources of information, such as the code artifacts, task-related context, and prior trials and participant responses. In a nutshell, we find that Centaur more closely aligns with human response patterns than its base model, is significantly less reliant on information from prior trials and responses, and benefits more from task-related information. These findings suggest that behavioral patterns learned from general psychological data can transfer to complex software engineering tasks such as program comprehension. More broadly, they point toward foundation models of human cognition as a basis for modeling developer behavior in software engineering.

cs.SE↗

arXiv2026

A Mechanistic Lens on Semantic Conflicts: Using Activation Patching to Understand LLM Behavior

Large language models (LLMs) are increasingly used in software-engineering tasks processing executable code and non-executable semantic cues such as comments or identifiers. These two sources can conflict when semantic cues suggest different program behavior than the code itself. It remains unclear how such semantic conflicts affect LLM behavior and which source dominates their outputs. We present the first controlled, mechanistic study of LLM behavior under semantic conflicts. To this end, we construct 45 Python snippet triplets that isolate conflicts by varying either semantic cues or implementation while keeping token-aligned pairs for causal intervention. We evaluate four open-weight LLMs on two tasks (output prediction and unit-test generation) using behavioral performance measures and residual-stream activation patching to identify token-layer states that causally contribute to behavioral differences between aligned and conflicting inputs. Our results show that semantic conflicts significantly reduce execution-grounded correctness in both tasks and that all tested LLMs often follow misleading semantic cues. Residual-stream activation patching reveals a consistent pattern for final-output prediction: The changed cue/code region and a small set of intermediate tokens carry most of the recoverable causal signal before aggregation near the output readout. For unit-test generation, this pattern extends beyond the prompt, showing that conflict-related information is recoverable at generated sites before producing expected values. Overall, our findings show that semantic conflicts affect program comprehension and downstream tasks, with relevant information concentrated in a small number of causally active residual-stream states, and demonstrate a framework for mechanistically analyzing how LLMs integrate code-related information under controlled semantic variations.

cs.SE↗

arXiv2026

Software Engineering Podcasts: An Empirical Study of Their Potential as a Research Resource

Podcasts have become an increasingly popular medium for knowledge sharing within the software engineering (SE) community, offering insights into industry developments and the perspectives of professionals with different backgrounds. As this medium grows, it presents a potentially valuable resource not only for practitioners but also for researchers seeking to understand the evolving field. However, little is known about the actual content of SE podcasts or how they are perceived and used by researchers. This study systematically explores the SE podcast landscape, analyzing its content and surveying researchers to assess how podcasts can serve as a meaningful resource for advancing empirical software engineering research.

cs.SE↗

arXiv2026

Harnessing Hype to Teach Empirical Thinking: An Experience With AI Coding Assistants

Software engineering students often struggle to appreciate empirical methods and hypothesis-driven inquiry, especially when taught in theoretical terms. This experience report explores whether grounding empirical learning in hype-driven technologies can make these concepts more accessible and engaging. We conducted a one-semester seminar framed around the currently popular topic of AI coding assistants, which attracted unusually high student interest. The course combined hands-on sessions using AI coding assistants with small, student-designed empirical studies. Classroom observations and survey responses suggest that the hype topic sparked curiosity and critical thinking. Students engaged with the AI coding assistants while questioning their limitations -- developing the kind of empirical thinking needed to assess claims about emerging technologies. Key lessons: (1) Hype-driven topics can lower barriers to abstract concepts like empirical research; (2) authentic hands-on development tasks combined with ownership of inquiry foster critical engagement; and (3) a single seminar can effectively teach both technical and research skills.

cs.SE↗

arXiv2026

Constructive Patterns for Human-Centered Tech Hiring

[Context] Online Recruitment and Selection (R&S) processes are often the first point of contact between early-career software engineers and the tech industry. Yet many candidates experience these processes as opaque, inefficient, or even discouraging. While prior research has extensively documented the flaws and biases in online tech hiring, little is known about the practices that create positive candidate experiences. [Objective & Method] This paper explores such practices, referred to as Constructive Patterns (CPs), from the perspective of early-career software engineers. Guided by Applicant Attribution-Reaction Theory, we conducted 22 semi-structured interviews in which participants collectively described over 470 online R&S experiences. [Results] Through thematic analysis, we identified 22 CPs that reflect positive practices such as comprehensive and transparent job advertisements (CP01), specific and developmental feedback (CP03), humanized and respectful interaction (CP06), and framing the process as a two-way street (CP18). [Conclusion] Our findings extend the conversation on tech hiring beyond diagnosing dysfunctions toward designing for human-centered and growth-oriented candidate experiences. The resulting catalog of CPs provides a concrete and empirically grounded resource for organizations seeking to attract and support early-career software engineers more effectively.

cs.SE↗

arXiv2025

What's in a Software Engineering Job Posting?

A well-rounded software engineer is often defined by technical prowess and the ability to deliver on complex projects. However, the narrative around the ideal Software Engineering (SE) candidate is evolving, suggesting that there is more to the story. This article explores the non-technical aspects emphasized in SE job postings, revealing the sociotechnical and organizational expectations of employers. Our Thematic Analysis of 100 job postings shows that employers seek candidates who align with their sense of purpose, fit within company culture, pursue personal and career growth, and excel in interpersonal interactions. This study contributes to ongoing discussions in the SE community about the evolving role and workplace context of software engineers beyond technical skills. By highlighting these expectations, we provide relevant insights for researchers, educators, practitioners, and recruiters. Additionally, our analysis offers a valuable snapshot of SE job postings in 2023, providing a scientific record of prevailing trends and expectations.

cs.SE↗

arXiv2025

From Developer Pairs to AI Copilots: A Comparative Study on Knowledge Transfer

Knowledge transfer is fundamental to human collaboration and is therefore common in software engineering. Pair programming is a prominent instance. With the rise of AI coding assistants, developers now not only work with human partners but also, as some claim, with AI pair programmers. Although studies confirm knowledge transfer during human pair programming, its effectiveness with AI coding assistants remains uncertain. To analyze knowledge transfer in both human-human and human-AI settings, we conducted an empirical study where developer pairs solved a programming task without AI support, while a separate group of individual developers completed the same task using the AI coding assistant GitHub Copilot. We extended an existing knowledge transfer framework and employed a semi-automated evaluation pipeline to assess differences in knowledge transfer episodes across both settings. We found a similar frequency of successful knowledge transfer episodes and overlapping topical categories across both settings. Two of our key findings are that developers tend to accept GitHub Copilot's suggestions with less scrutiny than those from human pair programming partners, but also that GitHub Copilot can subtly remind developers of important code details they might otherwise overlook.

cs.SE↗

arXiv2025

The Silent Scientist: When Software Research Fails to Reach Its Audience

If software research were a performance, it would be a thoughtful theater play -- full of rich content but confined to the traditional stage of academic publishing. Meanwhile, its potential audience is immersed in engaging on-demand experiences, leaving the theater half-empty, and the research findings lost in the wings. As long as this remains the case, discussions about research relevance and impact lack meaningful context.

cs.SE↗

arXiv2024

Human Factors in Model-Driven Engineering: Future Research Goals and Initiatives for MDE

Purpose: Software modelling and Model-Driven Engineering (MDE) is traditionally studied from a technical perspective. However, one of the core motivations behind the use of software models is inherently human-centred. Models aim to enable practitioners to communicate about software designs, make software understandable, or make software easier to write through domain-specific modelling languages. Several recent studies challenge the idea that these aims can always be reached and indicate that human factors play a role in the success of MDE. However, there is an under-representation of research focusing on human factors in modelling. Methods: During a GI-Dagstuhl seminar, topics related to human factors in modelling were discussed by 26 expert participants from research and industry. Results: In breakout groups, five topics were covered in depth, namely modelling human aspects, factors of modeller experience, diversity and inclusion in MDE, collaboration and MDE, and teaching human-aware MDE. Conclusion: We summarise our insights gained during the discussions on the five topics. We formulate research goals, questions, and propositions that support directing future initiatives towards an MDE community that is aware of and supportive of human factors and values.

cs.SE↗

arXiv2024

Evidence Tetris in the Pixelated World of Validity Threats

Valid empirical studies build confidence in scientific findings. Fortunately, it is now common for software engineering researchers to consider threats to validity when designing their studies and to discuss them as part of their publication. Yet, in complex experiments with human participants, there is often an overwhelming number of intuitively plausible threats to validity -- more than a researcher can feasibly cover. Therefore, prioritizing potential threats to validity becomes crucial. We suggest moving away from relying solely on intuition for prioritizing validity threats, and propose that evidence on the actual impact of suspected threats to validity should complement intuition.

cs.SE↗

arXiv2024

Apples, Oranges, and Software Engineering: Study Selection Challenges for Secondary Research on Latent Variables

Software engineering (SE) is full of abstract concepts that are crucial for both researchers and practitioners, such as programming experience, team productivity, code comprehension, and system security. Secondary studies aimed at summarizing research on the influences and consequences of such concepts would therefore be of great value. However, the inability to measure abstract concepts directly poses a challenge for secondary studies: primary studies in SE can operationalize such concepts in many ways. Standardized measurement instruments are rarely available, and even if they are, many researchers do not use them or do not even provide a definition for the studied concept. SE researchers conducting secondary studies therefore have to decide a) which primary studies intended to measure the same construct, and b) how to compare and aggregate vastly different measurements for the same construct. In this experience report, we discuss the challenge of study selection in SE secondary research on latent variables. We report on two instances where we found it particularly challenging to decide which primary studies should be included for comparison and synthesis, so as not to end up comparing apples with oranges. Our report aims to spark a conversation about developing strategies to address this issue systematically and pave the way for more efficient and rigorous secondary studies in software engineering.

cs.SE↗

arXiv2024

Beyond Self-Promotion: How Software Engineering Research Is Discussed on LinkedIn

LinkedIn is the largest professional network in the world. As such, it can serve to build bridges between practitioners, whose daily work is software engineering (SE), and researchers, who work to advance the field of software engineering. We know that such a metaphorical bridge exists: SE research findings are sometimes shared on LinkedIn and commented on by software practitioners. Yet, we do not know what state the bridge is in. Therefore, we quantitatively and qualitatively investigate how SE practitioners and researchers approach each other via public LinkedIn discussions and what both sides can contribute to effective science communication. We found that a considerable proportion of LinkedIn posts on SE research are written by people who are not the paper authors (39%). Further, 71% of all comments in our dataset are from people in the industry, but only every second post receives at least one comment at all. Based on our findings, we formulate concrete advice for researchers and practitioners to make sharing new research findings on LinkedIn more fruitful.

cs.SE↗

arXiv2023

Source Code Comprehension: A Contemporary Definition and Conceptual Model for Empirical Investigation

Be it in debugging, testing, code review or, more recently, pair programming with AI assistance: in all these activities, software engineers need to understand source code. Accordingly, plenty of research is taking place in the field to find out, for example, what makes code easy to understand and which tools can best support developers in their comprehension process. And while any code comprehension researcher certainly has a rough idea of what they mean when they mention a developer having a good understanding of a piece of code, to date, the research community has not managed to define source code comprehension as a concept. Instead, in primary research on code comprehension, an implicit definition by task prevails, i.e., code comprehension is what the experimental tasks measure. This approach has two negative consequences. First, it makes it difficult to conduct secondary research. Currently, each code comprehension primary study uses different comprehension tasks and measures, and thus it is not clear whether different studies intend to measure the same construct. Second, authors of a primary study run into the difficulty of justifying their design decisions without a definition of what they attempt to measure. An operationalization of an insufficiently described construct occurs, which poses a threat to construct validity. The task of defining code comprehension considering the theory of the past fifty years is not an easy one. Nor is it a task that every author of a primary study must accomplish on their own. Therefore, this paper constitutes a reference work that defines source code comprehension and presents a conceptual framework in which researchers can anchor their empirical code comprehension research.

cs.SE↗

arXiv2023

40 Years of Designing Code Comprehension Experiments: A Systematic Mapping Study

The relevance of code comprehension in a developer's daily work was recognized more than 40 years ago. Consequently, many experiments were conducted to find out how developers could be supported during code comprehension and which code characteristics contribute to better comprehension. Today, such studies are more common than ever. While this is great for advancing the field, the number of publications makes it difficult to keep an overview. Additionally, designing rigorous code comprehension experiments with human participants is a challenging task, and the multitude of design options can make it difficult for researchers, especially newcomers to the field, to select a suitable design. We therefore conducted a systematic mapping study of 95 source code comprehension experiments published between 1979 and 2019. By structuring the design characteristics of code comprehension studies, we provide a basis for subsequent discussion of the huge diversity of design options in the face of a lack of basic research on their consequences and comparability. We describe what topics have been studied, as well as how these studies have been designed, conducted, and reported. Frequently chosen design options and deficiencies are pointed out to support researchers of all levels of domain expertise in designing their own studies.

cs.SE↗

arXiv2023

Resist the Hype! Practical Recommendations to Cope With Résumé-Driven Development

Technology trends play an important role in the hiring process for software and IT professionals. In a recent study of 591 software professionals in both hiring (130) and technical (558) roles, we found empirical support for a tendency to overemphasize technology trends in résumés and the application process. 60% of the hiring professionals agreed that such trends would influence their job advertisements. Among the software professionals, 82% believed that using trending technologies in their daily work would make them more attractive for potential future employers. This phenomenon has previously been reported anecdotally and somewhat humorously under the label Résumé-Driven Development (RDD). Our article seeks to initiate a more serious debate about the consequences of RDD on software development practice. We explain how the phenomenon may constitute a harmful self-sustaining dynamic, and provide practical recommendations for both the hiring and applicant perspectives to change the current situation for the better.

cs.SE↗

arXiv2023

Evidence Profiles for Validity Threats in Program Comprehension Experiments

Searching for clues, gathering evidence, and reviewing case files are all techniques used by criminal investigators to draw sound conclusions and avoid wrongful convictions. Similarly, in software engineering (SE) research, we can develop sound methodologies and mitigate threats to validity by basing study design decisions on evidence. Echoing a recent call for the empirical evaluation of design decisions in program comprehension experiments, we conducted a 2-phases study consisting of systematic literature searches, snowballing, and thematic synthesis. We found out (1) which validity threat categories are most often discussed in primary studies of code comprehension, and we collected evidence to build (2) the evidence profiles for the three most commonly reported threats to validity. We discovered that few mentions of validity threats in primary studies (31 of 409) included a reference to supporting evidence. For the three most commonly mentioned threats, namely the influence of programming experience, program length, and the selected comprehension measures, almost all cited studies (17 of 18) did not meet our criteria for evidence. We show that for many threats to validity that are currently assumed to be influential across all studies, their actual impact may depend on the design and context of each specific study. Researchers should discuss threats to validity within the context of their particular study and support their discussions with evidence. The present paper can be one resource for evidence, and we call for more meta-studies of this type to be conducted, which will then inform design decisions in primary studies. Further, although we have applied our methodology in the context of program comprehension, our approach can also be used in other SE research areas to enable evidence-based experiment design decisions and meaningful discussions of threats to validity.

cs.SE↗

arXiv2023

Teaching Computer Science Students to Communicate Scientific Findings More Effectively

Science communication forms the bridge between computer science researchers and their target audience. Researchers who can effectively draw attention to their research findings and communicate them comprehensibly not only help their target audience to actually learn something, but also benefit themselves from the increased visibility of their work and person. However, the necessary skills for good science communication must also be taught, and this has so far been neglected in the field of software engineering education. We therefore designed and implemented a science communication seminar for bachelor students of computer science curricula. Students take the position of a researcher who, shortly after publication, is faced with having to draw attention to the paper and effectively communicate the contents of the paper to one or more target audiences. Based on this scenario, each student develops a communication strategy for an already published software engineering research paper and tests the resulting ideas with the other seminar participants. We explain our design decisions for the seminar, and combine our experiences with responses to a participant survey into lessons learned. With this experience report, we intend to motivate and enable other lecturers to offer a similar seminar at their university. Collectively, university lecturers can prepare the next generation of computer science researchers to not only be experts in their field, but also to communicate research findings more effectively.

cs.CY↗