The annoyance was ordinary enough to disappear into the furniture. At an engineering job, Abi Noda watched pull requests sit unattended for days. Someone needed a code review. Someone else had missed the request. The author grew tired of asking. So Noda, then an engineering manager, became the human notification system: scroll through the queue, spot the stale work, ping the responsible person in Slack, repeat.
It helped. It was also a rotten use of a manager's afternoon. Most people would have complained, delegated, or created a recurring calendar reminder with the solemnity of a municipal ordinance. Noda left the job and kept thinking about the nuisance. He asked peers in a Chicago CTO Slack group whether they had the same problem. They did. He found abandoned reminder projects online, evidence that the itch was widely felt even if nobody had scratched it properly.
In a couple of weeks he built Pull Reminders. The tool nudged reviewers in Slack and tracked how long reviews took. Noda expected to give it away. A trickle of signups arrived through the Slack App Directory, including people at larger companies who asked for changes with the brisk specificity of customers who had already assigned the product a job. He emailed every user, adjusted the software, and finally asked whether they would pay. He put the odds of a yes at about 30 percent. They paid.
The education of a professional noticer
The story makes sense because Noda had been turning curiosity into small systems since childhood. In middle school, he taught himself to code so he could build a website for his Counter-Strike team. His first lessons in commerce came from selling modified Nerf guns on internet forums. One delayed shipment produced an aggrieved customer who escalated the complaint to Noda's parents. Customer support arrived before the driver's license.
By his junior year of high school, the plan was music. He spent half the week practicing flute in hopes of attending a music school. Programming appeared to have one final assignment: make a web-design portfolio impressive enough for admissions. Instead, the portfolio became the trapdoor. This was the era when CSS was turning web pages from documents into designed places. Noda bought the CSS Zen Garden book, stayed up studying layouts, filled an RSS reader with design and software blogs, and fell for the possibility of making and selling software.
That turn led through software engineering, UX design, teaching at Dev Bootcamp, and engineering leadership. The work was not confined to comfortable startup offices. Noda contributed to Barack Obama's reelection effort and worked in Libya after its revolution on a voter-registration tool. Across the variety, he kept returning to a particular sort of problem: the distance between the process people are told they have and the experience they actually endure.
“My ultimate goal has always been to work for myself.”Abi Noda, reflecting on building software products
Pull Reminders grew into Pull Panda, a three-part suite. Reminders supplied the nudge. Pull Assigner spread review work across a team. Pull Analytics made waits and patterns visible. By 2019, thousands of teams were using the products. GitHub acquired the company that June and later folded its capabilities into the platform.
A tidy founder story could stop there, preferably with a photograph of a bell being rung. Noda went into research and product at GitHub, then returned to the unresolved part of the problem. A slow code review is measurable. The full experience of building software is not so polite. It includes cognitive load, interruptions, unclear ownership, brittle tools, awkward handoffs, and the wearying gap between knowing what matters and getting permission to fix it.
When the dashboard needs a witness
DX, which Noda co-founded and now leads, was built around the idea that developer productivity and experience required a research-led approach. The company pairs what systems record with what developers report. One side can show cycle time, deployment activity, or review delay. The other can reveal whether documentation is usable, tools are frustrating, priorities are clear, or a team is drowning in interruptions. A log can tell you that the train stopped. A passenger can tell you why everyone got off.
That distinction has shaped Noda's collaborations with researchers including Michaela Greiler and Margaret-Anne Storey. Their peer-reviewed framework described developer experience as contextual and personal, affected by factors at the individual, team, and organizational levels. It also catalogued barriers, improvement strategies, and coping mechanisms. This was less a hunt for a magic metric than an attempt to give leaders a map without pretending the territory was flat.
The position is important because metrics acquire ambitions. A number created to understand software delivery can be recruited to judge individual developers. A measure of activity can be promoted into a theory of value. Noda has repeatedly separated DORA's software-delivery measures from developer productivity, arguing that related concepts should not be casually collapsed. His preferred use of data is diagnostic and practical: find friction, decide where to invest, and check whether the change helped.
AI arrives with a stopwatch
Generative AI made this once-specialist debate an executive concern. Companies bought coding assistants, adoption graphs rose, and the obvious question followed: did the investment work? Noda's answer is to inspect more than use. A tool can speed code generation while review queues expand. It can make one developer feel faster while test systems, requirements, or deployment processes remain fixed. Local acceleration has a habit of delivering the bottleneck to the next desk.
In his conversations with DX CTO Laura Tacho, Noda describes platform and developer-productivity teams taking on a wider remit: evaluating tools, guiding rollouts, measuring impact, strengthening pipelines, and applying AI beyond code authoring. Documentation and clean feedback loops matter to agents for much the same reason they matter to people. New machinery does not repeal old organizational gravity. Meetings, interruptions, and unclear processes can still consume the gains.
This view helped define DX's AI measurement work: examine utilization, impact, and financial return while watching for changes in speed, quality, collaboration, and developer experience. It also made DX strategically legible to Atlassian. In September 2025, Atlassian announced a definitive agreement to acquire the company for approximately $1 billion, placing DX alongside Jira, Bitbucket, Compass, and Rovo Dev. The announcement said DX served more than 350 enterprises.
“Measuring developer productivity and experience was an unsolved problem that requires a research-driven approach.”Abi Noda on the belief behind DX
There is a satisfying symmetry here. GitHub bought the tool that helped teams move code reviews. Atlassian moved to buy the company that helps organizations understand the whole engineering system. Both began with the suspicion that small delays are not small when multiplied across hundreds of people.
A perfectionist writes a field guide
Noda has been candid about the less photogenic side of attention to detail. As a solo founder, a quiet signup week or a coveted customer saying no could send his thoughts downhill. Perfectionism tempted him into refactoring code or redesigning work that was already sufficient. While writing answers for an early interview, he polished them until they became longer and duller. His brother and friends intervened and told him to stop.
The anecdote is funny because the affliction is familiar. Care improves products until it starts protecting the maker from releasing them. Noda's career contains a repeated countermeasure: put the work in front of people. Ask the CTO group. Email the signup. Compare the survey with the system. The cure for private certainty is contact with a real workflow.
In 2025 he and researcher Nicole Forsgren published Frictionless, a 312-page guide to improving developer experience. The book lays out seven steps for diagnosing barriers, measuring DevEx, building a business case, and making changes last. More than 100 pages are workbooks. This is a book with its sleeves rolled up, designed for the meeting after everyone agrees developer experience matters and someone asks what happens Monday.
It also completes a loop that began in a high-school computer lab. Noda first discovered that software could be a form of creative independence. He later said he wanted to help other developers build businesses of their own. His current work operates at larger scale, but the instinct remains recognizable: notice where capable people are stuck, make the obstruction visible, and hand them something useful.
There will always be demand for a clean number that tells a complicated organization it is doing fine. Noda's work offers the more useful discomfort of a follow-up question. What are developers waiting for? Which tool is creating noise? Where did the time go? Did the improvement reach the people doing the work? Friction rarely announces itself as strategy. It looks like another Slack ping, another brittle test, another afternoon spent tending a process that everybody has learned to tolerate.
The trick is to remain annoyed long enough to investigate.