"Growing an Elm Project with the Whole Team"
summary
A small Elm app for domestic-violence support gets extended to translations and a 3–4 charity white‑label rollout while a mixed team of developers, a user researcher and an illustrator ship changes with limited dev hours. Specific practices: minimal initial code, short check-ins, and simple code-review checklists let a non-developer open PRs; Elm’s compile-time safety prevents bad releases; a time-subscription pattern replaces a bug-prone timer implementation and removes the only flaky feature.
AI-written summary · about
chapters (24)
- 0:00Introduction
- 1:54What was your app about
- 3:16How did you get started
- 4:38The team
- 5:44Guidelines
- 8:32New People
- 9:07Development Environment
- 10:33Rewriting
- 12:01Code Review Guidelines
- 13:26Declarative Style
- 15:00Learning Experience
- 17:43Trust Your Team
- 18:57Rockstars
- 22:59Neon Tribe
- 24:19We are not robots
- 25:28Decisions are hard
- 26:04Bugs happen
- 27:02People friendly code
- 27:54Emojis make you happy
- 28:52Questions to ask yourself
- 29:32Spaces and culture
- 30:22Democracy
- 31:20Labels and Job Roles
- 32:19What Can We Do
related talks
36m"Engineering to embrace change" Or "How clumsy engineering can lead to powerful research – Part II"
01h 01mArchitecture Decisions: A Case Study -
30mIn 1 Year
47mGood behaviour: Cultivating Healthy Elixir Teams & Codebases
45mKeynote: One Monolith, Many Teams: Growing an Org...
33mScaling Frontend: Supercharging Productivity with Dedicated Infrastructure Teams
43mBringing Functional Programming to Work
22mSetting up Enterprise Frontend for Success