---
# System prepended metadata

title: CW22 introduction presentation

---

# CW22 introduction presentation

- [Code review during research](#orgf89747b)
- [Code Review benefits researchers themselves](#orgbcf3cf6)
- [Code Review is common software development practice](#org3242a8e)
- [CRC group 2: Provide guideliesn for CR during research](#org17f05ee)
- [Workshop outline](#orgab73c80)
- [Code Review Community](#org4ff1ecf)
- [Polling](#orgc115994)
- [Overview of code review guidelines](#org1fe8659)
  - [Principles](#org7ac75a0)
  - [Four steps](#orga4bbd29)
- [Website overview](#org78e0346)


<a id="orgf89747b"></a>

# Code review during research

-   Yesterday we had a presentation about CODECHECK. Code review at the time of publication. It's relevant for reproducibility and checking state of a codebase.
-   But what if the code is unreadable/unmaintanable? It's too late for a rewrite.
-   There is a need for code review *during research*. A different kind of code review: informal, low-stakes and frequent. Something you would with colleagues once a week. Focus on code quality. Does not replace publication-time review - but is complementary.


<a id="orgbcf3cf6"></a>

# Code Review benefits researchers themselves

-   Code review during research has benefits beyond better code quality.
-   Learning and knowledge transfer
    -   Mentoring and dissemination of experience and good practices.
    -   More experienced programmers are exposed to new patterns and approaches.
-   Collaboration
    -   Regular meetings and discussions increases group awareness, trust and cohesion.
    -   Specific technical knowledge is spread. Easier for newcomers, reduce impact of leavers.


<a id="org3242a8e"></a>

# Code Review is common software development practice

-   Code review is common in the software industry and open source communities, but very rare in research.
-   Lack of awareness and guidance on how to do code review in a research context. Most material out there is targeted at the software industry and open source projects.
-   Establishment of code review culture will probably struggle with lack of incentives for code quality and lack of confidence.


<a id="org17f05ee"></a>

# CRC group 2: Provide guidelines for CR during research

-   UK/US based group of researchers and RSEs.
-   Started as one of the working groups of the Code Review Community.
-   GROUP PHOTO
-   In practice, guidelines as website. Living document that is open to contributions.


<a id="orgab73c80"></a>

# Workshop outline

1.  Short intro to CR guidelines and tour of the website.
2.  Breakout rooms
3.  Report back
4.  Wrap up


<a id="org4ff1ecf"></a>

# Code Review Community

A few words about the CRC? Maybe by Holly? Can reuse poster from SORSE?


<a id="orgc115994"></a>

# Polling

-   Mentimeter poll to learn more about the audience.


<a id="org1fe8659"></a>

# Overview of code review guidelines


<a id="org7ac75a0"></a>

## Principles

-   Suited for lone, perhaps isolated, research developpers.
-   Short, fixed duration. Can fit into a busy schedule with possiblity of iteration.
-   Informal and low stakes.
-   Accessible to less experienced programmers (e.g. resaercher how would not think of themselves as programmers).


<a id="orga4bbd29"></a>

## Four steps

1.  Find a reviewer
2.  Meet and agree on objectives
3.  Perform the code review
4.  Finish


<a id="org78e0346"></a>

# Website overview