Fluid source code views for just in-time comprehension

non-peer-reviewedThe use of modern programming paradigms and technologies,such as object orientation, inheritance, polymorphism and aspect orientation, facilitate a number of important software engineeringbenefits. Concerns can be better separated, software is more modular and reusable, and evolution is a simpler and less invasive process. However these advances in programming technology also negatively impact the ability of software engineers to read, navigate and comprehend source code. The definition and execution flow of program operations is more fragmented and relationships between software units are often implicit and difficult to determine. In this paper we propose and present some initial work on a new direction in source code document presentation called fluid source code views. Fluid source code views enable programmers working on a primary source code document to fluidly shift attention to related supporting material in a contextual manner. This reduces the need for programmers to navigate and presents code in a manner more efficient and fitting in terms of comprehension. We very briefly discuss the motivation behind fluid source code views, present the approach and discuss both the potential advantages and disadvantages of this technology

How software engineering research aligns with design science: A review

Background: Assessing and communicating software engineering research can be challenging. Design science is recognized as an appropriate research paradigm for applied research but is seldom referred to in software engineering. Applying the design science lens to software engineering research may improve the assessment and communication of research contributions. Aim: The aim of this study is 1) to understand whether the design science lens helps summarize and assess software engineering research contributions, and 2) to characterize different types of design science contributions in the software engineering literature. Method: In previous research, we developed a visual abstract template, summarizing the core constructs of the design science paradigm. In this study, we use this template in a review of a set of 38 top software engineering publications to extract and analyze their design science contributions. Results: We identified five clusters of papers, classifying them according to their alignment with the design science paradigm. Conclusions: The design science lens helps emphasize the theoretical contribution of research output---in terms of technological rules---and reflect on the practical relevance, novelty, and rigor of the rules proposed by the research.Comment: 32 pages, 10 figure

Carbon saturation of silicon target under the action of pulsed high-intensity ion beam

The action of the pulsed high-intensity ion (carbon) beam on the silicon target is investigated by means of the theoretical model. The forming of the carbon concentration profile in depth of the silicon sample is modelled. It is argued, that there are two ways of the profile forming: short-pulsed ion (carbon) implantation and diffusion of the carbon atoms adsorbed on the silicon surface. It is shown, that the carbon atoms adsorbed on the silicon surface and diffused into the silicon target play the main role in the concentration profile forming

Error Identification Strategies for Python Jupyter Notebooks

Computational notebooks -- such as Jupyter or Colab -- combine text and data analysis code. They have become ubiquitous in the world of data science and exploratory data analysis. Since these notebooks present a different programming paradigm than conventional IDE-driven programming, it is plausible that debugging in computational notebooks might also be different. More specifically, since creating notebooks blends domain knowledge, statistical analysis, and programming, the ways in which notebook users find and fix errors in these different forms might be different. In this paper, we present an exploratory, observational study on how Python Jupyter notebook users find and understand potential errors in notebooks. Through a conceptual replication of study design investigating the error identification strategies of R notebook users, we presented users with Python Jupyter notebooks pre-populated with common notebook errors -- errors rooted in either the statistical data analysis, the knowledge of domain concepts, or in the programming. We then analyzed the strategies our study participants used to find these errors and determined how successful each strategy was at identifying errors. Our findings indicate that while the notebook programming environment is different from the environments used for traditional programming, debugging strategies remain quite similar. It is our hope that the insights presented in this paper will help both notebook tool designers and educators make changes to improve how data scientists discover errors more easily in the notebooks they write.Comment: 11 pages, 5 listings, 7 tables, to be published at ICPC 202

Impostor Phenomenon in Software Engineers

The Impostor Phenomenon (IP) is widely discussed in Science, Technology, Engineering, and Mathematics (STEM) and has been evaluated in Computer Science students. However, formal research on IP in software engineers has yet to be conducted, although its impacts may lead to mental disorders such as depression and burnout. This study describes a survey that investigates the extent of impostor feelings in software engineers, considering aspects such as gender, race/ethnicity, and roles. Furthermore, we investigate the influence of IP on their perceived productivity. The survey instrument was designed using a theory-driven approach and included demographic questions, an internationally validated IP scale, and questions for measuring perceived productivity based on the SPACE framework constructs. The survey was sent to companies operating in various business sectors. Data analysis used bootstrapping with resampling to calculate confidence intervals and Mann-Whitney statistical significance testing for assessing the hypotheses. We received responses from 624 software engineers from 26 countries. The bootstrapping results reveal that a proportion of 52.7% of software engineers experience frequent to intense levels of IP and that women suffer at a significantly higher proportion (60.6%) than men (48.8%). Regarding race/ethnicity, we observed more frequent impostor feelings in Asian (67.9%) and Black (65.1%) than in White (50.0%) software engineers. We also observed that the presence of IP is less common among individuals who are married and have children. Moreover, the prevalence of IP showed a statistically significant negative effect on the perceived productivity for all SPACE framework constructs. The evidence relating IP to software engineers provides a starting point to help organizations find ways to raise awareness of the problem and improve the emotional skills of software professionals.Comment: Preprint with the original submission accepted for publication at ICSE-SEIS 202