I’m a backend software engineer with experience in data engineering, management, and systems architecture. I enjoy making PoCs and reviewing pull requests!
Much has changed in the 22 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 out of 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 more code daily than I've ever written before.
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 such a way that gives future engineers 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 for their employer.
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 XP 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. By observing the pairs at Promptworks and from my personal experience pairing since 2012, I was able to compile a practical guide that explores:
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.
Over on the Promptworks blog, I wrote a short piece on how software, by its nature, is never “done” because there are always new ideas and changing business requirements that move the goalposts—and that’s not a bad thing! What can be detrimental is to not accept the nature of software and expect it to conform to a construction project paradigm. By doing so, you miss out on a lot of value and create fragile expectations.
