Thread

We want you to build the next Git platform on Cloudflare

217 points · 203 comments · geoffbp

btown · 1791059919 · focus · HN ↗
Sometimes I think back to Google Wave, that beautiful glimmer of real-time collaborative canvases, announced in 2009 when Angular and Backbone hadn't even been invented, and think it launched almost two decades too early.
<a href="https://en.wikipedia.org/wiki/Google_Wave" rel="nofollow">https://en.wikipedia.org/wiki/Google_Wave
<a href="https://youtu.be/v_UyVmITiYQ?t=3850" rel="nofollow">https://youtu.be/v_UyVmITiYQ?t=3850
<a href="https://www.usenix.org/legacy/event/lisa09/tech/slides/berlin.pdf" rel="nofollow">https://www.usenix.org/legacy/event/lisa09/tech/slides/berli...
We're now in a world where we expect real-time interfaces to be developed and immediately deployed for our feedback by agents, in business-critical settings where classic SDLC timelines are far too slow, but code quality is becoming more difficult to manage at scale.
Git, at its core, is a fundamental notion that behavior is an auditable tree of immutable changes, where any participant can rearrange or rewind or remix this sequence on a local machine to show, and interact with, a provisional combination of those changes.
Google Wave, with its operational transformation (OT) and federation systems, was similar in many regards. We have CRDTs now, and far better techniques for auto-merging workstreams - including agentic systems that can resolve conflicts intelligently!
Wave fundamentally had a concept that people would come together and evolve a simple chat interface, into a customized real-time application for their use cases, and that that iteration could happen in real-time, with data and behavior both evolving in collaboration with bots. Wherever Git and the broader notion of SDLC goes, I hope it brings the best of this thinking.
1. lucideer · 1791063508 · focus · HN ↗
  The Wave release was the event that really kicked off my starting to rethink my own framing of what Google's engineering culture actually produces. I was so excited for its release, possibly moreso than any major innovation before then, & what was delivered was pure crap implementation wise. The idea was brilliant, & open, so theoretically someone could have done it well, but Google poisoned the well by releasing such a turd.
  Throughout it's existence Google has been revered as a company for its engineering output, but if you interrogate that even a little bit, you end up with a very small minority of gems among a massive ocean of over engineered crap. Even the huge objective open successes like k8s are to this day sold with the massive caveat of "it's heavy & over engineered, but": nobody's calling k8s elegant. Pretty much all of their good products are acquisitions, many of which they've subsequently degraded.
  One can certainly make this argument about almost any large corporation, but I do think there's very few with such a stark divide between how the quality of their engineering work is revered & the reality.
  1. pjmlp · 1791109310 · focus · HN ↗
    Having gone through AOSP source code multiple times in the past, I really ask myself where those top engineers that make it through Google's famous hiring practices land.
    The way they code Java, the C style C++ in some parts, the Android Studio stable releases that are always as buggy as preview releases (to the point of becoming a meme among Android devs), and so on.
    palata · 1791137698 · focus · HN ↗
    > I really ask myself where those top engineers that make it through Google's famous hiring practices land.
    Can I question the quality of said hiring practices?
    I have been rejected for a project that was starting from scratch on something exactly like I had been building for 6 years at a competitor, based on such famous hiring practices (not at Google though). I was literally more experienced than the whole team on what they were building.
    Because you hire people who are really good at leetcode doesn't necessarily mean that you always get the best candidates for the job?
    ndriscoll · 1791196334 · focus · HN ↗
    My sense is that it likely made sense before Campbell's law took effect. IIRC they developed an early reputation in the early 2000s for only hiring very bright people who could solve those kinds of problems on the fly. Then 1. the company needed more employees and 2. people started grinding away practicing those problems so they could pass tests that were intended to filter them, and you got what you have now.

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.