Skip to content

2022-10-04 backend meeting

Topic: The backend codebase is not in a very good state right now. What can we do to increase future feature velocity, and when should we do it? Attendees: Brent, Dom, Kriti, Mukesh, Sean

Potential agenda

Written before the meeting

  • Brainstorm about what’s slowing us down
  • Create a list of current problems with the code
    • What are our current architectural issues?
  • Prioritize
    • What do we need to fix for the live demo?
    • What do we need to fix for the first release?
    • What should we prioritize immediately afterwards?
  • What process changes do we need to make?

Brainstorming: what’s slowing us down?

Kriti’s notes:

  • Disagreements about architecture and readability
  • Brittle or hard-to-extend infrastructure (“overengineering”)
    • Hard to work with code that someone else wrote?
    • Potentially related to the lack of thorough code review and feedback
  • Issues taking too long to fix, big PRs, people disappearing into an issue for weeks or months
  • Refactors creeping into solving issues
  • Lack of “refactorability”
  • Lack of discoverability
  • Working around SQLAlchemy
  • Lack of standards or style guide?
    • To get us on the same page

Dom’s notes:

  • We’ve not been providing feedback to each other
  • Trouble with keeping PRs small
    • Would be interested in process-aided solutions

Brent’s notes:

  • small changes need to touch large portion of codebase
  • Long loops mean diverging from codebase, misunderstandings, sunk-cost fallacy
  • Generally overcomplicated codebase, given our feature set
  • review process takes too long
  • no process for “stopping bleeding”
  • bus factor is high. Leads to “only one can work on that part” attitude

Mukesh’s notes:

  • Fighting the framework
  • Complicated codebase due to the need for certain features
  • Breaking rules but not sure which one is important

Problems to solve

Based on the above brainstorming, here are the problems we need to solve and some discussion around them:

  • Get on the same page on what style etc. we’re aiming at
    • Style may not be a tight enough word here
  • Get on the same page on what things matter for style and what things don’t
  • Get better at feedback and PR reviews
    • We have had a “looks good to me” culture on the backend team
    • See this PR review from Sean as a good example of what we could do:
    • We don’t want to have only cathartic airing of grievances meetings, we want to build competency/consensus
      • Feedback is a gift for the person you’re giving it to, it helps them learn and grow
    • How much should we focus on feedback?
      • No feedback on current codebase, that will be covered when we talk about current codebase complexities
      • We should focus on thorough and honest feedback for new PRs
        • This should be more manageable because we are also tightening up feedback cycles
  • Tightening up feedback cycles for PRs (make PRs small)
    • Idea: walk through PRs once a week, even if you’re not ready to submit it
      • Hard to see where to split out PRs and make them smaller
      • Would benefit from a regular meeting to walking through the code for current work to get perspective
    • Pair programming could be useful also
    • 1:1s within backend team have been helpful
      • Make them more targeted to current problems
    • Meetings where we demand feedback on a regular basis
      • “Demand feedback” was a action item from public speaking training meetings as well, useful here
  • Identify and fix current codebase complexities
    • We shouldn’t touch this until we fix some of the above problems
    • It will only complicate things

Next steps

Live demo & first release are still top priorities, most time/effort will still be focused on them. Here’s some small changes we’ll make:

  • We will schedule another backend meeting in 3 weeks
  • To increase velocity, reach out to the person that has the most expertise in a particular part of the codebase and get them to help you with tasks so they are completed quickly.
    • We’ll work to break down this “only one can work on that part” through the next few steps.
  • Creating backend standards / style guide:
    • Everyone should individually write down notes on what makes code readable
    • We can use that to identify what we disagree on and figure out next steps
    • We’ll discuss this at the next meeting
  • Be more honest while giving feedback
    • Everyone should keep this in mind
    • No one will be insulted, no pre-filtering is necessary
    • It will help us understand each other’s preferences
    • We’ll discuss how this is going at the next meeting
  • Tightening up feedback cycles
    • Brent & Dom, Brent & Mukesh already have 1:1s
      • Brent will ask questions about current work in 1:1s
      • Focus these 1:1s on feedback and walking through code together
      • Get perspective on how to split up PRs
    • Dom & Mukesh should also set up a similar weekly 1:1
    • We’ll discuss how this went at the next meeting
  • Identify and fix current codebase complexities
    • We’re not tackling this right now