# 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