---
# System prepended metadata

title: 'UKAEA RSE Team Journal Club: 2023-03-02'

---

# UKAEA RSE Team Journal Club: 2023-03-02


:::info
- **Location:** K1/0/85
- **Date:** 2023-03-02
- **Article Link:** [The lone developer problem](https://evanhahn.com/the-lone-developer-problem/)
- **Agenda**
  1. Brief intro `2 min`
  2. Discussion `43 min`
- **Participants:**
  - Matthew Bluteau (scribe)
- **Host:** Dan Short

:::

## Brief Intro

- someone sharing some high-level thoughts which perhaps we see quite a lot in our organisation
- lone developer problem: someone has a great idea, implements, balloons, becomes a bit unmaintainable

## Discussion

- DS: do we sympathise and identify with this scenario?
    - CM: in our position as RSEs, we often seem software that is fundamentally designed in an incorrect way, and therefore the larger problem is not really "lone" developer, but a developer without suitable experience and skills
        - having other developers around would help, but it isn't the root problem
    - AA: PM's underestimating time and resources needed for developing software, and often one person gets allocated either the whole thing, or large parts of the system
        - no real solution except better project management
        - DS: indeed, a lot of projects are mis-scoped
        - AH: software is seen as the beginning and the end, and the middle bit of implementation often ignored
    - PV: from "scientific" code development perspective, this lone developer syndrome can cost a lot of time
    - JN: developing with someone else certainly helps the quality of my code
        - CM/HS: this isn't denying this effect, but there are two underlying problems here, one of which is lack of skill
    - KZ: having someone there to look at my code helps keep it in check from going off the rails
- MF: the mindset and pedagogy of software engineering biases us towards being lone developers
    - you get an assignment, give it a go on your own, and then submit it
- CM: create a course where you work on someone else's code or an open source project as a way of teaching how software collaboration works
    - PV: these sort of collaborative course do exist in CS degrees, so we could just lift from one of those
    - JN: should we moreso be trying to change the way we work at UKAEA to incorporate collaborative and code review culture
- DS: could we create a central code review network type thing where people can submit there analysis scripts
    - MB: a different direction of approach would be having something at the pinboard level and stage
    - PV: IVC is starting to implement proper analysis and QA checks, and this is built into the process
        - opportunity to incorporate this more broadly across site
    - MF: could we have some checklists of code quality that we can point people at from the beginning
        - DS: cookiecutters are part of this
        - CM/PV: but these sorts of checklists and things don't guard against bad design
        - MB: we do have a code quality page, but needs to be put into the broader context that CM/PV have pointed out
        - AA: indeed, we need a dialogue around
    - DS: we probably also need some design reviews to get to things before code review
- MB: we often in our own team find ourselves in solo development scenarios
    - how do we fix that?
    - DS: get multiple people on a project, or at least have other people come into do code review
    
    
    