'The Art of Software Development'
summary
Argues software development relies on judgment and craft, not just repeatable engineering: cites Canadian regulation that protects the title “engineer,” contrasts bridge engineering (can’t ship an MVP bridge) with iterative software, and references a Nature study showing humans add rather than remove complexity. Describes concrete practices at Picnic: auto-formatting with Google Java Format, static fixes via Error Prone and OpenRewrite, quality tracking with SonarQube/SpotBugs, and a Tech Academy that gives new hires 50% learning time plus a senior mentor.
AI-written summary · about
chapters (18)
- 0:00Introduction and welcome
- 1:05Software engineering vs art
- 2:29Accountability in engineering
- 3:50Regulation and titles
- 4:54Iterative vs bridge building
- 5:38Computer science in practice
- 7:02Problem solving in domains
- 8:06Software as an art form
- 10:35The truth in code
- 13:28Purpose-driven code
- 14:30Context and fit in coding
- 15:57Art of writing good code
- 17:01The need for software design
- 18:47Challenges of software design
- 20:29Simplifying architecture
- 21:56Learning the art of development
- 23:41The role of mentorship
- 25:07Leaving a legacy
related talks
51mThe Art of Software Development
42mwhy software development is an engineering discipline
47m‘Engineering' for Software - How to Amplify Creativity
23mCode and Fear: Talent, Art, and Software Development
22mDo We Need Software Craftsmen?
45mTaking Back "Software Engineering"
01h 01mKeynote: Software Craftsmanship – Growing a Technical Culture
44mA Plea for More Software Craftsmanship