Writing on software, systems, and hard-won lessons.
Writing on developer experience, systems thinking, and the mistakes behind both - covering AI workflows, continuous improvement, and the mental models that drive better decisions.
Writing on developer experience, systems thinking, and the mistakes behind both - covering AI workflows, continuous improvement, and the mental models that drive better decisions.
Ten Ways to Build the Culture Into the Tooling
1. Fix the System, Not the Person. When someone struggles, ask "what system failed them?" not "what did they miss?" That junior stuck on SFTP for weeks? That's not a training gap. That's a 10-minute fix you haven't built yet.
2. Annoyance is a Bug Report. If something annoys you, it's probably unbearable for everyone else. That 1am deployment? Your team hates it too. Use your frustration as a detector. When you feel friction, you've found something to fix.
3. Make "I Don't Understand" Safe. Questions are feedback, not incompetence. If someone's afraid to ask, your culture is broken. Better to ask early than struggle silently for hours.
4. Document for Zero Prior Knowledge. The better you get at something, the harder it is to remember what it's like to not know it. Write docs for someone who arrived yesterday. Test them with someone who's never seen the system.
5. Optimise for the Reader. Code is read more than it's written. Shallow logic beats clever abstraction. Clear names beat comments explaining cryptic ones. If a new dev can't understand it in ~5 minutes, it's too complex.
6. Automate Quality. If a rule matters enough to follow, it matters enough to automate. Linter rules beat code review nagging. CI checks beat "please remember to." Don't rely on discipline when you can rely on tooling.
7. Prevent the Class of Bug. When you fix a bug, ask: where else does this exist? Audit the present: search the codebase for similar problems now. Secure the future: add a constraint (database, type system, linter rule) so it can't happen again.
8. Treat Errors as Instructions. A stack trace isn't an accusation. "Missing dependency X" means add X. "Timeout at scale" means optimise. Read errors like tickets, not judgments.
9. Choose Boring Over Clever. That elegant one-liner? Unmaintainable. Those abstraction layers "for flexibility"? Unnecessary until you have two implementations. Boring code ships and stays shipped.
10. Be Number Two. Your value isn't in being the hero. It's in making your team better. When you solve every hard problem yourself, you're stealing the learning moments your team needs. Wait 5 minutes before answering low stakes in Slack. Let someone else take the win.
For the mindset version, see Egoless Programming: Greatest Hits