ways-of-working
books
- The Phoenix Project: A Novel about IT, DevOps and Helping Your Business Win by Gene Kim, Kevin Beh, George Spafford
- The Goal: A Process of Ongoing Improvement by Eliyahu M Goldratt & Jeff Cox
- Joy, Inc: How We Built a Workplace People Love by Richard Sheridan
- The Lean Startup: How Constant Innovation Creates Radically Successful Businesses by Eric Ries
- Show your work by Austin Kleon
- Getting started with Agility: Essential Reading by Allen Holub
- The Great CEO Within
links
- The Product Backlog and Technical Debt
- Kanban Classes of Service
- 12 Signs You’re Working in a Feature Factory
- Authority Matrix
- Is agile costing you too much
- Stevey’s Google Platforms Rant
- Nemawashi
- Ladder of Evidence
- Search is hard
- Revolutionary Software Development
- Shape Up - Stop Running in Circles and Ship Work that Matters
- THE TYRANNY of STRUCTURELESSNESS
- Estimation is Evil
- Simplicity is An Advantage but Sadly Complexity Sells Better
code
- John Carmack on Functional Programming
- Scientists don’t want to write good code
- How to Do Code Reviews Like a Human (Part One)
- How to Do Code Reviews Like a Human (Part Two)
- The Soft Side of Peer Reviews
- Cognitive Load is what matters
- The Grug Brained Developer
- Hammer factory - Why I hate frameworks
templates & frameworks
- Ways of Working canvas
- Product roadmap (The Tree of Up)
- Questions for our first 1:1
- Structured presentations
language
- Gender Decoder
- Falsehoods programmers believe about names
- PlayStation’s ultimate list of gaming terms
lulz
misc
oss
- colors & faker corrupted by dev
react-hooks-testing-librarymerges intoreact-testing-library- npm audit: Broken by Design by Dan Abramov
- Enzyme is dead
learn
projects
web
mentoring / coaching
- Coaching vs Mentoring vs Training
- How to be a great Mentee - Racheal Goodenough
- How to not suck at mentoring - Andrew Best
posts
links
Code is cheap. Show me the talk argues that the ability to think clearly, communicate problems, and architect solutions matters far more than the ability to write code itself.
Addy Osmani’s LLM coding workflow going into 2026 appears very similar to my own, though an interesting note on articles like this is that the reader can interpret the language used in different ways. Claude Code has an excellent /plan capability that Opus 4.5 excels on. I do plan, and I do write specs from time to time, but I also one-shot and two-shot changes and my actual development looks like a mixture of these. At no time do i generate pages and pages of specs and then have the LLM embark on a long horizon delivery period and not look at the code it wrote. Addy points out in anther post the importance of understanding the code with ideas like:
If you skip review, you don’t eliminate work - you defer it
And also links to another article noting that skipping review results in:
No consistency, no overarching plan. It’s like I’d asked 10 junior-mid developers to work on this codebase, with no Git access, locking them in a room without seeing what the other 9 were doing
This is inline with my findings and against a popular (hype) argument that an increase in code volume due to LLMs needs to be accompanied with a decrease in human-in-the-loop because speed. This is a drop in quality, which is deferred until your customer’s are affected and your DORA metrics deteriorate.
If I did read this in 2012 when it was leaked then I’ve completely forgotten. Valve’s (2012) Employee Handbook includes a section on stack ranking.
Some really basic tables that help illustrate the benefit of reducing work in progress.
Every team is at a different stage of collaboration and so it’s difficult to find a team charter template that fits all teams - I like this atlassian one even if just for the Team Preferences and Communication Channels sections.
Jeff Sutherland on Acceptance Test Driven Development suggests that estimating tasks will slow you down.