3 ms·

> I've talked with multiple ex coworker developers at Google about the 3 to 6 months it takes to actually figure out how to deploy something. In typical develo

> I've talked with multiple ex coworker developers at Google about the 3 to 6 months it takes to actually figure out how to deploy something. In typical developer environments, you end up with a bell curve of "easy things are relatively easy (host a static site, 30 seconds), but some things end up being totally impossible (build a global CDN with 99.999... availability)." Developing at Google is not at all like this: building anything at Google is medium-hard. It takes longer to do simple things, but at the same time, basically nothing is technically impossible. In many cases, doing the hard things is much easier than elsewhere because, yeah, sure, you have to set up 20 different config files, but those config files abstract damn near anything a production system needs to operate. Example: I wanted to add improved image serving functionality (e.g. imgix style URL params), and I was able to integrate the existing infra Photos uses in about 15 lines of code and a few hours. I don't think there are too many places in the world where it's possible to provide that functionality in an afternoon. Why it never shipped is a separate story involving non-technical reasons (cross-PA politics). > Also the constant overhead of approvals and oddball systems (gerrit!) thereafter. IIRC only the Android codebase used Gerrit, the rest of Firebase and GCP were on Google3. The approvals and other stuff... true. > Eventually good DX seems unimportant and even associated with failure. I think this comes down to a definition of "good DX". I think the HN definition (indeed by default one) is "how quickly can I solve for an issue using the happy path." Indeed, Firebase solves that for a good number of problems (why people use it, why there are people who love it). At some point though, you can't solve for _all_ use cases along the happy path (see e.g. SAML, ABAC, any $ENTERPRISE_FEATURE). If you want to expand the business, you need to solve for some things that don't have a perfect happy path, and that's where things start getting messy. IMO, the goal of Firebase's acquisition was to keep Firebase solving the 80-90% of things that had a happy path, and GCP was the remaining 10-20% where folks had to break out of to do arbitrary things. It seems like a lot of folks in other threads here are complaining about that because the abstractions leak out--I think it's a fair criticism, but I also am not entirely sure how to solve for that.

joshe 4y ago
Great nuance, thanks for commenting. DX to me is reduced cognitive load. We are all operating at the limits of abilities, better DX expands the scope of what we can accomplish in our weeks and months. Often things sold as DX are absolute garbage dead end schlock, like a Flash to iphone app builder or something. So I get some of the indifference (google's not yours). But I don't think we should think of it that way. Just on your last paragraph, I think it started that way. That Firebase would be the competent general problem solver that you might need to break out of. Firebase and App Engine have tended to weaken over time, so that you needed to move to GCP more often. Ideally Firebase would get more powerful, cover more cases, and have higher quota limits. Instead it feels like they are being degraded or abandoned rather than embraced. I've never gotten the impression that at google DX was lionized. Examples of doing this well culturally are pre-Salesforce Heroku, Github, vscode, and Stripe. A github/heroku style culture doing GCP would crush all competitors. Instead if anything GCP is a little worse than AWS.
- asciimike 4y ago
  > Just on your last paragraph, I think it started that way. That Firebase would be the competent general problem solver that you might need to break out of. Firebase and App Engine have tended to weaken over time, so that you needed to move to GCP more often. Ideally Firebase would get more powerful, cover more cases, and have higher quota limits. Instead it feels like they are being degraded or abandoned rather than embraced. I think I mentioned this on another thread, but the "weakening" you mention is "strengthening integrations with other parts of the platform." I think the general thought here is that an App Engine or a Firebase is a local maximum, and in exchange for trading off deeper integration, there is a platform wide global maximum that is achievable. Pre-acquisition Heroku, GitHub, Firebase, etc. all were able to achieve local maxima, which led to acquisition, and subsequent attempts to globally optimize. Dev tools is a brutal business: if you're lucky, 80% of your customers cost you money, 15% break even, and 5% are where 80-90% of your revenue comes from. A better DX typically only gets you more customers in the bottom 95% bracket, because it's easier to onboard people who can get from 0 to 1 than from 10 to 100 (or 100 to 1000). Deeper integrations into the features on the far side of the curve tend to get prioritized and look a lot like what folks here are discussing as negatives. > I've never gotten the impression that at google DX was lionized. Examples of doing this well culturally are pre-Salesforce Heroku, Github, vscode, and Stripe. It's not, for the reasons others have pointed out about people being smart enough to figure out the solution regardless of the DX, etc.
- zoomzoom 4y ago
  I'm curious if you think it must be the case DX should be so cloud-specific. Could someone (maybe like my company, withcoherence.com) create a broadly "good" engineering workflow for different kinds of cloud apps, and map that onto different cloud substrates? I don't have your degree of experience with the internal culture at GCP but I would have to agree it seems to be less customer-obsessed than the examples you provide. It's clear that AWS is more popular, especially with startups, but my experience is that GCP is better, if viewed through a user experience and product quality lens, outside of a few notable exceptions such as SSL certs (ACM) and some NoSQL DB products.

joshe 4y ago

Great nuance, thanks for commenting. DX to me is reduced cognitive load. We are all operating at the limits of abilities, better DX expands the scope of what we can accomplish in our weeks and months. Often things sold as DX are absolute garbage dead end schlock, like a Flash to iphone app builder or something. So I get some of the indifference (google's not yours). But I don't think we should think of it that way. Just on your last paragraph, I think it started that way. That Firebase would be the competent general problem solver that you might need to break out of. Firebase and App Engine have tended to weaken over time, so that you needed to move to GCP more often. Ideally Firebase would get more powerful, cover more cases, and have higher quota limits. Instead it feels like they are being degraded or abandoned rather than embraced. I've never gotten the impression that at google DX was lionized. Examples of doing this well culturally are pre-Salesforce Heroku, Github, vscode, and Stripe. A github/heroku style culture doing GCP would crush all competitors. Instead if anything GCP is a little worse than AWS.

asciimike 4y ago
> Just on your last paragraph, I think it started that way. That Firebase would be the competent general problem solver that you might need to break out of. Firebase and App Engine have tended to weaken over time, so that you needed to move to GCP more often. Ideally Firebase would get more powerful, cover more cases, and have higher quota limits. Instead it feels like they are being degraded or abandoned rather than embraced. I think I mentioned this on another thread, but the "weakening" you mention is "strengthening integrations with other parts of the platform." I think the general thought here is that an App Engine or a Firebase is a local maximum, and in exchange for trading off deeper integration, there is a platform wide global maximum that is achievable. Pre-acquisition Heroku, GitHub, Firebase, etc. all were able to achieve local maxima, which led to acquisition, and subsequent attempts to globally optimize. Dev tools is a brutal business: if you're lucky, 80% of your customers cost you money, 15% break even, and 5% are where 80-90% of your revenue comes from. A better DX typically only gets you more customers in the bottom 95% bracket, because it's easier to onboard people who can get from 0 to 1 than from 10 to 100 (or 100 to 1000). Deeper integrations into the features on the far side of the curve tend to get prioritized and look a lot like what folks here are discussing as negatives. > I've never gotten the impression that at google DX was lionized. Examples of doing this well culturally are pre-Salesforce Heroku, Github, vscode, and Stripe. It's not, for the reasons others have pointed out about people being smart enough to figure out the solution regardless of the DX, etc.
zoomzoom 4y ago
I'm curious if you think it must be the case DX should be so cloud-specific. Could someone (maybe like my company, withcoherence.com) create a broadly "good" engineering workflow for different kinds of cloud apps, and map that onto different cloud substrates? I don't have your degree of experience with the internal culture at GCP but I would have to agree it seems to be less customer-obsessed than the examples you provide. It's clear that AWS is more popular, especially with startups, but my experience is that GCP is better, if viewed through a user experience and product quality lens, outside of a few notable exceptions such as SSL certs (ACM) and some NoSQL DB products.