Jason Garber
Senior Software Engineer

Jason
Garber

I’m a backend software engineer with experience in data engineering, management, and systems architecture. I enjoy making PoCs and reviewing pull requests!

  • Primary Languages Ruby & Python
  • Working remotely from New Hampshire
  • Employer Cisco Systems

About Me

25
Years'
Experience
9
Years as
a Principal
100+
People
Hired

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.

My Book

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:

  • What good pair programming is (and isn't)
  • Techniques to support personal growth and improve team cohesion through pairing
  • Criteria for deciding when to pair and how to share time, space, and power
  • Ideal hardware and software setups for pairing, whether in-person or remote
  • Convincing your team to adopt pair programming practices

Available in paperback or e-book from A Book Apart

Practical Pair Programming demystifies the logistics, benefits, and challenges of pair programming. It’s a must-read for teams new to the methodology pair programming and great for veterans of the practice, too.

Joe Moore

Principal software engineering manager at VMware Pivotal Labs

A practical handbook for developers everywhere! Jason’s book is full of great tips on how to master the art of pair programming.

Rachel Davies

Author of Agile Coaching

My Blog


16 July 2020

Pair Programming Book Launch

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.


09 October 2019

The Safety Inherent in Pairs

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.


22 August 2016

Why can't we tell when software is done?

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.