Skip to content

Our Ways of Working

These are our ways of working. The initial set was decided during a workshop. You are welcome to make changes and open a PR to start a discussion with the team.

"Agile" Philosophy and Meetings

Our general philosophy is to avoid too many "ceremony" meetings. Instead, we have a few recurring meetings that we deem important and create ad-hoc meetings and pairing sessions otherwise.

Our recurring meetings currently are:

  • Dailies 4 days a week. Purpose: Sync on what we are working, socialize.
  • Tech Discussion 1/week. Purpose: Room for longer discussions that don't fit into a daily. Share learnings, newly built stuff, general knowledge exchange.
  • Backlog Refinements. Purpose: Go through the backlog, prune, refine, prioritize tickets.
  • Biweekly Review every 2 weeks. Purpose: Demo what we achieved in the last few weeks. Collect feedback from stakeholders. Other Discovery teams are also demoing in the same meeting.
  • Retro every 4 weeks. Moderator is rotated. Purpose: Improve our ways of working and mood check-in.

Other relevant meetings:

  • Disco Leads. Usually attended by Simon as Engineering Manager (EM). Purpose: Exchange and alignment btw. all Discovery Department Leads. If Simon is not there, someone from the team joins the meeting.
  • RFD 12 Movement. Usually attended by Simon as EM. Purpose: Weekly stand-up to exchange on the status, progress, and todos for unified-content-metadata.

Coding Philosophy

  • Everything should be made as simple as possible, but not simpler.
  • Everyone takes responsibility to keep coding styles and patterns consistent across the Repo.
  • We practice boy / girl scout refactoring, i.e. "Always leave the code a bit better than you found it". Hence, if you see something that should be refactored and only adds 5-10% of work to your task. Do it! (You should probably refactor in a separate PR!). Some refactorings are bigger or need complicated deployments. Write a ticket for those!

Git Workflow

  • We practice CI/CD. Each change merged to main gets integrated, tested, and (if tests are successful) automatically deployed to STAGE and PROD. Hence, our tests need to be expressive and our CI/CD pipeline should be fast.
  • Everyone is responsible to keep main "green"
  • We want each code change reviewed by one other person before merging to main. We don't have Code Owners. We don't enforce reviews via GitHub rules. We want to keep the process super lean. From experience, intricate approval processes lead to Devs avoiding small PRs, Refactoring, etc.
  • In most cases, Devs should be able to merge their PRs without requiring a re-review after applying requested changes.
  • Reviewers should indicate the criticality of their comments, consider these snippets as inspiration:
    • "Super smart how you solved X, I love it! I left a few stylistic comments that might be a matter of taste, feel free to ignore them."
    • "Before you merge, you should change the method names for construct X. All other comments are more stylistic, I left my opinion, but feel free to ignore."
    • "I don't understand why we do X. I think we might be on the wrong track with this PR. Should we have a pairing session to work through some of my doubts?"
    • "We should really refactor Module X. But that shouldn't block the feature in this PR. Let's merge and create a follow-up PR."
Last updated: March 31, 2026 at 14:51
By: Alexandra Klochko