| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| work:semana_9_de_2022 [2022/03/02 14:24] – [Research] magsilva | work:semana_9_de_2022 [2022/03/02 18:32] (current) – magsilva |
|---|
| * Considering the role congruity theory, they predicted the evaluation of code reviews of code which was authored by a person that "belongs to a group whose stereotypes do not align with the perceived qualities of a successful programmer or software engineering." The stereotype was modeled considering three dimensions: gender, race/ethnicity, and age. | * Considering the role congruity theory, they predicted the evaluation of code reviews of code which was authored by a person that "belongs to a group whose stereotypes do not align with the perceived qualities of a successful programmer or software engineering." The stereotype was modeled considering three dimensions: gender, race/ethnicity, and age. |
| * For dependable variable, they considered "the perception of unnecessary interpersonal conflict in code review while a reviewer is blocking a chance request", which is named as pushback. A pushback is identified by excessive chance requests and approval withholding of code review. That was measured by the number of review rounds, amount of time spent by reviewers, and amount of time spent by the code author addressing the reviewers' concern. | * For dependable variable, they considered "the perception of unnecessary interpersonal conflict in code review while a reviewer is blocking a chance request", which is named as pushback. A pushback is identified by excessive chance requests and approval withholding of code review. That was measured by the number of review rounds, amount of time spent by reviewers, and amount of time spent by the code author addressing the reviewers' concern. |
| | * Results: "Women [code] authors face higher odds of pushback than men; Asian, Black, and Hispanic/Latinx [code] authors face higher odds than White authors; and older [code] authors face higher odds than younger authors." |
| | * Confounding factors not accounted for: language spoken by code authors, code quality in the change under review. |
| | * Next was "Here We Go Again: Why is It Difficult for Developers to Learn Another Programming Language?" (10.1145/3511062). Oddly, the PDF retrieved from ACM DL was incomplete (it has just the first page), but I could read the whole paper using ACM DL reader. |
| | * Although we often focus on introductory programming classes, there is also the problem of learning to program in a second (or third :-) programming language. That is the issue this paper tackles. |
| | * The authors used a mixed- method research method, comprising analysis of questions posed at StackOverflow and semistructured interviews. Regarding the questions at StackOverflow, they considered ones that identified correct and incorrect assumptions across pair of languages. |
| | * There are evidence that cross-language interference occurs: for some language pairs, there are more misconceptions; for others, the knowledge was transferable. |
| | * Differently from novice programmers, experienced programmers often learn on their own, just in time and try to relate concepts from previously known language. However, those learning methods may be not suitable for new languages. For instance, there may not have a clear mapping for the same concept between languages, lack of documentation and examples for these mappings, or even the language implements a new paradigm that is incompatible with the previous one. Another issue is tooling: programming environments and features may differ considerably, making it harder to program in the new language. |
| | * The results of the paper are complemented by the introduction by Jonathan Aldrich (10.1145/3511061). We should not assume that it is easy to learn a new programming language. From programming education viewpoint, we should be aware that "old knowledge can either facilitate learning new knowledge or interfere with it." |