In June 2025, I started (yet another) personal blog here. All my other bloggy writing, lives on Medium.

On building software

• What is code readability, really?Aug 2024
• The one-person product: Throwing the AI train in reverseJul 2024
• Old school workarounds: Keeping the screen up to dateMay 2024
• Championing the doerApr 2024
• We shouldn't be surprised that code gets that wayApr 2024
• My 25-year career in web design (through the Wayback Machine)Apr 2024
• Professionals are often just sliver expertsMar 2024
• It's OK to want to work aloneMar 2024
• Most bugs live in the permutationsMar 2024
• Why I can't bill timeMar 2024
• Avoiding fancy abstractionsJan 2024
• Old school workarounds: The interstitial stateJan 2024
• Encapsulation is a messy artJan 2024
• Beware the blind faith of testsJan 2024
• Why it's hard to write about codeDec 2023
• It's the end...and I feel fineDec 2023
• The nth impressionDec 2023
• Starting design with spaceDec 2023
• Code as the design mediumDec 2023
• The small pleasure of info tablesDec 2023
• Using CSS classes as markersDec 2023
• The thing to think about with feature gatingDec 2023
• Why cache invalidation is actually hardDec 2023
• Build software like a musicianDec 2023
• Software writing to just writingDec 2023

In 2017, I wrote a series on the making of DoneDone—some flashbacks to how we started and pivotal moments during the early years of the product.

• Customer #000001
• Hindsight is…please don't make me look
• How an early feature was born
• Project BugSpray
• The glam of maintaining
• The ridiculous thing we do every day
• One vote of influence
• Emailin' ain't easy
• Love hurts
• Processlessness
• George Washington's axe
• Six o' clock in the morning, you're the last to hear the warning
• The Big Migration

Older writing on business, work, teaching, coding, design, and testing.

• What’s your weekly work pyramid?Jun 2017
• Being briefApr 2017
• Finding big passions in small thingsApr 2017
• Sometimes, it's life-work balanceApr 2017
• Where the software endsApr 2017
• Shining the spotlight on stage crew softwareMar 2017
• When I first learned about the impact of designMar 2017
• A maker's approach to managing projectsMar 2017
• The life changing magic of tidying up your codebaseMar 2017
• How about a refactorthon?Nov 2016
• What's the greatest piece of advice you've ever received?Nov 2016
• Why sports matter to some of usNov 2016
• Camraderie and recognition inside the development teamOct 2016
• Finding comfort in the uncomfortableSep 2016
• Building and maintaining a global search catalog using LuceneSep 2016
• Make good decisionsSep 2016
• There are rockstars and there are bandsAug 2016
• Remembering the rabbits: A fond farewell to FlashAug 2016
• The mythical couch-liftMay 2016
• The unintended byproducts of refactoring codeMay 2016
• Finding those “clear glue” momentsMay 2016
• Sometimes archaic technology is the most effective kindMay 2016
• How the evolution of baseball stadiums might inform the future of web designMar 2016
• Why I (still) write codeMar 2016
• Hiring into boundariesJan 2016
• The psychological battle of big refactoringsSep 2015
• Why it is hard to write about codeSep 2015
• An homage to strict codingAug 2015
• A primer on delivering a good presentationJul 2015
• The personal lessons I've learned in businessJun 2015
• The overlooked benefits of making yourself busyJun 2015
• Building the optimal users database modelMay 2015
• Do what you love, but know what love isApr 2015
• Where automated testing should (and shouldn't) fit in your strategyApr 2015
• Programmers should be a part of the design processFeb 2015
• Give away the punchlineJan 2015
• Cut the problem in halfNov 2014
• The hard thing about testingOct 2014
• The face on the other sideJul 2014
• A remote-first approach to the workplaceJun 2014
• Programming's three life lessonsJul 2014
• The least you can doMay 2014
• Want fewer bugs? Test these five casesApr 2014
• The redesign, the wait, and the responseMar 2014
• Quiet please: The benefits of online chatMar 2014
• A fast code cultureFeb 2014
• Thinking through your problemAug 2013
• The by-products are everywhereApr 2013
• Humility is at the heart of every problem solverMar 2013
• There will never be a programmer in the White HouseFeb 2013
• The golden rule on creating rulesFeb 2013
• Create your own sense of urgencyJan 2013
• Keep working on the easy stuffJan 2013
• Write code to read it, not bow to itJan 2013
• Reaching programmer's nirvanaJan 2013
• Teach abstraction through concretenessAug 2012
• Legacy code is good for your company cultureAug 2012
• Who is the new business programmer?Apr 2012
• Thank goodness I usually don't have a strong opinionMay 2011
• Why you should (and shouldn’t) track timeMar 2011
• The importance of familiarity within a teamFeb 2011
• Time your detailsDec 2010
• The benefits of the imperfect art of handwritingOct 2010
• Selling the process with the productMar 2010
• Recalibrating your sensesMar 2010
• Being your own boss is about being your own employeeJan 2010
• Treat time as an ingredientFeb 2010
• Simple sells depending on who you’re selling it toOct 2009
• Fixing software problems after the factSep 2009
• Building an ISV on top of a client businessAug 2009
• .NET MVC/LINQ/jQuery let you care about the details laterAug 2009
• Breaking old habits: Delete your crusty old codeMar 2009
• Use what you designMar 2009
• Make less interface when you canFeb 2009
• The fallacy of first impressionsJan 2009
• Quality starts and a save: Starter-reliever developmentNov 2008
• Make your product better in 2 ways every dayAug 2007
• Abstracting your writing is as important as abstracting your codeOct 2006