Software Engineering at Google

Mike's Notes

Discovered this gem via the DORA Community. You can buy the 602-page book from O'Reilly, and you can read an HTML copy for free online at Abseil.

The book is CC BY-NC-ND 4.0

"About Abseil

Abseil is an open source collection of C++ libraries drawn from the most fundamental pieces of Google’s internal codebase. These libraries are the nuts-and-bolts that underpin almost everything Google runs. Bits and pieces of these APIs are embedded in most of our open source projects, and Abseil aims to bring them together into one comprehensive project. Abseil encompasses the most basic building blocks of Google’s codebase: code that is production-tested and will be fully maintained for years to come.

Our primary purpose in releasing Abseil is to more easily support Google open source projects sharing their C++ code outside of Google. In some cases, Abseil provides pieces missing from the C++ standard; in others, Abseil provides alternatives to the standard for particular use cases we’ve needed in the Google codebase. We denote those cases clearly within the library code we provide you.

Abseil is not meant to be competitor to any standard library code; we’ve just found that many of these utilities serve a purpose within our codebase, and we now want to provide those resources to the C++ community as a whole."

Resources

References

  • Software Engineering at Google curated by Titus Winters, Tom Manshreck, and Hyrum Wright, O'Reilly. 2020.

Repository

  • Home > Ajabbi Research > Library > Subscriptions > DORA Community
  • Home > Handbook > 

Last Updated

12/10/2026

Software Engineering at Google

By: Titus Winters, Tom Manshreck and Hyrum Wright
Abseil: 01/03/2020

Titus Winters: Senior Principal Scientist at Adobe. C++ Libraries Lead for Google. Founder of Abseil (http://abseil.io). C++ Standards Committee member, chair for Library Evolution Working Group (design for the C++ standard library). Google C++ Style Guide co-maintainer.  Teacher, author.

Tom Manshreck: Education engineer with deep programming experience. Experienced Principal Program Manager and Staff Technical Writer. Have worked on both internal and external projects at Google for 19 years, including as a manager of 12 individuals, a tech lead for a company-wide series of internal programming manuals, and external REST/gRPC-based APIs (Maps and Machine Learning APIs). Deep experience in educational efforts of complex internal programming systems, Cloud APIs, Machine Learning, GIS/Geographic information, and the C++ programming language.

Hyrum Wright: Hyrum K. Wright is a Staff Software Engineer at Google, where he has worked since 2012, mainly in the areas of large-scale maintenance of Google's C++ codebase. Hyrum has made more individual edits to Google's codebase than any other engineer in the history of the company.

Camille Fournier: Author, The Manager's Path

...

Foreword

I have always been endlessly fascinated with the details of how Google does things. I have grilled my Googler friends for information about the way things really work inside of the company. How do they manage such a massive, monolithic code repository without falling over? How do tens of thousands of engineers successfully collaborate on thousands of projects? How do they maintain the quality of their systems?

Working with former Googlers has only increased my curiosity. If you’ve ever worked with a former Google engineer (or "Xoogler," as they’re sometimes called), you’ve no doubt heard the phrase "at Google we…" Coming out of Google into other companies seems to be a shocking experience, at least from the engineering side of things. As far as this outsider can tell, the systems and processes for writing code at Google must be among the best in the world, given both the scale of the company and how often people sing their praises.

In Software Engineering at Google, a set of Googlers (and some Xooglers) gives us a lengthy blueprint for many of the practices, tools, and even cultural elements that underlie software engineering at Google. It’s easy to overfocus on the amazing tools that Google has built to support writing code, and this book provides a lot of details about those tools. But it also goes beyond simply describing the tooling to give us the philosophy and processes that the teams at Google follow. These can be adapted to fit a variety of circumstances, whether or not you have the scale and tooling. To my delight, there are several chapters that go deep on various aspects of automated testing, a topic that continues to meet with too much resistance in our industry.

The great thing about tech is that there is never only one way to do something. Instead, there is a series of trade-offs we all must make depending on the circumstances of our team and situation. What can we cheaply take from open source? What can our team build? What makes sense to support for our scale? When I was grilling my Googler friends, I wanted to hear about the world at the extreme end of scale: resource rich, in both talent and money, with high demands on the software being built. This anecdotal information gave me ideas on some options that I might not otherwise have considered.

With this book, we've written down those options for everyone to read. Of course, Google is a unique company, and it would be foolish to assume that the right way to run your software engineering organization is to precisely copy their formula. Applied practically, this book will give you ideas on how things could be done, and a lot of information that you can use to bolster your arguments for adopting best practices like testing, knowledge sharing, and building collaborative teams.

You may never need to build Google yourself, and you may not even want to reach for the same techniques they apply in your organization. But if you aren’t familiar with the practices Google has developed, you’re missing a perspective on software engineering that comes from tens of thousands of engineers working collaboratively on software over the course of more than two decades. That knowledge is far too valuable to ignore.

Camille Fournier

Author, The Manager's Path

CC BY-NC-ND 4.0

Nest-driven configurations

Mike's Notes

Yesterday I was tying up loose ends and gained a new insight. Quite unexpected.

A work in progress.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

11/10/2026

Nest-driven configurations

By: Mike Peters
On a Sandy Beach: 11/10/2026

Mike Peters: Mike invented and designed Pipi and founded Ajabbi.

...

Nest

The Nest code names map to the different system builds Pipi can install and automatically grow. I deleted the redundant account classes c, i, and b and replaced them with a.

The letters used are not significant. There are 26 letters available. But the full names must not duplicate and must be easy for people to understand. Still some work to do here.

After I sleep on this for a few days and make a few more tweaks, I'll update the existing engineering blog notes and develop documentation with the new settings. Then Pipi can render out the new builds.

Columns

Here are some columns in the configuration table, with more to come. This web page is too small to show everything, so a white paper PDF might be needed to show the whole table in landscape format.

  • Major version
  • Edition
  • Account
  • Nest
  • Workspaces
  • Source (closed/open)
  • Pricing (free/usage-based)
  • Tenancy (single/multi)
  • No. of Pipi's (0-xxxx)

Version 9 Nest configuration table


Edition

Account

Nest

Workspaces

Source

Application

?

9ac/

Agent

Mission Control

Data Centre

Open

Developer

9ad/

Config

Tools

Enterprise

9ae/

Agriculture

Built Infrastructure

Civil Defense

Community

Culture

Faith

Health

Learning

Nature Conservation

Research

Transport

Website

Personal

9ap/

My

Researcher

9ar/

Constraints

Laws of Science

SME

9as/

App

Temp

9at/


Core

Agent

9ca/


Closed

IaC

9ia/

Robot

9ra/

How to Read a Book

Mike's Notes

This is great advice. I'm going to do this. Also, using commonplace books is a great suggestion. Thanks, Hana 😎

"A commonplace book is a personal notebook where a reader copies passages and questions from everything they read. Keeping one lets us carry questions from one book to the next." - Hana Lee Goldin

Card Catalog is a fantastic gem of a newsletter from Hana.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Card Catalog
  • Home > Handbook > 

Last Updated

10/10/2026

How to Read a Book

By: Hana Lee Goldin, MLIS
Card Catalog: 30/09/2026

Hana Lee Goldin, MLIS: Your personal librarian for the AI age. Forever in the pursuit of exploring how we find, filter, and feel about information.

...

Quick summary

Reading a nonfiction book as more than its chapters changes what the book can give us. The pages around the chapters tell us how its argument is built, when it was written, who made it, and which conversation it joins. With that context in hand, every chapter carries more meaning.

Key takeaways

  • Reading the table of contents before chapter one lets us follow the argument as it builds, step by step.
  • Our own marks in the margins and a running note on the phone turn the book into a conversation we can return to.
  • The notes and the bibliography hand us our next book, chosen by someone who spent years in the field.

Cracking open a new nonfiction book is one of the finest adventures a mind can go on. It’s portable and immediate, asking for almost nothing but curiosity, and not just a willingness to give sustained attention to one subject but a deep, abiding welcome of the attention itself. The book becomes both mentor and sparring partner all at once. For a little while, its subject occupies our thoughts, in the most delightful way. We dive deep into some niche and come up with our minds fuller, fed by the richest kind of mental nourishment.

There’s far more to a nonfiction book than its chapters, though. Most of us turn to chapter one, where the writing we came for begins. The pages at the front and back are less familiar and can look like formalities, so they tend to stay unread.

The pages we pass over carry records left by the people who made the book. A finished book passes through many hands, from an editor who pushes back on its logic to a designer who arranges its pages. Several of those hands leave a mark we can read. The publisher dates the book and names itself on the copyright page. A cataloger, who read the book before it reached a shelf, wrote the short block of catalog information printed on that same page. Behind the last chapter, the author’s own notes and acknowledgments sit next to an index, which an indexer built by combing every page for what a later reader might want to find.

Read alongside the chapters, those pages give a book a place in time and a circle of company that the chapters alone can’t. With the table of contents in mind, we walk into each chapter knowing what the author is trying to prove and how far along the argument we’ve come. A year on the copyright page lets us hear the book as a voice from its own moment, one whose claims carry a date and whose confidence we can weigh against everything learned since. The notes and bibliography introduce us to the company the author kept, the writers the author argued with and admired, and turn a single voice into a conversation we’re invited to join. An index lets us come back long after and find the passage that stayed with us, keeping the book ours past the last page.

In 1940, the philosopher Mortimer Adler published How to Read a Book, later revised with the editor Charles Van Doren. Adler taught readers to survey a book’s structure before reading it closely. A librarian begins there too, then asks different questions. Who made this book? What work does its argument rest on? Where does it sit among the other books on its subject?

Every book we read has a life with us that runs longer than the reading. It starts in a bookshop aisle or a library app, with a title that catches our eye, and can carry on for years after the last page, in a passage we return to or a book it led us toward. The pages around the chapters travel that whole distance with us. They do the most for us when we know which ones to reach for as we go, beginning with the moment we first pick a book up.

Before we start

We can learn a lot about a nonfiction book before reading any of it. With the book in hand, a few pages at the front and back answer two questions. The first is whether the book covers what we want to learn, and in how much depth. The second is what kind of reading we’re in for, from how recent the research is to how the argument is laid out. Answering those questions before chapter one means we start the book knowing what it can give us. On the next nonfiction book we pick up, these are the places to look:

  • Check the year on the copyright page against how quickly the subject has changed.
  • Look for an edition number on the copyright page. A second or later edition often opens with a new preface on what the author changed.
  • Turn to the page about the author and the acknowledgments to see who trained the author and who funded the work.
  • Scan the subject headings in the cataloging block on the copyright page, if the book has one. A heading the cover never mentions may point to a subject the book takes on and the marketing set aside.
  • Read the chapter titles straight through, in order, before chapter one.
  • Read the last paragraphs of the introduction, where authors often preview each chapter.
  • Glance at the final pages of the last chapter, where the conclusion often states the whole case.
  • Look up the one topic we came for in the index at the back. A lone page number may mean the book barely covers the subject. Many page numbers, broken into subentries, usually mean the book covers it in depth.

Glancing at these pages answers the questions we brought to the book. A slower look turns up more: how an argument changed across editions, what the book’s subject headings reveal, and where the author places their work among other writers. The first page to turn to sits behind the title page, where the copyright page records when the book came out and who published it.

The copyright page

  • What it is: The publisher prints this page on the back of the title page to record who owns the book’s rights and when it came out.
  • What it’s for: It names the house that produced the book and gives the year of publication, our starting point for asking how current the research is and how the book reached print.
  • What it gives us: We can read each claim alongside the year it was made and notice which parts of the book newer work may have revised.

The copyright page sits on the back of the title page. Publishers use that page to record who owns the rights to the book and the year it was first published. The year is the line to read first, because it tells us when the book entered the conversation. A study of public health from decades ago can still be brilliant, though its statistics describe a world that has since moved on. With that year in mind, we can read the book as a report from its own moment, written by someone who could only know what was knowable then. The year tells us which claims may need checking against newer work before we repeat them. How much the year changes our reading depends on the field. Thirty years may matter less to a history of ancient Rome, where the central evidence often changes more slowly than it does in nutrition or computing.

A printing is a new batch of the same text; an edition changes the text itself. Many books show their printing history as a row of numbers, sometimes descending: 10 9 8 7 6 5 4 3 2 1. Printers call it a number line. Publishing conventions vary, but the lowest number still standing usually identifies the printing in our hands. A row whittled down to 7 means six earlier batches of the same edition were printed before ours. New editions often arrive with a new preface, where authors explain what they changed and why. Reading that preface first shows us where the argument shifted before we commit to the rest.

The publisher’s name on this page gives us one clue about how the book reached print. University presses often publish scholarly work and commonly send manuscripts to outside specialists for review before publication. Trade publishers usually publish for a general readership, with editors working closely on a book’s structure, clarity, and pace. Both kinds of publisher may seek expert advice, copyedit closely, or leave much of the factual checking to the author. Neither name guarantees accuracy. It tells us where to begin asking how the book was made, and how much checking we may need to do ourselves.

Besides the publisher, the person to get to know before we begin reading is whoever wrote the book. A page near the front or back gives the author’s training and earlier work. That tells us what they bring to the subject, whether a historian coming to a scientific question or a journalist who spent years inside an industry. The acknowledgments say more still, this time in the author’s own voice. They often name the people who read early drafts and the institutions that supported the research. Those names place the author inside a community of colleagues and mentors and show us the conversation the book grew out of. A history written from inside one school of thought, or a book funded by the industry it describes, can still be excellent. Reading the acknowledgments first tells us which community and point of view the book comes from. With that in mind, we can follow the author's arguments knowing the perspective behind them.

The cataloging block

  • What it is: The cataloging block is a short catalog record printed on the copyright page, listing the book’s subject headings and shelf numbers.
  • What it’s for: It gives libraries a standard way to describe the book and place it beside others on related subjects.
  • What it gives us: Its subject headings show what the book substantially covers and give us a route to other books on the same subject.

The copyright page carries a second kind of entry, this one from a library rather than a publisher. On many books it appears as a boxed cluster of text lower on the page. Librarians call it the cataloging block, a catalog record printed inside the book itself. Its subject headings name the topics the book covers. Libraries use shared terms so books on one subject gather under the same heading instead of scattering across near synonyms. The classification numbers beneath them place the book on a shelf beside related work.

Not every book carries a cataloging block. When one does, its headings are still human choices, made inside an institution with its own history. Libraries revise their terms as language and understanding change, though the printed record stays as it was.

Reading the subject headings before chapter one shows us how a cataloger summarized the book in a handful of phrases. A history of a revolution might carry one heading for the war and another for the women of that era. That second heading tells us that women’s lives are substantial enough to the book for the cataloger to name them as a subject. When the headings line up with what the cover promises, the marketing has described the book fairly. When they name a subject the cover leaves out, we have found something the marketing set aside.

Each subject heading can be searched in a library catalog, including WorldCat. Search one, and the catalog gathers other books described with the same terms. The classification number can do the same work in a physical library: nearby numbers lead us toward books on related subjects. A cataloging block turns one book into a route through a shelf.

The table of contents and the introduction

  • What it is: The contents page lists the chapters in order. The introduction often states the thesis and may preview what each chapter will do.
  • What it’s for: Together they show the author’s plan before the argument begins.
  • What it gives us: We meet each chapter knowing what work it is meant to do, which keeps the argument in view even in a long or difficult book.

Once a book has passed the checks on its copyright page and its cataloging block, the next pages show how its argument is built. The table of contents is the place to begin, since chapter titles read in order lay out the author’s case the way an outline lays out an essay. Mortimer Adler called this kind of survey inspectional reading: a look at a book’s structure before we read it closely. Reading the titles first hands us the author’s plan before we reach the argument itself.

The author’s plan, read off the chapter titles, lets us guess the argument before we’ve read a page. Picture a history whose chapters begin with a single town and end with the decisions of a distant capital. The sequence may suggest that the author sees local events as an explanation for national ones. Carrying that guess in our heads as we read turns every chapter into a small test of whether the author delivers. When the book surprises us, we feel the surprise. That feeling marks the place where the book changed our mind.

A contents page also shows proportion, which the text itself never announces. Page numbers beside each chapter reveal where the author spent the most space, often on the part of the case that needed the most defending. Books divided into larger parts offer another clue: their part titles show the argument’s main turns, with the chapters beneath them doing the work.

Authors of nonfiction often use the introduction to state their thesis outright and to name the scholars they’re arguing with, which turns a book that looked like a monologue into one side of a debate. Many introductions close with a preview of each chapter, which lets us check our reading of the contents against the author’s own summary. Adler also recommended glancing at the final pages before starting, because authors tend to restate the case there in its finished form. With the introduction and those closing pages read, we enter the text knowing where it begins and where it means to arrive, which frees us to watch how the author gets there.


Photo by Elijah Crouch on Unsplash

While we’re reading

Even with the argument in view, attention tends to drift somewhere in the middle of a book. One cause is that we’ve only been receiving for a stretch, not responding. Our focus returns the moment we answer back. A mark in the margin or a question in a note keeps the author’s claim separate from our own response to it. When we come back months later, we can see what persuaded us and where we pushed back. Every habit that leaves such a record is one we already have, pointed at the case the author is building instead of at the lines we happened to like.

  • Fold a corner or highlight the claims we doubt, alongside the lines we love.
  • Keep one note on the phone or in a journal titled with the book’s name, and let the questions or comments pile up there.
  • Park an unfamiliar name in that note and look it up later, rather than breaking off to search in the middle of a page.
  • When a chapter ends, look at its notes at the back. They show the sources behind particular claims and may reveal where the author sees uncertainty or disagreement.
  • Glance at the dates in the bibliography to see whether the author draws on recent work where the field calls for it.

Each of these habits fits into the reading we’re already doing. Kept up across a whole book, they leave a record of our exchange with the author, one that stays on the page and in our own notes after the reading is done. That record leads us naturally to the back of the book, where the author’s notes and bibliography show us the work beneath the argument.

What we add to the book

  • What it is: Marginalia are the notes we write in a book’s margins. A commonplace book is the notebook where we collect passages and questions from everything we read.
  • What it’s for: They turn reading from something we absorb into a conversation we take part in.
  • What it gives us: The record we leave of what persuaded us and what didn’t keeps the book ours to argue with and return to.

Every page covered so far came from someone who helped make the book. Marginalia and the commonplace book come from us instead, written in as we read. By the time we reach the text, we know the argument the author intends to make. Each chapter becomes a step in the case. We can ask whether its evidence supports the claim it was meant to prove. The book becomes an argument we test.

Marginalia are the notes readers write in the margins. Plenty of us already keep a version of them without using the word. A folded corner marks a page we mean to return to. Highlighting in an e-reader, or photographing a page with a phone, saves the line that struck us. Pointing those habits at the argument, instead of at the lines we happened to like, turns reading into an exchange. A question mark beside a sweeping claim marks a place to push back. Underlining a quoted source flags a work to find later.

A commonplace book is a personal notebook where a reader copies passages and questions from everything they read. Keeping one lets us carry questions from one book to the next. The English philosopher John Locke devised an indexing method for his commonplace books so he could find an entry again by topic. The commonplace book’s modern form is the phone in our pocket. A notes app does what Locke’s index did, with a search bar instead of a system. One running note titled with the book’s name, where the photos and saved lines collect, is a commonplace book in everything but the binding.

When a book mentions an event or a thinker we don’t recognize, add the name to the running note and look it up later. We stay with the page for as long as it has our attention. Over time, those notes become a log of how different authors treat one subject. Sooner or later, two of those authors disagree. At that moment, the note turns into a research tool of our own. The back pages of a book with full notes and a bibliography supply that tool with its material.

The notes

  • What it is: Notes are numbered entries tied to specific passages in the text, printed at the foot of each page or gathered at the back of the book.
  • What it’s for: Each note leads us to the source behind a claim and may add the author’s own comment on it.
  • What it gives us: Read alongside the chapter, notes show us how an argument rests on evidence and where the author’s interpretation begins.

Many books gather their notes at the back, though the notes belong to the reading itself. Each one is tied by a number to a passage in the chapter. Flipping back as we go, or reading a chapter’s notes the moment it ends, keeps each claim beside its evidence. Any source can be judged by what it was built on. The notes show that foundation claim by claim.

In the notes, many authors write more candidly than in the chapters. They argue with other scholars there and admit where the evidence runs thin. Reading a chapter’s notes right after the chapter shows us how a claim rests on evidence and where interpretation begins. A long note often marks a claim that needs more explanation than the chapter can hold. It may be where the evidence is contested, where the author qualifies the point, or where another argument waits just off the page.

Some nonfiction books carry no notes at all. Their claims may still rest on extensive reporting, archival work, or expert consultation, but the path back to the evidence is harder for a reader to follow. Look for a page headed Sources, Further Reading, or Selected Bibliography, and read the acknowledgments for the experts, archives, and institutions the author names. When a claim has no trail inside the book, write it down and check it against other reliable work before carrying it forward.

How I Find Problems to Solve as a Staff Engineer

Mike's Notes

Discovered this in a recent Arc Notes Weekly. My method as well.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Arc Notes Weekly
  • Home > Handbook > 

Last Updated

09/10/2026

How I Find Problems to Solve as a Staff Engineer

By: Lalit Maganti
Lalit Maganti: 25/07/2026

Lalit Maganti: I'm a founding engineer of Perfetto, a tool for understanding where time goes in software. I've been building it at Google since 2017, helping engineers track down performance problems in Android, Chrome, and beyond. I share what I learn in articles and notes.

...

Discussed on Hacker News and lobste.rs.

Note: this post was revised after publishing for increased clarity, based on reader feedback.

...

“How do you find problems worth working on?” a senior engineer I mentor asked me recently. He’s trying to make the jump to staff engineer and realized that the role isn’t just about doing the work he’s assigned. He also needs to get involved in figuring out what his team and org should be building.

Someone else had suggested blocking out time in his calendar to think about the bigger picture. He’d tried that, but hadn’t found it productive, so he asked if I had any alternatives.

I told him I rarely find good problems by staring at a blank page and trying to “think strategically.” Instead, I act like a sponge. I listen to the stream of day-to-day noise, absorb the problems people are having and let them sit in the back of my mind. Over time, some fade away while connections begin to appear between others that initially seemed unrelated. Eventually, I start to see what’s really slowing people down and what my team or I can do about it.

I’ve worked with many engineers who’ve never really tried this. They wait for managers or leads to identify opportunities, then demonstrate their value by solving the hardest assigned problems. That can absolutely lead to promotion. But the projects that have made the biggest impression in my career were the ones where I found and solved an important problem my leaders did not yet realize existed.

One caveat: my experience comes mainly from working on infrastructure and developer tools at large companies, on teams where engineers have a lot of bottom-up autonomy to influence their roadmaps. In a more top-down environment, there may simply be less room to work this way.

Absorb problems, not requests

People love talking about the problems they are facing: in meetings, chat threads, presentations and email. They explain why their work is hard, complain about what slows them down and describe what they wish they could do.

When something overlaps with my area, I start pulling on the thread. I might ask, “If X existed, would it solve your problem?” or point them at an existing feature in a product I own and ask how much of their use case it covers.

Users often ask for a particular solution instead of explaining their root issue. Rather than taking the request at face value, I keep digging until I understand what they are trying to accomplish and why existing products do not work for them.

As a natural introvert, this sort of ambient listening works particularly well for me. I don’t need to fill my calendar with speculative meetings just to find ideas; there is already an enormous amount of useful information flowing around me during a normal week.

When a problem seems worth exploring, though, I become more active; I need to see how it affects the team’s day-to-day work. I’ll sit with them as they walk me through their workflows and the bugs they’re investigating. When I can, I’ll try working through some of those bugs myself. Seeing the problem firsthand makes it easier to separate what the team actually needs from the solution they asked for.

I also seek out people who see more of the organization than I do: those who own critical systems, work across several teams or have particularly deep insight into the work downstream of my team. I’ll arrange a 1:1 or coffee chat and ask about interesting problems they’ve come across. They may have already seen the same issue in several places and started connecting the dots, giving me a head start on patterns I might otherwise have taken much longer to notice.

Let problems accumulate

Several times, I’ve been burned by moving too fast. I became excited by a request from a vocal team, built the feature and watched them barely use it. Their priorities had changed, or the request had come from a one-off investigation that no longer mattered. How eager a team was in that moment wasn’t the same as how important the feature was relative to everything else my product needed to support. By hyperfocusing on their request, I lost sight of the bigger picture.

That taught me to let potential problems pile up. Listening the way I do leaves me with far more of them than I could possibly solve, and not all deserve action. Most don’t need to turn into projects the first time I hear about them; waiting can be a superpower.

Waiting means the same problem might pop up independently in different teams, making it a higher priority to solve. Or problems that look different on the surface might turn out to have the same shape, so I can address several use cases in one shot. Or, as I’ve learned painfully, the requesting team didn’t even care that much in the first place.

Instead, I make a mental note and revisit the problem if it comes up again. Other engineers I know write this sort of thing down more systematically. The mechanism is a personal choice: everyone has to figure out what works for them. What matters is keeping unresolved problems around long enough for more evidence to accumulate.

Find the common shape

Waiting helps me collect evidence, but that alone doesn’t tell me what to build. I still need to work out whether the problems I’ve retained are genuinely related and what, if anything, could address them together.

Perfetto, the performance debugging tool I work on, is a good example. It displays recordings of system activity on a timeline made up of rows called “tracks.” Over a couple of years, teams kept asking for small, specific additions to the UI. One wanted a command to keep their preferred tracks pinned to the top of the screen; the next team wanted the same, but for a completely different set of tracks. Others wanted Perfetto to open already zoomed in on a particular part of a recording, or to show a custom aggregation tuned to what they cared about. A few had stopped waiting for us and built elaborate workarounds with bookmarklets.[1]

By the time enough of these had piled up, my head was the usual tangle: the requests themselves, the constraints on each and a handful of half-formed solutions. I’ve learned not to force a solution by just sitting at a desk and thinking. Instead, my best untangling happens on long, aimless walks around London, where connections come more easily when I’m not trying to force them.

What I eventually realized was that none of these teams really wanted the specific feature they’d asked for. Each wanted to personalize Perfetto for their own workflow without imposing their choices on everyone else. The underlying need wasn’t any one feature but rather the ability to extend the UI. When a connection like that finally clicks, it’s one of the best feelings in the job: several awkward requests collapse into a single idea, and possibilities open up that none of them hinted at on their own.

That feeling, though, is exactly when I have to be careful, because a common shape is only a hypothesis and elegance is not evidence. When it happened with extending the UI it turned out to be real, but I’ve been fooled before.

In another recent case I was convinced that building a transparent caching system for querying Perfetto traces would solve issues with sharing large traces and repeated queries. It was only as I wrote the RFC and built a prototype that I realized the elegance was a lie: the two problems wanted genuinely different solutions. I reluctantly split the design in two, both halves of which have since shipped.[2]

Pressure-test before building

You’d think this would be the moment I start building, but it usually isn’t. How far I go depends on how sure I am that the idea works and that people actually want it.

If something is useful and low-risk enough, I act straight away: I send the change and let my manager know. When I’m unsure whether an idea will work or how much effort it will take, I build a throwaway prototype instead; it exposes the failure points and gives me something concrete for others to react to. And when an idea is big but I’m convinced by it, I commit to the full effort: weeks or months of work and the hard yards of building support across other engineers and teams.

Through all of it, I’m not only trying to convince other people; I’m also trying to convince myself. Sometimes the honest answer is to stop: if people don’t see the value I do, or we hit a major technical wall, I’d rather drop the idea now than build something no one uses or that becomes a maintenance nightmare. And sometimes it holds up but the timing is wrong, so I park it, ready to spring into action the day it becomes an org priority.

When an idea does hold up, I don’t necessarily need to be the person who builds it. I might implement it, someone else on my team might, or it might change what the org focuses on. Finding and shaping the right problem can have an impact even when I don’t own the implementation.

The Perfetto extensions idea was worth that full effort. We were already building plugins to modularize the UI, but they weren’t enough: teams had to open source all their plugin code, which wasn’t an option for many internal use cases. So before building anything new, I took the problem and my proposal to my manager, teammates and the client teams. I ended up writing two RFCs, having several 1:1s and giving a couple of talks, refining it as the feedback came in.

In the end, I designed and implemented macros as “lightweight extensions”: a way to automate actions in the UI without writing a plugin. Extension servers took the idea further by letting teams share their macros.

Instead of implementing every requested feature ourselves, we gave teams ways to adapt Perfetto to their own needs. Dozens of teams inside Google now use macros and extension servers, and several other companies use extension servers internally too.

Solving useful problems helps me find the next one

The more often I go through this process, the easier it becomes. When I show genuine interest in someone’s problem, ask useful questions or help solve it, they remember. They start coming to me earlier and bring me into conversations with other people facing related issues.

That gives me a wider view of what is happening across the organization, making it easier to spot patterns and build things people actually need. Solving one of those problems brings me into more conversations, and the loop continues.

Those successes build the kind of trust that comes from long-term stewardship. Early on, I had to turn many of these ideas into something real myself to prove that my judgment was sound. Over time, my manager and org gave more weight to my assessment of what mattered. That allowed me to influence the roadmap without needing to own every project.

This differs from the idea that becoming a staff engineer means replacing technical work with meetings and coordination. For me, conversations are inputs into what I build, not the end result.

Conclusion

That is what I wanted my mentee to understand: finding problems worth solving isn’t separate from the rest of the job. It comes from staying engaged with people’s work long enough to see what no single request can show you.

References

  1. These workarounds used bookmarklets to run JavaScript against Perfetto’s internal UI APIs.
  2. The original proposal was to use a transparent cache for repeated queries and faster reopening of large traces. As I worked through it, I realized repeated queries were better served by keeping sessions warm in memory, whereas reopening was better served by explicitly exporting a trace into a format designed to load quickly. A transparent disk cache could also retain multi-gigabyte files without the user realizing and would need a new system to manage their lifetime. The proposal was ultimately replaced by warm sessions and streaming table export. 

The Tech Talent We’re Not Looking For Because It’s Already Here

Mike's Notes

Dorenda's dyslexic brother, John Britten, made the carbon-fibre elbow crutches that enabled my Tracy to complete the NZ Coast-to-Coast. The only paraplegic to ever do so.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

08/10/2026

The Tech Talent We’re Not Looking For Because It’s Already Here

By: Dorenda Britten
Tech New Zealand: 05/10/2026

Dorenda Britten: Co-Founder and Co-Developer, Peppr | Co-Founder, Unlock Innovation.

...

Dyslexia Awareness Week, 6–12 October 2026

As New Zealand’s technology sector grapples with AI, rapidly changing skills requirements and the challenge of finding the people it needs to innovate, there is another question worth asking: do we actually know what talent we already have?

For Dyslexia Awareness Week, perhaps it is time to look at dyslexia through a different lens. Dyslexia is usually discussed in terms of reading, writing and workplace accommodations. These things matter. But focusing only on the difficulties can mean overlooking something potentially very valuable to New Zealand’s technology sector: a different way of thinking.

Because 1 in 5 people are dyslexic whether they know it or not, the chances are you already employ people with hidden talents. Research by EY and Made By Dyslexia identified a range of capabilities associated with dyslexic thinking, including creativity, visualisation, cognitive flexibility, logical reasoning, systems analysis, complex problem solving and empathy.

Significantly for the technology sector, the research also makes connections with areas including programming, technology and user-experience design and customer relations.

Not every dyslexic person will have the same strengths. But the broader picture raises an interesting question for employers.

Are we recognising these capabilities when they are already sitting inside our teams and peppered through your job application processes?

AI makes the question more urgent. The World Economic Forum’s Future of Jobs Report 2025 found that analytical thinking remains the number-one core skill identified by employers. Creative thinking is fourth, while systems thinking is also among the core capabilities employers identify as important.

Looking towards 2030, the report expects AI and big data, analytical thinking, creative thinking, resilience and flexibility, technological literacy, curiosity, systems thinking and empathy all to continue increasing in importance.

There is an interesting convergence here. As organisations invest heavily in AI some of the human capabilities they increasingly need, alongside that technology, are also capabilities frequently associated with dyslexic thinking. That should matter to the technology sector. AI can process enormous quantities of information and increasingly undertake routine and repeatable work. But organisations still need people who can ask different questions, recognise patterns, imagine alternatives, make unexpected connections and see a problem from another perspective.

What did we find in New Zealand? Our interest in this began through work undertaken by Unlock Innovation (now Peppr) in New Zealand’s technology sector. Our 2022 Tech Skills Pilot, supported by MBIE, involved New Zealand technology businesses and revealed a significant presence of people who identified as dyslexic, including people whose dyslexia had not necessarily been visible or declared within their workplace. 

It prompted a much bigger question for us. If organisations don’t know who their different thinkers are, how can they intentionally include their thinking when they are trying to innovate?

The answer is not simply to identify dyslexic employees or put another label on People. It is to examine the systems around them. How do we run meetings? How do we communicate ideas? Who gets heard? How do we recruit and promote people? How do we form innovation teams? And do our processes favour people who communicate and process information in conventional ways?

An organisation can employ brilliant different thinkers and still unintentionally design them out of the innovation process.

From awareness to advantage

This is why we believe the conversation around dyslexia needs to move beyond awareness alone. Awareness is important, but recognition and inclusion are where organisations begin to see value. This work is now continuing with the University of Canterbury to further investigate the relationship between dyslexia, different thinking and innovation. We want to better understand what happens when organisations deliberately create conditions in which different thinkers can contribute their capabilities.

For New Zealand’s technology sector, this could become increasingly important.

The conversation about our future workforce often begins with a skills shortage: Where will we find the people with the capabilities we need?

During Dyslexia Awareness Week, we’d like technology leaders to consider a different starting point: what if some of the talent you are looking for is already in your organisation, but you haven’t yet learned how to see it? This may be one of New Zealand’s most overlooked opportunities for innovation.

Skeptic vs. 'Doomer': How Scared Should We be of Rogue AI?

Mike's Notes

I agree with Gary Marcus.

The insight I got from watching this interview is that hallucinations in LLM results are generally statistical because they rely on probabilistic vectors. But statistics apply to populations, not individuals. Everything about an individual is a fact.

Resources

References

  • Algebraic Mind, The: Integrating Connectionism and Cognitive Science, by Gary Marcus. 2001.

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Quillette
  • Home > Handbook > 

Last Updated

07/10/2026

Sceptic vs. 'Doomer': How Scared Should We Be of Rogue AI?

By: Jonathan Kay
Quillette: 02/10/2026

 Jonathan Kay: Mike invented and designed Pipi and founded Ajabbi.

Gary Marcus: Cognitive scientist Gary Marcus, author of The Algebraic Mind and Taming Silicon Valley and writer of the Substack Marcus on AI

...

Quillette podcast host Jonathan Kay interviews AI expert Gary Marcus about the possibility that a rogue artificial intelligence will turn us all into paper clips.

...

This week, I’m going to tackle a big and important subject—artificial intelligence and the risks it could pose to society.

I’m going to be honest here. I’ve been putting this subject off because it’s so big and so technical that I felt intimidated by it.

But the subject is increasingly dominating the news, and I’m a journalist, so it’s time to face the music.

Maybe you’ve been putting off educating yourself about this subject for the same reason.

If so, we’re in this together. So let’s dive in.

The good news is that my guest this week, Gary Marcus, is a real expert—someone who’s been theorising and writing about AI—including its dangers—for more than a quarter century. He’s a well-known American psychologist, cognitive scientist, and book author, who also runs the popular AI blog, Marcus on AI.

But before I run that interview, which I recorded last week, let’s review some key terms, so that the discussion you’re about to hear makes the maximum amount of sense.

First of all, and I’m grossly simplifying here, AI comes in two big categories.

The first, which you’ll hear Gary often refer to as “Symbolic AI,” basically operates like a very big and very sophisticated version of a conventional computer program, with lots of rules, and decision trees, and if-then statements—just like you remember from middle-school computer class, except much, much bigger.

This kind of AI is great for, say, creating a database, or setting out rigid decision trees for an airline pilot to follow. But it’s really bad at a lot of basic tasks that even small children can do, like, say distinguish a dog from a cat, or a plate from a frisbee.

The second kind of AI, which you’ll hear us refer to as “neural networks,” or machine learning, or deep learning, which are overlapping concepts, is completely different.

This kind of AI, which became ascendant in the early 2010s, isn’t created with human instructions. Rather, these systems teach themselves by reference to massive troves of pre-existing data—including through a technical process you’ll hear me refer to as backpropagation.

By way of example, let’s say you want to create a neural network to identify a cat. Instead of writing thousands of lines of code relating to fur and whiskers and meowing noises, you just show the neural network millions of pictures of cats and millions of pictures of things that aren’t cats; and then instruct the computer to teach itself the difference between the two by a computational process of trial and error.

The idea here is that the neural network will start with a completely useless algorithm, then compare the results to the data set, and then try again with tweaked parameters, teaching itself—though a process of machine learning—to refine its self-created algorithms so that it better aligns with the data you’ve already given it.

The humans aren’t giving the computer rules about what a cat is or isn’t. They’re just providing the data trove and then hitting the go button and the computer teaches itself.

These systems are easy to scale, by supplying them with more data and computing power—which is one of their big selling points to investors.

But the problem is that the iterative, self-constructed nature of these mechanisms means they aren’t grounded by predictable rules, and so can sometimes hallucinate artificial realities—a problem that Gary predicted in a 2001 book. Even something as basic as a simple database of public figures, the sort of thing human-resources department at large companies were creating on 1970s-era mainframes, is alien to the neural network information architecture.

As a result, purely neural-network-driven AI systems aren’t very good at following user-supplied rules, even fairly basic ones, like, “write me an academic paper with citations, but make sure those citations aren’t made up,” or “find and download some information for me, but please don’t hack into any proprietary servers in the process,” or, more speculatively, “make a trillion paper clips for me, but don’t make any of them from the bodies of humans.”

I know that last one sounds weird, but I promise it will make sense when you listen to the podcast,

All of this has set off a movement known as the AI doomers, who don’t just think AI will take our jobs and access our banking information—but that it will cause the extinction of humanity itself, by launching nuclear weapons, or creating and unleashing some kind of super powerful bioweapon.

While my guest is not a doomer, he does call himself a sceptic, especially when it comes to what he regards as the allegedly irresponsible and dangerous business practices of certain companies—OpenAI, in particular.

Unlike U.S. senator Bernie Sanders, he doesn’t want to ban hyper-advanced AI systems that greatly surpass human capabilities (which is sometimes called superintelligence). But Gary also doesn’t approve of Donald Trump’s apparently laissez-faire attitude, either.

And he’d like to see a more balanced approach from government, an approach that holds AI companies to account if they don’t place appropriate safeguards on their products, and align those products with human values.

And what would those safeguards look like?

Well, this gets us back into the technical sphere. Gary has long advocated something called neurosymbolic AI, which combines the extraordinary power of neural networks with some of the safeguarding and fact-checking features that can be implemented through the rules-based, predictably algorithmic features of so-called “classic AI”.

It’s all very complicated, I know, but I’m confident I have the guest who can walk us through it.

Please enjoy my interview with Gary Marcus, AI expert extraordinaire.



Stealth Mode continues

Mike's Notes

After a recent trip to Christchurch, NZ, recruiting for the mission is underway, and Ajabbi and Pipi will stay in stealth mode until they are strong enough to rapidly scale without limits.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

11/10/2026

Stealth Mode continues

By: Mike Peters
On a Sandy Beach: 25/09/2026

Mike Peters: Mike invented and designed Pipi and founded Ajabbi.

...

4-18 September 2026 Christchurch visit

While on holiday in Christchurch, opportunities and openness were confirmed by visiting the following;

  • KiwiSaaS Meetup
  • KiwiSaaS Leaders Breakfast
  • IT Curry Meetup
  • AI Meetup
  • Westpac Smarts
  • WordPress Meetup
  • BDI
  • Interested people
  • ChristchurchNZ
  • Business Canterbury
  • NZTE
  • Ministry of Awesome
  • Epic Innovation
  • Collaboration with University of Canterbury Faculty of Engineering
  • Libraries, legal, commercial office, printing, banking, transport options, data centre, and electrical services

The CBD is compact, with good public transport that makes walking easy and simplifies collaboration and access to resources. Much of the built infrastructure is new, and Christchurch has become a magnet for technical talent.

One thing Mike learned was the importance of being surrounded by good people, and that getting the culture right and building a great team will take time. This is a critical foundation for scaling.

A big hard problem

Global IT waste from project failure exceeds $100 billion annually (IEEE).

AI slop will only add to the problem.

Why Ajabbi

Ajabbi exists to reduce failure in massive enterprise systems for socially useful critical infrastructure. Ajabbi is a bootstrapped, mission-led organisation with no investors. All future profits will go to a yet-to-be-established non-profit foundation to fund open research, science communication, and support for the Pipi user community.

Origins

Pipi originated as a national platform for community-led ecological restoration in New Zealand, built and operated by NZERN. Mike founded NZERN and served as National President and software architect. The NZ government funded Pipi version 4 and later valued it at $3M, with a great team, 300K lines of code, and a 3-rack data centre. A bad business model, the Christchurch earthquakes, and a change of government funding ended it all.

In Invercargill in 2017, Mike rebuilt Pipi from memory as version 6, then refactored and merged it with open-source biological cell simulation software, eventually making it a self-managing complex adaptive system (CAS). The intent was to make Pipi self-funding by being useful in multiple domains, solving the business model problem. Invercargill was a great place to do the initial work because of the city's obvious critical infrastructure problems.

10 years later, at version 9, it has become a non-LLM SaaS platform that runs 3,000K lines of code on CPU, is constrained by the laws of physics, and can self-manage, learn, evolve, and replicate; it is designed to host large, complex systems and gives them the same properties and real-world model context. It has a large closed core, and Pipi can automatically generate many open-source SaaS applications from ontologies and configuration.

Pipi also has many other unique capabilities to explore, offering other possible income streams to support the mission.

Stealth mode

Ajabbi and Pipi operate in stealth mode, with 99% of the system hidden. Mike keeps research notes on the build-out for his own use in an engineering blog, "On a Sandy Beach". Still, a community has grown, with a waitlist. Blog traffic is growing rapidly. Initial community testing with a closed beta has been roughly successful. It's good enough to move forward confidently, solving issues as you go. Because "an exit" isn't the goal, the biggest threat is getting swamped by rapid growth, so stay in stealth mode.

Now prove it

Pipi makes a big claim: Developers will need to prove the black box works by testing, using, and then telling others. With a long runway from upfront usage fees, it's cash-flow positive from day one and covers its very low costs. It's ready to go live, staying 100% reliable, secure, and safe while slashing customer costs. It is a SaaS platform for developers to build reliable, self-managing enterprise systems using no-code, plugins and API.

Slow and steady, community-driven, it can expand to many cloud platforms, human languages, and writing systems, with a highly adaptive, accessible UI for everyone. Eventually, the enterprise layer can be donated to the Cloud Native Foundation.

Next steps

This is a rough sketch that will no doubt change along the way.

  1. Carefully complete setup of legal, tax, banking, etc.
  2. Lead with developer docs, training videos, recorded live demos, polished Ajabbi websites, recorded slide talks, live talks ready, white papers, newsletters, logo, business cards, and recruiting for the mission.
  3. Stay in stealth mode.
  4. Move Ajabbi onto an Ajabbi enterprise account to become self-managed using Pipi (Dogfooding).
  5. Go live for a single customer carefully chosen from the waitlist. Prove it. Refine. Repeat. Grow by one customer at a time so that they all succeed. Give lots of in-person talks to groups.
  6. Grow by word-of-mouth referrals among developers while staying in stealth mode. Accumulate funds. Grow the ecosystem. Build a great team.
  7. Resource and configure Ajabbi and Pipi to rapidly scale without limits.
  8. Escape from stealth mode.
  9. ...

MedGemma: Google's open models for Health AI development

Mike's Notes

I recently attended the excellent Google Startup School: HealthTech. Most video sessions were in the early hours (NZ Time), so I watched them on demand.

A virtual series exploring cutting-edge technology, cloud infrastructure, and the future of care. Held September 24, 2026-October 1, 2026.

Looks great, lots of possibilities for integrating MedGemma with Pipi in the future.

Resources

References

  • MedGemma 1.5 Technical Report, [v2] Fri, 1 May 2026, arXiv:2604.05081.

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

05/10/2026

MedGemma: Google's open models for Health AI development

By: Daniel Golden
YouTube: 24/09/2026 53:32

Daniel Golden: Dan is a Software Engineering Manager in Google Research, where he has worked since 2019 (including one year at Verily) on AI diagnostic and generative systems for ophthalmology, radiology, pathology, and healthcare more broadly. He leads the Health AI Developer Foundations (HAI-DEF) program in Google Research, which focuses on developing MedGemma and other open multimodal foundation models for healthcare, as well as tools that help developers build medical AI applications more effectively.

...

Explore Google’s family of open medical AI models, including MedGemma, and learn how they are purpose-built for healthcare workloads. Discover how engineering and clinical research teams fine-tune and deploy these models securely on Google Cloud to accelerate diagnostic workflows and build next-generation health applications.

YouTube: 24/09/2026
Play length: 53:32