Why should I write software well?
summary
Argues that software quality is a time‑based tradeoff with concrete examples: adopting pydantic and dataclasses versus keeping fewer dependencies, prototyping that skips ops then later needing API integration, and choosing between tidying incremental changes or a full refactor that ultimately reduces developer cost. Cites a rough audience check that ~20% of teams work with people who don’t write well. Recommends option analysis — including a clear do nothing option — so choices like research prototype vs ops‑ready are technical, measurable, and negotiable.
AI-written summary · about
chapters (8)
- 0:00Welcome
- 1:08Why software quality matters
- 5:44Software benefits long-term
- 10:01Short-term vs long-term goals
- 13:57Quality trade-offs in coding
- 20:19Research vs operational needs
- 25:42Messy pull requests & team dynamics
- 28:30Recap and key takeaways for better software
related talks
40mBuild Better Software
51mReasons and Ways to Improve Code Quality
01h 00mBuilding Software Capital: How to write the highest quality code and why
42mKeynote track Methods: "Quality is a variable"
35mWhy Software Engineers Should Make Quality a Priority
39mYou should stop writing code
59mTechniques for writing high-quality code
01h 01mKeynote: Writing Software