chrisweekly

Yeah; how many times in 24 hours can one vigilante commit acts of thinly-narratively-justified but actually-illegal torture without audiences clueing in?

I love this idea. I also just checked out your blog (jerf.org) which also has some gems.

Hmm, I'd define that as "deprecated", not "obsolete". Many extant H2 deployments are stable and performant, and if they're eg fronted by an H3 CDN, the migration ROI might be questionable. /$.02

By what definition is HTTP/2 considered obsolete? Are you suggesting it's been supplanted by H3?

(FWIW I agree w/ your objection to the "httpx2" name.)

IMHO equating commits and PRs puts undue pressure on the scope and quality of a given commit, adding potential for unnecessary stress and eliminating the benefits of an additional buffer / layer for aggregation of changes. A PR representing a sizable feature or refactor might naturally contain a dozen commits, each dedicated to a logical area or a requisite subset of the whole. Assuming on principle a goal of keeping main in a known-good state, such intermediate and incomplete changes (fine in an unstable feature branch) would wreak havoc.

It's equivalent to asking, "Why would you have more than one story in an epic (or task in a story)?".

rewolves? EDIT: ah, "resolves" typo. was v curious about python's mysterious "wolfing" aspects

Fastmail is awesome. Happy customer for many years. Zero problems.

How does this compare to "smolvm" microvms from https://smolmachines.com?

Sure. No real disagreement here. (See also my replies to peer comments here.)

What models do you use in your work?

I hear you. "Choose boring tech" is a reasonable default stance. IMHO, designing resilient systems in anticipation of change, and finding ways to incorporate the best of what's new, is the nature of the game and what helps keep it fun after all these years (closer to 30 vs your 40, but I'm no spring chicken).

What kind of work have I done? All kinds of webdev and SWE-adjacent roles since the late 90s. Startups, scale-ups, SMBs, huge enterprises. FT and contract / consulting roles (w/ titles containing words like "Principal", "Architect", "Director" and "VP").

In a world where everyone followed rigid advice to stick to 3yo+ tech, Vite wouldn't exist, let alone have people to argue for it. Nor would the web, for that matter.

I'm _not_ saying "chase the new-and-shiny for its own sake", and I don't recommend introducing immature or untested dependencies in production. But it's essential to learn how to gauge the quality of a mature solution -- and IME the only way to do that is to have something to compare it to (ideally, something newer and better). Develop an instinct for separating the signal from the (considerable) noise by trying things. Newer isn't always better, but the arc does trend towards improvement. Dev tooling is rife with examples, and a great place to start.

As for "You have had a lot managers push newer frameworks/technologies on you?" On the contrary -- I've had managers wedded to outdated cruft that threatened to drag the whole enterprise down. Resistance to change is sometimes fear masquerading as wisdom.

Finally, note this whole thread is in the context of an update to the MCP spec. In the world of AI, 3 years might as well be 3 centuries.

> "Sometimes all students need is to see what caring looks like to ignite it in themselves."

Excellent point, well expressed.

(Also, IMHO the sarcasm in your final sentence detracts from your comment.)

"honest", "real", "genuine" -- wat.

> "only use things that have been around for at least three years"

Yikes. I can understand the desire to mitigate churn, but following this advice would be career suicide. Trying new things is essential.

I wonder how necessary/useful this is, in light of the amazing smolvm microvms from https://smolmachines.com.

(Not snark, not affiliated, just happy and impressed with smolvm and genuinely curious.)

see also "smolvm" - the awesome microvms from https://smolmachines.com

> newfound prohibitions on “write in this writer’s style”

that explains a lot. but do you have a decent citation?

Yes. MDN and caniuse.com are great. See also https://webstatus.dev and https://web.dev/baseline

Great advice and PoV. One nit: I recommend against the filename "DESIGN.md" for architectural invariants, in light of the emerging use of that filename for UI / design system / CSS tokens (colors, fonts, typography, etc).

See https://designmd.ai/ for examples.

"causing" -> "costing", right?

I think we're on roughly the same page. Long emails are problematic. Realtime meetings or (possibly but not necessarily near-realtime) chats in a dedicated channel can and do solve email's problems.

> "I don’t email is a collaboration tool"

That's almost the entirety of my point. Sure, email works well for simple, unidirectional / broadcast comms. But for async collaboration involving multiple recipients and any kind of back and forth, it's inherently problematic.

Thanks for considering possible reasons for disagreement. I'd like to understand it, too. FWIW, I'm about to turn 52. Been working in tech since the late 1990s. Remote more than not. Email is great for certain specific things. But for multiuser async collaboration in the workplace, surely you've encountered problems like I have, no? Email conversations -- especially if they're long and/or include a lengthy recipient list -- are inherently prone to critical failure, completely decohering as _both_ the recipient list(s) _and_ the topic(s) under discussion can fragment from the very first of N replies, making it impossible to resolve anything conclusively or to know what's been communicated to whom.

Sending a wall of text in an email is, IME, ~never^1 the right thing to do. If more than a fraction of colleagues fall into that bad habit, soon all anyone will be doing is email. Let alone if you try to respond to one of the too many points in an overlong message, or loop someone else into the conversation(s) which are now hopelessly fragmented. It's akin to a self-inflicted DoS attack.

1. Exceptions do exist (eg if the message is intended solely for and addressed to a single recipient, and includes a disclaimer / request / reminder about general email hygiene), but they're vanishingly rare.

sadly none of those are mutually exclusive

How do you search emails you weren't cc'd on?

(Replying to parent and GP)

I wasn't suggesting an IM system should be the source of truth for long-form documentation. But searching Slack works better than searching email you weren't cc'd on. Virtually anything is better than email for many essential aspects of collaboration.

Want to add someone to the mailing list and loop them in? How many prior emails will you forward to them?

Someone replies to one of several points in an email, someone else wants to address a different point, and there are a mix of habits and patterns for whether / how much / where to quote or include the previous messages in a response....

vs adding someone to a channel where they can review the conversation history, and some combination of threads and links to additional channels or external resources can adequately support whatever direction(s) the conversation takes.

In any case, it's the wrong tool for the job in so many ways, so much of the time. Hence my recommendation to keep emails to 5 sentences, and to prefer communication tools that properly support multiuser collaboration.

> "To my shame I've never read Dickens"

I suggest dropping the shame; you're not missing much. IMHO Dickens is hugely overrated. Paid by the word and it shows.

> "Write a long email that took time to reason and write, precise and complete text."

Respectful hard disagree. Emails should be limited to five sentences. "I didn't have time to make a shorter reply" as an apology / disclaimer for rare exceptions. In virtually every case, anything longer belongs somewhere better than email (Slack, wiki / knowledgebase, docs site) or merits a realtime conversation. My PoV is shaped by over 20 years in the industry working at startups, SMBs and huge enterprises.