I’m a full-stack software engineer with experience in data engineering, management, and systems architecture. My em dashes and semicolons are 100% human-generated. :)
Much has changed in the 23 years since I started writing software professionally. I picked up Ruby in 2005 by taking a 300-page book to an empty office and reading it cover to cover. Now, I confidently dive into any technology by asking questions of AI. Even since I wrote Practical Pair Programming based on years of in-office collaboration experience, I've switched to remote work with a globally distributed team and I pair with AI assistants to write better code than ever.
Yet the principles that define the craft have hardly changed in decades. Software engineering continues to be knowledge work—a process of discovering what works and what doesn't. It's finding just the right language to describe abstract concepts and using good judgement to improve outcomes, reduce risk, and make people happy. That's why I get up every day excited to see what I can learn, fix, uncover, and codify as an engineer.
Coding is simply writing down how a system should work in a way that a computer can follow. The human part is having the vision, making code communicate the intention of your design, and building it in a way that gives future engineers — whether human or artificial — maximum agility to adapt to new discoveries about what customers want. That's what separates a developer who merely gets the job done from one who delivers great value.
On my team, we meet our commitments today and build software that serves stakeholders well into the future by applying our best human qualities: attention to detail, kindness to each other, and a dedication to getting it right.
The practice of pair programming is a fascinating way to co-create effective, maintainable software, but there was little guidance on how to do it well and many anecdotes about it going horribly wrong. By observing the pairs at Promptworks and from my personal experience pairing since 2012, I compiled a practical guide that explores:
For some, the COVID-19 pandemic was a mere blip – a pause in the busyness before life returned to normal. For many people engaged in building software, however, the world looks very different in 2024 – especially if you consider the way AI has fundamentally changed how we specify, write, and verify software.
In 2012, I began collecting thoughts and learnings from pair programming in a long document that I thought could one day become a book. Last year, when engineers at Promptworks asked for some pair programming resources, I circulated the manuscript internally. Jon Long saw its potential and tipped off Katel LeDû, the CEO of A Book Apart, who got in touch about making it the next title in their Briefs collection.
The last connecting flight between home and my college was on a comically small airplane. It was a 1996 Beech turbo-prop with no lavatory, no overhead bins, and 19 of the tiniest seats you’ll ever see. About 10 minutes into the 45-minute flight, the copilot would crawl out of the cockpit and serve drinks to the handful of passengers aboard. He could barely finish opening everyone’s cans of soda and handing out the peanuts before needing to return to the cockpit for landing.
