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.

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.

When you request an archive of your data, we send the download link to your primary email address (the required token is not available via the web UI). Once you click that link, you'll be asked to re-enter your password. So for this particular feature, an attacker would need both your GitHub password (and your 2FA seed or an active session if 2FA is enabled) and access to your email.

Did I miss something? Is there not a way to use 1Password 7 without it automatically uploading your 1Password 6 vault to their cloud as part of the setup flow (as it did for me)? Unless I did something wrong, it looks like a my.1password.com account is _required_ in 1Password 7.

See the section on "Sexually obscene content" in the GitHub Community Guidelines (https://help.github.com/articles/github-community-guidelines...). We purposely chose the word "obscene" and not "explicit" to allow for explicit but educational, scientific, or artistic content like this.

I am the Product Manager for GitHub Pages. As has been mentioned multiple times here, the usage limits were not in response to a specific external event. The limits have been an internal policy (in one form or another) for as long as I've been involved (nearly 4 years now), and we chose to publicize them in a series of updates beginning early this summer.

This is a classic case of "this is why we can't have nice things". If you're using GitHub Pages for your personal site or to document/talk about the work you're doing on GitHub, in general, you should be fine, even if you get HN-level traffic every once in a while.

The problem comes when a small handful of users use GitHub Pages for things like automated version checks or configuration distribution, as a makeshift ad CDN for for-profit sites, pushing an automated build every minute, or to distribute large assets (for which things like Releases are a better fit).

When a user (ab)uses GitHub Pages in a way that threatens our ability to build or serve other users' sites, technically or practically, we need to step in, and those posted limits are intended to help set expectations as to what you should and shouldn't use GitHub Pages for. But again, the vast majority of the nearly 1M users that use GitHub Pages will never hear from us (and in most cases when they did, we proactively reached out and provided ample warning/offered to help).

We may make things more flexible down the line, but for now, it was motivated by two primary reasons:

1. The overwhelming majority of users use one of those three design patterns. For example, I can tell you that more than 98% of GitHub Pages sites use either `master` or `gh-pages` as their primary branch (with only about one tenth of one percent of sites using the `stable` branch).

2. Our experience tells us that every option we add to GitHub Pages increases the learning curve for newer developers. With only those three options, if you're just learning HTML, you don't need to understand Git's branching model before you can create your first website.

We chose these options to start because we thought they struck a good balance between supporting collaborative documentation workflows for open source projects and encouraging "hello world" experimentation among new developers, but as with most features at GitHub, this is just the start.

> Is there a discussion somewhere that outlines some of the reasoning behind this pick?

Yes. The decisions was actually made on the open source GitHub Pages Gem repo, based on both user feedback and actual usage stats: https://github.com/github/pages-gem/issues/179.

They work just like any other Markdown file, and you can include a link in the rendered site to edit. See http://ben.balter.com/2015/09/13/github-pages-edit-button/.

From the original post:

> The rank represents languages used in public & private repositories

The delta is due to private repository usage influencing the rank.

Rank is number of repositories with that language created in a given year, so e.g., the languages with the most repositories created would be ranked 1, the second most 2, etc.

Source: I ran the query.

What do you mean by commercial offering? A paid version of GitHub Pages? What would you want to see in a paid offering that couldn't be baked into the current version?

> Do you have a wishlist of features to add to GitHub pages? Maybe allowing minimal sandboxed server side computation with a max runtime of say 1ms, setting headers, redirects or other stuff? I am guessing every little addition would eat away at the alternatives.

Moving from WordPress, the fact that you couldn't constantly tweak a thousand little things was extremely liberating. That's the zen-like simplicity of GitHub Pages that to me, makes it an attractive option over heavyweight alternatives. Just push and your site is live. Fewer things to break and fewer things to worry about means more time to focus on what matters: your content.