Mentorship Cafe [GFS Rising Founders]

Mike's Notes

I had to get up yesterday morning at 3am (NZ Time) to attend the Mentorship Cafe organised by Google. I learned a lot.

Resources

  • Resource

References

  • Reference

Repository

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

Last Updated

15/10/2026

Mentorship Cafe [GFS Rising Founders]

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

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

...

Google for Startups (GFS) Rising Founders Community is a global initiative Google created to support high-potential tech startup founders.

I have been attending some of it, as long as the hours aren't in the middle of the night. It has been useful.

Yesterday, there was a 90-minute Mentorship Cafe. I had applied and was successful. There were two 30-minute one-on-one sessions with a mentor. It was excellent; this is what I learned from Georg, John and Kennedy.

Context

Ajabbi is mission-led, bootstrapped, with no investor funding planned. All profits go to a non-profit foundation. Its SaaS product, Pipi, solves a very hard problem.

My questions

How do I recruit a remote workforce for the mission? How do I know I found the right people? How do I connect with Google DeepMind? Connecting Pipi to Gemini will be a 2-way experiment.

Mentors

  • Build a community first.
  • Grad students like to have a project anyway.
  • Creds on their CV for career building.
  • Be associated with a big name (University, etc).

Discussion

  • Ajabbi is using "Honey Traps" to attract people with the right mindset/talent.

Actions

  • Update Stealth Mode plan

The Martians

Mike's Notes

The Martians is the working title for a long-term publishing and associated screen project currently in Development.

With help from Google Search AI Mode, here is some historical background on some of the main characters (some of whom appeared in Christopher Nolan's film Oppenheimer). This project will be self-funded by the future Ajabbi Foundation.

This project exists because Pipi uses much of the maths and science these people developed.

I read Ananyo Bhattacharya's excellent book, The Man from the Future: The Visionary Life of John von Neumann, last month while researching Hilbert Spaces to add to Pipi in a future release.

The top secret sneaky plan

As part of the forthcoming Pipi documentation going on the Ajabbi websites, these scientists and mathematicians will be featured alongside their insights, including references to read, embedded video, and Jupyter Notebooks. This will happen early on.

As resources allow, this effort will expand to include other scientists of the period, including Einstein, etc., historical reenactments with actors, and the factual historical factors at play.

This science communication resource will be made freely available to all, and can also be used for teaching, exhibitions, documentaries and historical drama for TV, etc.

This project is well underway. Redworks will be an initial development vehicle once we quickly sort out some minor legal and tax issues.

Resources

References

  • The Man from the Future: The Visionary Life of John von Neumann by Ananyo Bhattacharya. Penguin (2022).
  • Macrae, Norman (1992). John von Neumann: The Scientific Genius Who Pioneered the Modern Computer, Game Theory, Nuclear Deterrence, and Much More. Pantheon Press. p. 33. ISBN 0-679-41308-1.
  • Marx, George (2001). The Voice of the Martians: Hungarian Scientists Who Shaped the 20th Century in the West. Budapest: Akadémiai Kiadó. ISBN 963-05-7830-1. OCLC 48621487.

Repository

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

Last Updated

14/10/2026

The Martians

By: Mike Peters
Redworks: 13/10/2026

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

...

The Martians is a working title for a publishing and associated screen project under development. It is about how a group of Hungarian Jews revolutionised mathematics and physics between the French Revolution and WW2. The slow decay of the Austro-Hungarian Empire led to WWI, then to the Russian Revolution, Stalinism, and the rise of Hitler. The project ends with the start of World War II.

The sudden explosion of genius from late 19th and early 20th-century Budapest is one of the greatest intellectual mysteries of modern history. Historians generally agree that it wasn't a coincidence, but rather the result of a highly specific "perfect storm" of political, educational, and cultural factors unique to the Austro-Hungarian Empire.

Here are the primary reasons why this specific environment bred such extraordinary minds:

1. The Legendary High Schools (Gimnáziums)

The Hungarian secondary education system at the time is widely considered one of the best in human history. Following reforms in the late 19th century, the state established gimnáziums (high schools) modelled after the rigorous German classical system, but with a heavier emphasis on mathematics and hard sciences.

  • Elite Teachers: Because university positions were limited, many world-class scientists and mathematicians taught at the high school level.
  • The "Fasori" Phenomenon: Schools like the Fasori Evangélikus Gimnázium produced John von Neumann and Eugene Wigner in the exact same generation.

2. A Hyper-Competitive Culture of Math

Hungary turned mathematics into a highly prestigious, nationwide competitive sport.

  • The KöMaL Journal: Founded in 1894, this monthly high school mathematics and physics journal published incredibly difficult, creative problems. Students from all over the country mailed in their solutions, which were graded and published. This created a national, collaborative network of young geniuses who pushed each other to their absolute limits before ever reaching university.
  • The Kürschák Competition: This annual, blind-graded mathematics competition identified the country's top talent, turning young mathematicians into national celebrities within academic circles.

3. Jewish Emancipation and the "Golden Age" of Budapest

Following the Austro-Hungarian Compromise of 1867, Jews in the empire were granted full civil rights. This triggered a massive wave of urbanisation, and Budapest quickly grew into a booming, wealthy metropolis.

  • The New Middle Class: Barred from traditional aristocratic roles like landownership or politics, the newly emancipated Jewish population poured their wealth and energy into education, medicine, science, and industry. Most of the "Martians" came from this highly driven, affluent Budapest Jewish bourgeoisie, where intellectual achievement was viewed as the ultimate status symbol.

4. The "Budapest Coffee House" Culture

Much like Vienna, Budapest developed a vibrant coffee house culture. Intellectuals, writers, artists, and scientists did not lock themselves in laboratories; they spent their afternoons in cafes like the New York Café or Café Centrál. Ideas from physics, psychology, literature, and economics were fiercely debated across disciplines, fostering lateral thinking, intense debate, and intellectual agility.

5. A State of Creative Anxiety

The "Martians" grew up in a world of profound instability. They witnessed the collapse of the Austro-Hungarian Empire, a communist revolution, a Stalinist counter-revolution, hyperinflation, and the rapid rise of virulent anti-Semitism and Fascism.

  • This created what Eugene Wigner called a "feeling of extreme insecurity" and an awareness that everything they owned could be taken away—except what was inside their minds.
  • This background forced them to be adaptable, highly driven, and comfortable with chaos, traits that proved invaluable when they later had to solve unprecedented problems in wartime America.

"The Martians" (Hungarian: A marslakók) was a nickname for a group of exceptionally brilliant Hungarian physicists and mathematicians who emigrated to the United States in the early 20th century. Most were secular Jewish refugees fleeing Nazi expansion and rising anti-Semitism in Europe.

The name originated as a joke among colleagues like Enrico Fermi and Leo Szilárd. When discussing the Fermi Paradox—asking why there is no evidence of intelligent extraterrestrial life—Szilárd quipped that aliens were already here, but they simply disguised themselves as Hungarians. The moniker stuck because these scientists possessed seemingly superhuman intellects, all grew up within walking distance of each other in Budapest, and spoke English with a thick, matching accent.

Core Members of "The Martians"

While the wider group included up to 23 thinkers, the core group of five distinct "Martians" reshaped modern physics, defence, and computing:

  • John von Neumann (1903–1957): Widely considered one of the greatest mathematicians of the 20th century.
  • Leo Szilárd (1898–1964): The visionary physicist who conceived the nuclear chain reaction.
  • Edward Teller (1908–2003): Theoretical physicist known historically as the "father of the hydrogen bomb".
  • Eugene Wigner (1902–1995): Theoretical physicist who won the Nobel Prize in Physics in 1963.
  • Theodore von Kármán (1881–1963): A pioneer in aerodynamics and mathematics.
Others included:
  • Denis Gabor: A physicist who won the 1971 Nobel Prize in Physics for inventing holography.
  • John G. Kemeny: A mathematician and computer scientist who co-developed the BASIC programming language.
  • George Pólya: Mathematician
  • Paul Erdős: One of the most prolific mathematicians in human history, known for his eccentric lifestyle and work in combinatorics and number theory.
  • Cornelius Lanczos:
  • Egon Orowan:
  • Franz Alexander:
  • George de Hevesy:
  • George Olah:
  • John Harsanyi:
  • John Polanyi:
  • Paul Halmos:
  • Paul Neményi:
  • Peter Carl Goldmark:
  • Peter Lax:
  • Valentine Telegdi:

Impact on Science and Mathematics

The Martians did not just contribute to their fields; they laid the bedrock for the technology, national security, and computational infrastructure of the modern world.

  • The Von Neumann Architecture: John von Neumann designed the framework for modern digital computers. He pioneered the system in which data and program instructions are stored in the same memory space—a fundamental structure that nearly all desktop computers, smartphones, and servers still use.
  • Cellular Automata: Von Neumann created the concept of cellular automata, modelling self-reproducing systems on computer screens before the biological role of DNA was even fully understood.
  • The Nuclear Chain Reaction: In 1933, Leo Szilárd conceived the idea of a neutron-driven nuclear chain reaction and patented it.
  • The Manhattan Project: Recognising the threat of Nazi Germany, Szilárd drafted the famous Einstein–Szilárd letter to President Franklin D. Roosevelt, which sparked the creation of the Manhattan Project. Von Neumann, Wigner, and Teller all performed core calculations that made the atomic bomb a reality.
  • Thermonuclear Weapons: Post-WWII, Edward Teller drove the physics and design behind the first hydrogen bomb, fundamentally changing Cold War geopolitics.
  • Aviation & Space Flight: Theodore von Kármán provided the mathematical and scientific foundation for modern aerodynamics. He discovered the Kármán vortex street (fluid dynamics) and helped establish the U.S. Air Force’s research wing.
  • JPL Founding: Von Kármán later co-founded NASA's legendary Jet Propulsion Laboratory (JPL).
  • Game Theory: John von Neumann co-created mathematical Game Theory, publishing Theory of Games and Economic Behaviour. This framework mathematically analyses strategy, risk, and decision-making, transforming modern economics, evolutionary biology, and military strategy.
  • Quantum Mechanics: Eugene Wigner introduced Group Theory into quantum mechanics. His work on the symmetries of atomic nuclei earned him a Nobel Prize.
  • Heuristics and Education: George Pólya wrote How to Solve It, a foundational text that systematically defined how to approach and teach mathematical problem-solving.

SPDX License List

Mike's Notes

A fantastic resource. Will use it to sort out open-source licensing.

"System Package Data Exchange (SPDX, formerly Software Package Data Exchange) is an open standard capable of representing systems with digital components as bills of materials (BOMs).[2] First designed to describe software components, SPDX can describe the components of software systems, AI models, software builds, security data, and other data packages. SPDX allows the expression of components, licenses, copyrights, security references and other metadata relating to systems.[3]

The original purpose of SPDX was to improve license compliance,[4] and it has since been expanded to facilitate additional use cases such as supply-chain transparency and security.[5] SPDX is authored by the community-driven SPDX Project involving key industry experts, organizations, and open-source enthusiasts under the auspices of the Linux Foundation.

The SPDX specification is recognized as the international open standard for security, license compliance, and other software supply chain artifacts as ISO/IEC 5962:2021. As of August 2025, the latest version of the standard has been 3.0.1.[1]" - Wikipedia

Legal advice

Edwin Lim, a lawyer at Hudson Gavin Martin (HGM), is my go-to for licensing advice.

Resources

References

  • ISO/IEC 5962:2021

Repository

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

Last Updated

13/10/2026

SPDX License List

By: 
SPDX: 16/09/2026

...

The SPDX License List is an integral part of the SPDX Specification. The SPDX License List itself is a list of commonly found licenses and exceptions used in free and open or collaborative software, data, hardware, or documentation. The SPDX License List includes a standardized short identifier, the full name, the license text, and a canonical permanent URL for each license and exception.

The purpose of the SPDX License List is to enable efficient and reliable identification of such licenses and exceptions in an SPDX document, in source files or elsewhere.

License Exceptions are commonly found exceptions to free and open source licenses, used with the License Expression operator, "WITH" to create a license with an exception.

The matching guidelines define what constitutes a license or exception match. The license text on the HTML pages here will display omitable text in blue and replaceable text in red (see Guideline #2 for more information).

Explanation of fields used on the SPDX License List

  • License inclusion principles for adding new licenses or exceptions to the SPDX License List
  • Contribute to the project or request a new license
  • Use short identifiers in your source code
  • Github repo
  • Machine readable data files for the SPDX License List

[Example of data]

Note: You can sort by each column by clicking on the column header. By default, the table sorts by the Identifier column.

Full name Identifier FSF Free/Libre? OSI Approved?
BSD Zero Clause License 0BSD Y
3D Slicer License v1.0 3D-Slicer-1.0
Attribution Assurance License AAL Y
Abstyles License Abstyles
AdaCore Doc License AdaCore-doc
Adobe Systems Incorporated Source Code License Agreement Adobe-2006
Adobe Display PostScript License Adobe-Display-PostScript
Adobe Glyph List License Adobe-Glyph
Adobe Utopia Font License Adobe-Utopia
Amazon Digital Services License ADSL
Advanced Cryptics Dictionary License Advanced-Cryptics-Dictionary
Academic Free License v1.1 AFL-1.1 Y Y
Academic Free License v1.2 AFL-1.2 Y Y
Academic Free License v2.0 AFL-2.0 Y Y
Academic Free License v2.1 AFL-2.1 Y Y
Academic Free License v3.0 AFL-3.0 Y Y
Afmparse License Afmparse

Deprecated License Identifiers

SPDX endeavors to never change the SPDX license identifiers. However, sometimes there has been a compelling reason to deprecate a license identifier, such as to accommodate improved SPDX license expressions or when we have found a duplicate license. When a license identifier is "deprecated" on the SPDX License List, it effectively means that there is an updated license identifier and the deprecated license identifier, while remaining valid, should no longer be used. The URL to each deprecated license is retained and those license pages are updated to note the deprecation. Some reasons for deprecation are as follows:

  • Release 2.0 of the SPDX Specification introduced License Expressions that supports the ability to identify common variations of SPDX-identified licenses without the need to define each potential variation as a distinct license on the SPDX License List. This new syntax supports the ability to declare an SPDX-identified license exception using the "WITH" operator (e.g. GPL-2.0-or-later WITH Autoconf-exception-2.0), as well as the ability to use a simple "+" operator after a license short identifier to indicate "or later version". SPDX has defined a list of license exceptions to use after the "WITH" operator. As a result, a number of licenses formerly included on the SPDX License List have been deprecated, and correct usage employs the License Expression syntax as of v2.0.
  • Release 3.0 replaced previous Identifiers for GNU licenses with more explicit Identifiers to reflect the "this version only" or "any later version" option specific to those licenses. As such, the previously used Identifiers for those licenses are deprecated as of v3.0.
  • Other licenses may have been deprecated for the reasons noted.

[Example of data]


Full name Identifier Deprecated as of:
Affero General Public License v1.0 AGPL-1.0 3.1
GNU Affero General Public License v3.0 AGPL-3.0 3.0
BSD 2-Clause FreeBSD License BSD-2-Clause-FreeBSD 3.10
BSD 2-Clause NetBSD License BSD-2-Clause-NetBSD 3.9
bzip2 and libbzip2 License v1.0.5 bzip2-1.0.5 3.16
eCos license version 2.0 eCos-2.0 2.0rc2
GNU Free Documentation License v1.1 GFDL-1.1 3.0
GNU Free Documentation License v1.2 GFDL-1.2 3.0
GNU Free Documentation License v1.3 GFDL-1.3 3.0

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 tied up loose ends and gained an unexpected new insight. A work in progress.

Resources

References

  • Reference

Repository

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

Last Updated

13/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. A White Paper has been published with the full table.

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

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.