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: https://github.com/centerofci/mathesar/pull/1568
  • 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