benbalter

> I'm curious how much you think lessons and practices from say, 2012 or 2014 are holding up so far in a rapidly changing post-AI environment.

I didn't touch too much on AI in the book itself (since it's changing so quickly), but it was interesting to reflect that the fundamentals of 2012/2014 (Markdown, URLs, APIs, etc.) carry double the weight when we start thinking about machine readability.

> It seems to be listed on multiple outlets, I'm curious how much that part of the process was able to be handled by agents vs being done manually.

Entirely manual, and I suspect that's by design. I've never published a book before, so I did ask (non-agentic) AI questions about the process (should I use service X or service Y, should I do a pre-sale, etc.).

> And I do recommend applying a much stronger human-in-the-loop editing process to any material meant to market this book (and of course the book itself).

100% human in the loop. I wanted the public-facing presence to be reader-centric, not marketing/author centric, which I felt was the norm LLMs are trained on.

> Prior experience and taste are all we have left in this new era.

+100. I held the book to a much higher standard than I do musing I randomly post on the internet that hardly anyone reads. (I didn't expect this to get so much attention). I'm going to take another pass at both the post and the site tonight. Thanks for the feedback.

Fair, and I think this is the most interesting feedback here, especially because I made the same observation in the blog post itself:

> One of these caught me. `validateHypotheticalHooks` flagged the opening of a paragraph I was certain I’d written myself — and I had. But reading it back cold, it did sound ghost-authored; I’d absorbed the cadence from reading too much generated text and produced a fluent imitation of nothing.

As for the book, "trust me, I'm human" isn't going to cut it here (we literally prove humanity on the internet by training robots to act more like humans). As I posted earlier in the thread (https://news.ycombinator.com/item?id=49337307), most of the book's chapters began as blog posts that I've published for over a decade, well before AI slop came into the picture. The book is those, refined. 2026 me can't Terminator myself into creating a retroactive paper trail.

And thanks for the feedback. Human Ben is going to take another pass at the post and rewrite those you flagged so that they don't take away from the message.

Fair. The project originally started as "turn my blog into a book", with a 1:1 mapping of blog post to chapter. I got feedback early on that that wasn't landing, but if you compare the outline on the book site to my blog archive, the original posts are still there.

Chapters built on an earlier post making the same argument:

- Why everything should have a URL → "Why URLs?" (2015) + "Expose process through URLs" (2014)

- Speak like a human → "Write corporate blog posts as a human" (2015)

- Optimize for developer happiness → "On stickers and optimizing for happiness" (2015)

- The zen of open and async work → "The zen of GitHub" (2015)

- Lead like an engineer → "Manage like an engineer" (2023)

- Rethinking management for remote teams → "Deprecate management" (2012) + "Cathedral–bazaar management" (2023)

- Retool your documents → "Word vs. Markdown" (2014) + "We've been trained to make paper" (2012)

- The etiquette of issues and pull requests → "Types of pull requests" (2015) + "Pull requests are a form of documentation" (2023)

- Showing colleagues they're valued → "Three easy ways to show employees you appreciate them" (2017)

- Choosing the right collaboration tools → "Tools of the trade" (2020)

- What I wish I knew before going remote → "Eight things I wish I knew my first week at GitHub" (2016)

- Career conversations → "The brag doc" (2026)

- Intro to software development for non-technical roles → "GitHub for non-technical roles" (2023)

And chapters that are near-verbatim descendants of a named post:

- Leaders show their work → "Leaders show their work" (2022)

- Work loudly → "Work loudly" (2026)

- Meetings are a point of escalation → "Meetings are a point of escalation" (2023)

- The Andon principle for knowledge work → "Transparency & collaboration is the Andon of knowledge production" (2023)

- Engaging with dissent → "Dissenting voices" (2024)

- How to 1:1 → "One-on-one playbook" (2026)

- Agentic workflows → "Agentic workflows" (2026)

- Why you should work asynchronously → "Why async" (2022)

Nice! My rule (pre-AI) had always been never force a human to do what a robot can. If you can automate yourself out of your least favorite part of your job, that's a win for both you and your employer. You can move on to more meaningful work, or in some environments, just leave early. Reminds me of that old xkcd about the tradeoff in time between doing something manually vs. automating it.

Glad to inspire. That was the point of the post. For the record, I never made any guarantees that the book (or the website) was any good. Software or prose, you can have the most pristine build pipeline in the world, but "garbage in, garbage out" as they say.

Ha! Indeed. Love the time-lapse video.

ETA: Need to add "maniac on the front page of Hacker News" to my resume.

I've gotten that feedback before. Once a lawyer, always a lawyer.

Full disclosure, a few months back when I had some tokens expiring, I had Copilot spike out a draft to see if there was anything "there" worth writing. If you check the revision history (linked from the bottom of the post), I did a full (human) blank page rewrite three days ago and then only used Claude for line edits like adding links or fixing failing lints.

Well, there goes my weekend. Thanks for sharing. Will take a look.

Why do you think I procrastinated writing by building out all that unnecessary tooling? /s

Partially licensing, but also tokens + efficiency. As noted above, the book is written for humans (anecdotes, examples, etc.). Robots just need the facts and can extrapolate. If I were building a hosted service, a custom LLM with embeddings would probably beat both approaches.

This was my first "real" MCP server (previously I made an MCP server to control a Furby for GitHub Universe) and I learned a lot. A few things I learned (not an expert):

* Tool vs. Resource: Does it compute or does it serve * Prompts -> Tools * Deterministic vs. Probabilistic is a choice per tool

> the book's website and blog appear interesting, the author can write

I'll take the compliment!

README was 100% intended for robots, not humans (book is 100% for humans, FWIW). I'd be impressed if you can spend $10 on tokens interacting with the MCP. That's one reason why I went with an MCP over a skill. A lot of the logic is offline/token free.

Fixed rubric. It works on regex matching across interpersonal tension, active incident, sensitivity, and ambiguity. If a pattern matches, it weights sync over async.

More than a decade ago, I adopted the self-imposed rule, if I answer a question more than once, the third time I need to be able to answer with a URL. Today, I published one very large URL - a book distilling what I learned from helping people work remotely at GitHub, and I wanted to rethink my rule for the age of AI.

What if, instead of a URL, I could create an interactive experience that could tailor the guidance to your particular situation?

What I ended up building was an Open and Async Advisor MCP server. To install (in claude or any other AI):

> claude mcp add open-async -- npx -y @open-and-async/mcp

Transparently, yes, it's from a book I wrote which launched today, but the MCP server is open source and free to use. No purchase required. It knows the key principles of the book, and has specialized tools like `draft_decision_doc`, `convert_meeting_to_async`, `score_status_update`, `triage_sync_vs_async`.

This is an experiment for me, and I'm genuinely curious if it's helpful for others.

Please don't send meeting invites without an agenda.

Imagine getting a calendar invite that just says "Quick sync" with zero context… and having no idea what it's about.

TL;DR: When working as a distributed team, be mindful of cultural differences, time zones, encouraging breaks between meetings, and connecting as humans.

TL;DR: When authoring a pull request, use the body as an opportunity to document the proposed change, especially the “why”, and cross link any related issues or other PRs to create a trail of breadcrumbs for future contributors.

Default to transferring context asynchronously. Hold colleagues accountable for being async first. If you receive a meeting invite without context, an agenda, or a read-ahead doc, consider politely declining.

PiHole is what first introduced me to the DNS sinkholing concept and was more mature when I was first researching options. AdGuard home has come a long way since then and I’m planning on giving it a closer look when I’m looking for my next project.

> A lack of knowledge hoarding, healthier knowledge transfer and decision making, and reduced waste.

Author here, +100 to this. The role of the PM should be to drive consensus around the problem, not to decree the problem (or requirements) by fiat.

For me, that process is highly collaborative, and engineers (and design, support, etc.) should 100% be involved from the begining. The amount of definition will vary from team to team and even engineer to engineer, but if a PM is hoarding knowledge, their understanding of their own role is the opposite of what it should be.

To paraphrase a famous product manager at Initech, "I talk to the customers so the engineers don't have to". That's not to say the engineers shouldn't talk to customers, but generally speaking, PMs should be the ones conducting qualitative and quantitative research day-to-day so that everyone can focus on what they do best.

At least on my teams, for example, user interviews are recorded and shared with the entire team, along with their raw notes, as are the high-level takeaways, allowing everyone to opt-in to as much or as little context as they'd like. We treat quantitative research the same way, sharing the underlying query, raw data, etc.

While the PM may ultimately drive the discussion, problem definition should be collaborative so that the entire team is aligned around a shared product vision. The PM's role should be to gather, organize, and share knowledge to build consensus, not to hoard it.