On Being a Scientist: A Guide to the Responsible and Ethical Conduct of Research: Fourth Edition 2026

Mike's Notes

Useful for future reference. The guide can be read freely online.

Resources

• https://www.nationalacademies.org/news/national-academies-release-new-edition-of-widely-used-guide-to-responsible-research
• https://www.nationalacademies.org/projects/PGA-POLICY-21-13/publication/29488
• https://doi.org/10.17226/29488

References

• National Academies of Sciences, Engineering, and Medicine. 2026. On Being a Scientist: A Guide to the Responsible and Ethical Conduct of Research: Fourth Edition. Washington, DC: The National Academies Press. https://doi.org/10.17226/29488. 2026. On Being a Scientist: A Guide to the Responsible and Ethical Conduct of Research: Fourth Edition. Washington, DC: The National Academies Press.

Repository

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

Last Updated

22/10/2026

On Being a Scientist: A Guide to the Responsible and Ethical Conduct of Research: Fourth Edition 2026

By: Megan Lowry

The National Academies of Sciences, Engineering, and Medicine: 17/09/2026

Megan Lowry: Megan Lowry is Manager, Media Relations, of the Office of News and Public Information at the National Academies of Sciences, Engineering, and Medicine.

...

WASHINGTON — The National Academies of Sciences, Engineering, and Medicine today released an update of On Being a Scientist: A Guide to the Responsible and Ethical Conduct of Research. This fourth edition is organized into online, thematic modules, and reflects the evolution of the scientific enterprise since the last version in 2009 by including new topics such as research security and responsible collaboration.

On Being a Scientist introduces students and early-career researchers across disciplines and sectors to the fundamental values that guide responsible research — such as objectivity, honesty, and openness — and explores the increasingly complex research contexts in which they need to be applied. The report was mandated by Congress.

“The research enterprise has changed immensely in recent years because of increasing collaboration, growing global competition, and emerging technologies like AI and CRISPR; these changes offer exciting opportunities for the advancement of science but also raise new ethical questions,” said Michele Masucci, vice chancellor for research and economic development for the University System of Maryland, and co-chair of the committee that developed the guide. “On Being a Scientist is meant to help students and early-career researchers navigate this evolving landscape. We hope the guide will also serve as a framework for responsible research practices for the entire scientific community.”

This guide’s release as online modules rather than as a printed book reflects how users typically access the guide and will make it easier to update going forward. The new edition follows previous printed versions published in 2009, 1995, and 1989.

While directed primarily toward undergraduate and graduate students, postdocs, and early-career researchers, the guide is also useful for faculty who teach research ethics and for established researchers who mentor people in research activities across range of settings — academic institutions, government agencies and laboratories, and industry.

“The dynamic, ever-shifting research environment makes the basic tenets of responsible science — including rigor, integrity, and transparency — even more critical to the effective functioning of the research enterprise and to maintaining public trust,” said National Academy of Sciences President Neil H. Shubin, who co-authored a preface to the new edition with Tsu-Jae Liu and Monica Bertagnolli, the current presidents of the National Academy of Engineering and National Academy of Medicine, along with the immediate past presidents of the NAS and NAM. “This guide is an essential resource to help set norms for ethical conduct and encourage practices that promote the use of science for societal benefit.”

The guide includes an introduction that offers an overview of responsible research and scientific values, together with the following four modules:

• Collaborating Responsibly provides guidance on collaborating productively across disciplines and institutions, which is increasingly important as the scale and complexity of science grows. This module explores how to enter collaborations intentionally, structure them, manage challenges, and learn from experience.
• Earning and Maintaining Trust focuses on the daily practices and professional commitments that establish trustworthiness; the institutional structures — including policies, cultures, and accountability measures — that support trustworthy science; and trustworthy communication with the public.
• Openness and Security offers guidance on navigating the “productive tension” between openness about methods, materials, and data — which is important to evaluating findings and advancing science — and research security, which protects research from misuse, theft, or unintended harm.
• Responsible Conduct and Stewardship of the Research Process covers the norms and practices of responsible science, such as the judicious use of resources, appropriate oversight and protections for research participants and subjects, prevention of mistakes and negligence, and adherence to norms of ethics and integrity.

“No single resource can fully cover the wide range of situations researchers encounter in their work,” said committee co-chair Alan Leshner, chief executive officer emeritus of the American Association for the Advancement of Science. “On Being a Scientist offers an introduction to these issues and ways to think about them. The goal is to help researchers recognize the relevant considerations when they arise, ask the right questions, and know where to look for further guidance.”

The project — undertaken by the Committee on On Being a Scientist: An Online and Updated Guide to the Responsible and Ethical Conduct of Research — was sponsored by the National Science Foundation, the U.S. Department of Energy, and the Alfred P. Sloan Foundation.

The National Academies of Sciences, Engineering, and Medicine are private, nonprofit institutions that provide independent, objective analysis and advice to the nation to solve complex problems and inform public policy decisions related to science, engineering, and medicine. They operate under an 1863 congressional charter to the National Academy of Sciences, signed by President Lincoln.

Contact:

Megan Lowry
Manager, Media Relations
Office of News and Public Information
202-334-2138; email news@nas.edu

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, Boltzmann, Planck, Noether, 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.

Redworks

This project is well underway. Redworks will be an initial development vehicle once we quickly sort out some minor legal and tax issues. Initially, the focus will be on "world-building", leading into production design. Scripts will come later.

Update 25/10/2026

The Martians will use the Workspaces for Screen. It will be a good dogfooding test of its capabilities and drive additional useful features.

Update 27/10/2026

Include Euler, Gauss, and Riemann from The Martians' perspective to show how these personalities and continuity shaped the development of maths and physics and the emergence of The Martians.

Euler–Riemann Zeta Function

"If Euler was the master of manipulating infinite series, algebra, and the properties of real numbers, Riemann was the architect who took those exact same equations and projected them into multi-dimensional, complex space." - Wikipedia

Leonard Euler (15 April 1707 – 18 September 1783) was the greatest mathematician who has ever lived and was revered throughout Europe at the time. Bernhard Riemann (17 September 1826 – 20 July 1866) was a student of Carl Gauss, who was deeply influenced by Euler.

Resources

• http://www.redworks.co.nz/2026/10/the-martians.html
• https://en.wikipedia.org/wiki/The_Martians_(scientists)
• https://www.blog.ajabbi.com/2026/10/stealth-mod-continues.html
• https://www.goodreads.com/book/show/693795.John_Von_Neumann
• https://www.blog.ajabbi.com/2026/09/hilbert-spaces-and-matrix-calculations.html
• https://en.wikipedia.org/wiki/Oppenheimer_(film)
• https://en.wikipedia.org/wiki/Revolutions_of_1848
• https://www.blog.ajabbi.com/2025/12/playing-with-krobarai.html
• https://www.blog.ajabbi.com/2025/11/workspaces-for-screen.html
• https://www.themarginalian.org/2016/09/20/janna-levin-a-madman-dreams-of-turing-machines/
• https://www.komal.hu/lap/archivum.e.shtml

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 > Subject > Mathematics
• Home > Handbook > 

Last Updated

25/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. After the revolutions of 1848, the slow decay of the Austro-Hungarian Empire led to WWI, then to the Russian Revolution, the Stalinist counter-revolution, anti-semitism 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.

Vienna in the 1930s. The sign, belonging to a gambling parlour, reads: “Don’t let luck pass you by.” A horseshoe and chimney sweep, superstitious symbols of good fortune, appear above it. (Photograph: Roman Vishniac)

• 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:

Inside Café Josephinum, the convening place of the Vienna Circle

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.

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

• https://abseil.io/resources/swe-book
• https://abseil.io/resources/swe-book/html/toc.html
• https://www.oreilly.com/library/view/software-engineering-at/9781492082781/
• https://en.wikipedia.org/wiki/Camille_Fournier
• https://refactoringenglish.com/excerpts/write-an-effective-design-doc/
• https://refactoringenglish.com/excerpts/write-an-effective-design-doc/little-moments-design-doc/

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

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

• https://lalitm.com/post/find-problems-staff-engineer/
• https://news.ycombinator.com/item?id=49411643
• https://lobste.rs/s/utnhmy/how_i_find_problems_solve_as_staff
• https://lalitm.com/post/dont-answer-the-first-question/
• https://perfetto.dev/docs/visualization/ui-automation#creating-macros
• https://perfetto.dev/docs/visualization/extension-servers
• https://github.com/google/perfetto/discussions/4960
• https://github.com/google/perfetto/blob/rfcs/0031-trace-processor-warm-sessions.md
• https://github.com/google/perfetto/pull/6839

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. 

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

• https://www.blog.ajabbi.com/search/label/sign-up
• https://www.revenuecat.com/blog/growth/subscription-app-trends-benchmarks-2026

References

• Reference

Repository

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

Last Updated

14/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).

• https://www.blog.ajabbi.com/2025/12/why-software-fails.html

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 unique frontier model, 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.

• https://www.blog.ajabbi.com/p/pipi.html

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.

• https://www.blog.ajabbi.com/2026/03/the-accessibility-issue.html

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. ...

Daylight essential for our sleep, health and mood

Mike's Notes

Important for people to be healthy and function well. For future reference: Ajabbi work schedules, environment, staff cafe location, etc.

Resources

• https://www.rnz.co.nz/national/programmes/ninetonoon/audio/2018879599/daylight-essential-for-our-sleep-health-and-mood
• https://podcast.radionz.co.nz/downloads/ntn/ntn-20230227-1005-daylight_essential_for_our_sleep_health_and_mood-128.mp3
• https://thedaylightaward.com/laureates/anna-wirz-justice/
• https://youtu.be/gFzzWIJ5uOo?si=KpkGsGPrDegAdfFA
• https://www.healthnavigator.org.nz/health-a-z/s/seasonal-affective-disorder/
• https://thesleepdoctor.com/sleep-quizzes/chronotype-quiz/
• https://sleepsurge.com/morningness-eveningness-questionnaire/
• https://time.com/5063665/what-is-polyphasic-sleep/
• https://epfl-pavilions.ch/en/exhibitions/lighten-up
• https://my.matterport.com/show/?m=Myk62Aa4Nms
• https://www.rnz.co.nz/life/wellbeing/david-r-samson

References

• Reference

Repository

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

Last Updated

19/09/2026

Daylight essential for our sleep, health and mood

By: Kathryn Ryan

RNZ Nine to Noon: 27/02/2023

Kathryn Ryan: Kathryn grew up in the South Island and is now based in Wellington.

She has a BA degree in History and Education, a post-graduate diploma in journalism, and has also completed university study in business and economics.

A journalist for twenty years, Kathryn began in print and joined RNZ in 1999. She spent six years reporting on Parliament in RNZ's Press Gallery office, the last three as RNZ's political editor. She became host of Nine to Noon in May 2006.

Kathryn has travelled widely throughout New Zealand and visited around 20 countries in Europe, Asia and the Pacific, as well as the United States and Antarctica.

Her interests include reading, movies, good food and wine, the great outdoors, tramping and sea swimming. The Association of International Broadcasters named her 2015 International Radio Personality of the Year.

...

One of the best things we can do for our sleep cycle – and therefore mental health – is head outside for 30 minutes of daily daylight, says world-leading neurobiology researcher Anna Wirz-Justice.

"'Go out for half an hour in the morning no matter what weather," she tells Kathryn Ryan.

Neurobiologist Anna Wirz-Justice is Professor Emerita at the Centre for Chronobiology, Psychiatric Clinic of the University of Basel in Switzerland. Neurobiologist Anna Wirz-Justice is Professor Emerita at the Centre for Chronobiology, Psychiatric Clinic of the University of Basel in Switzerland. Photo: Supplied / The Daylight Award

Wirz-Justice is an expert on circadian rhythms who grew up in New Zealand and now lives in Basel, Switzerland.

Last year she received the Daylight Award for her work on light therapy as a treatment for seasonal affective disorder (SAD)and other sleep-related pyschological disorders.

Back in the 1980s, when Wirz-Justice began researching light therapy as a treatment for SAD, it wasn't taken seriously in psychiatry, she says.

Thanks partly to her research, it has now been established as the "treatment of choice" for SAD, rather than antidepressants.

Wirz-Justice has also discovered light therapy can be beneficial – yet not as beneficial – for people with non-seasonal depression, bipolar disorder, and pregnancy-related depression.

It has also been shown to slow cognitive decline and improve mood and sleep in people with Alzheimer's disease and dementia.

For decades, people saw light therapy as a "really alternative medicine without any scientific justification," Wirz-Justice says.

Although many patients still think "alternative" is the right way to describe the healing power of light – because it's natural and not a drug – Wirz-Justice says that there's now too much scientific evidence for this label to be appropriate.

"We just have to keep working on finding a way that the psychiatric establishment can consider light therapy as part of the therapeutic armamentarium, particularly in depression."

Not only is healthy sleep crucial for recovering from any illness, Wirz-Justice says, a lack of healthy sleep can exacerbate the symptoms of psychiatric illnesses.

With a better understanding of the importance of getting enough daylight and understanding our own circadian rhythms, we can each time our sleep so it's of good quality, Wirz-Justice says.

Increased flexibility of working hours was one upside of the Covid-19 pandemic as it gave people the ability to create a lifestyle better suited to their individual chronotype, she says.

"As a night owl, I do not like getting up to go to [work] every morning at 8 o'clock whereas a [morning lark] would find that absolutely unproblematic."

Anna Wirz-Justice's sleep tips:

• Aim to be in more light during the day and more darkness at night.
• Don't go near electronic devices within an hour of bedtime.

"The blueish screens we play and work with in the evenings are going to delay our circadian clock and shift our sleep to later … Particularly kids are inordinately sensitive to these blue wavelengths, even at very low intensity."

• If your child has a night light make it orange, not blue.
• And if you're not always blessed with an "eight-hour lot", don't panic.

Five hundred years ago, it was normal for people to have a "first" and a "second" sleep during winter, Wirz-Justice says, and many non-human animals are polyphasic – get their sleep in bursts rather than a long stretch.  

'We have this image that good sleep should be consolidated. I say just don't worry about it. Natural sleep, particularly in winter, is bimodal. It has 'first sleep' then a hole in the middle. Just lie there or go to the fridge… don't worry about it."

...

Anna Wirz-Justice collaborated with fellow Switzerland-based New Zealander Sarah Kenderdine - director of the Lausanne scient and art laboratory EPFL Pavilion - on the current exhibition Lighten Up! On Biology and Time.

<HR>>>>

Anna Wirz-Justice, Laureate of The Daylight Award 2022 for Daylight Research

Anna Wirz-Justice, Neurobiologist and Professor emerita at the Centre for Chronobiology / Psychiatric Clinic of the University of Basel, received The Daylight Award for her research on 16 May 2022, at the award ceremony in Copenhagen, Denmark.

The jury citation:

Anna Wirz-Justice has undertaken pioneering research on how human circadian rhythms and sleep are regulated by light. Defining the key parameters of how light acts as a biological stimulus, including the importance of when we see light, how long we see it, and of what intensity and colour spectrum. 

Working in a psychiatric clinic, Anna appreciated the connections between abnormal light exposure, circadian rhythm disruption, and the impact this has on mental health. She introduced the use of light therapy to Europe and studied its use in Seasonal Affective Disorder (SAD), non-seasonal depression, Borderline Personality Disorder and dementia. This work allowed Anna, and other groups around the world, to establish both the scientific and therapeutic application of light as a treatment for different areas of mental illness. This holistic approach led Anna and colleagues to write a manual for health care professionals, thereby guiding evidence-based light treatment to improve mood and sleep disorders. 

Anna Wirz-Justice has embedded her science broadly across the public sector. She has, and continues to reach out to numerous other fields in both the natural and humanistic sciences, to convey the importance of the natural day-night cycle on our psyche and physiology, including through architecture and the world of art. She has been the driving force behind multiple public lectures, exhibitions, installations, and architecture projects. 

YouTube: 17/05/2022 05:22

Signals & Levers: AI Pokes the System

Mike's Notes

Useful systems thinking.

Resources

• https://curiousduck.io/
• https://signalsandlevers.com
• https://maven.com/p/4c46b4/ai-adoption-rewired-a-systems-thinking-approach
• https://sim.curiousduck.io/
• https://itrevolution.com/product/signals-and-levels-paper/

References

• Signals & Levers, Elisabeth Hendrickson and Joel Tosi, IT Revolution. 2026.

Repository

• Home > Ajabbi Research > Library > Subscriptions > Signals & Levers
• Home > Ajabbi Research > Library > Publishers > IT Revolution
• Home > Handbook > 

Last Updated

13/09/2026

Signals & Levers: AI Pokes the System

By: Elisabeth Hendrickson

Signals & Levers: 19/08/2026

Elisabeth Hendrickson: Elisabeth Hendrickson is a technology leader with hands on experience leading geographically distributed teams. She was VP R&D at Pivotal where she led Engineering and Product for the Big Data Suite, and a VP Engineering at a Series B startup. She is also the co-author of Signals & Levers: Systems Thinking Tools to Unblock Software Delivery (with Joel Tosi), and author of Explore It!, a book on exploratory software testing. These days she works with leaders and teams to unblock software delivery.

...

In Extreme Programming Explained (right at the start of Chapter 5, “Cost of Change”), Kent Beck asked a deceptively simple question: “What if the cost of change didn’t rise exponentially over time, but rose much more slowly, eventually reaching an asymptote?”

The question holds profound economic implications. If a change tomorrow costs essentially the same as a change today, there is no penalty for delaying a decision. You can start with the simplest thing that could possibly work, and only make further investments when signals from actual customers—not just opinions—show that it’s needed. Whenever additional complexity starts creeping in, you can invoke the principle of YAGNI: You Aren’t Going to Need It. You don’t have to commit to an approach; you can learn as you go.

That was back in 1999. Today, the promise of AI opens a new line of questions about software economics: What if the time and cost of writing code shrinks to almost nothing?

Yes, we’re in the middle of a hype cycle and actual outcomes have been mixed. You might be skeptical, and rightly so. Perhaps you’ve seen too many instances where AI took indefensible shortcuts, and obsequiously responded “You’re right to challenge this…” when called out on its mistakes.

But suspend disbelief for a moment. What if the promises were real? What then?

If 1K lines of code costs just pennies in tokens, experimentation becomes absurdly cheap. Can’t figure out how to crack that gnarly technical problem? Take 100 runs at it in parallel. Unsure what features real users will actually use? Build them all and collect telemetry. Historically struggled with a flood of demands on engineering’s incredibly limited capacity? Code isn’t a constraint anymore.

And then what? There’s the rub.

Just because experimentation becomes incredibly cheap doesn’t mean your customers will appreciate the thrash of a rapidly changing user experience. Just because you can collect near infinite telemetry data doesn’t mean you’ll be able to turn all that data into actionable insights. At a certain point, an overwhelming amount of data makes even legitimate signals feel like noise. For that matter, just because initial development costs pennies doesn’t mean that maintenance or operations are cheap. Keeping production systems up and running can be expensive.

Every solution—no matter how powerful or good—brings new problems. Software delivery remains a non-linear, socio-technical system. You poke the system and the system pokes back. More code doesn’t guarantee more value.

When we wrote Signals & Levers, we avoided talking about AI. It gets a short mention at the beginning of the book and again at the end of the book. But in between? No mention. Our editors and early readers asked us about that: Why would we ignore the thing that is radically transforming software development right now?

The answer is that we believe systems thinking is evergreen, and we didn’t want premature declarations about the nature of AI’s impact to limit the shelf life of our book. And we were right. When we started this book two years ago, AI was essentially a powerful auto-complete. Now you can unleash fleets of agents to build entire systems nearly unsupervised, and those systems actually work. (There are some big caveats about what has to be true in your system to see those kinds of results, but that’s a topic for another day.)

The thing that hasn’t changed, and won’t change, is that if you want to take advantage of the full power of AI, you have to understand your system. AI is poking the system. System thinking tools can enable you to see how to get the most out of it within your context, and anticipate the ways in which your system will poke back.

Upcoming Events

If you're interested in exploring how systems thinking can help you reason about the impact of AI in your context, we hope you'll join us for our latest Maven Lightning session.

• What: AI Adoption, Rewired: A Systems Thinking Approach​
• When: Thursday August 27, 10AM Pacific
• ​To join us, please register on Maven​

In this talk, we pull on the systems thinking tools from Signals & Levers, including causal models and variability analysis to explain differences in outcomes. In doing so we help you identify where your organization is best poised to get benefit from AI today and how to find the right interventions in your system to increase the impact AI can have.

We also hope to see you in person at a conference this fall:

• ​DevOps Midwest @ St. Louis MO, Sep 16​
• ​Prairie Dev Con @ Winnipeg MB, Sep 21 - 22​
• ​Tech Fuse DSM @ Des Moines IA, Oct 15 - 16​
• ​Agile Testing Days @ Potsdam & online, Nov 16 - 19​

Or check out our previous appearances on these podcasts:

• ​Build & Break Through: Joel talked to host Hunter Harris about about high-functioning product teams, integration, customer feedback, and the importance of focusing on strategy over reaction.
• ​Build & Break Through: In a separate episode, Elisabeth talked to Hunter Harris about systems thinking and feedback loops.
• ​TechLead Journal: Joel and Elisabeth talked to Henry Suryawirawan about Signals & Levers, the persistent illusions in software delivery, and implications of AI.
• ​Engineering Alpha in Private Equity: Elisabeth talked to Dave Mangot and Dr. Paul Karner about quality as a strategic advantage for PE-backed companies.
• ​Leadership & Success Podcast: Elisabeth and Joel talked to Bob Fabien "BZ" Zinga (Coach BZ) about building better systems.
• ​Goto; Joel and Elisabeth talked to Charles Humble about signals, levers, and why systems thinking is having a moment right now.
• ​Third Loop: Elisabeth and Joel talked to Kim Harrison, Heidi Waterhouse, Adam Zimman, and James Governor about Signals & Levers and seeing software delivery as a system. ​

And, book news! In addition to the print and e-book pre-order, the audio book is now available for pre-order. It's read by professionals. We got to hear the audition recordings and had a hand in selecting our favorites. There are two: one reads the fiction portions of the book, and the other reads the non-fiction portions. We have't heard the whole thing yet, but we heard a sample and can't wait to hear the rest. Having two readers was definitely the right call.

Finally, the launch date for Signals & Levers is almost here! September 22! We'll have news about our virtual launch event soon.