bhuga

I moved away from a gmail address that was that old, dating back to the invitation-only days. It had become more spam than not, mostly other people who share my initials not knowing their own email addresses. But the possible devastation you mention was more worrying. It had become too much of a risk for my banking and identity generally to not own my email address.

I got a custom domain. I still host it on google, because I know how impossible it is for small companies to have a reasonable program to deal with insider threats. Because of that, I think only one of the giant companies can realistically provide secure email. And the google app suite is great. Now that I pay for google workspace, there's support and appeals available, and if they ban me anyway, I still control the domain and can regain access to everything.

I have not been able to delete the old address, even after 3 years. There are some things like Google Fi that can only use a non-workplace google account. Very, very rarely, I still get an email that matters on it. But I got to the point where I could stop checking it in about 2 months, and now I look at it about once a week quickly, more out of habit than anything else.

The switch was annoying, but not "hard". It was worth it.

There's so much happening in this space, but I still haven't seen what would be the killer feature for me: dual-mode operation in IDE and CLI.

In a project where I already have a lot of linting brought into the editor, I want to be able to reuse that linting in a headless mode: start something at the CLI, then hop into the IDE when it says it's done or needs help. I'd be able to see the conversation up to that point and the agent would be able to see my linting errors before I start using it in the IDE. For a large, existing codebase that will require a lot of guardrails for an agent to be successful, it's disheartening to imagine splitting customization efforts between separate CLI and IDE tools.

For me so far, cursor's still the state of the art. But it's hard to go all-in on it if I'll also have to go all-in on a CLI system in parallel. Do any of the tools that are coming out have the kind of dual-mode operation I'm interested in? There's so many it's hard to even evaluate them all.

> I don't think those would change often

I think this is where our contexts may differ, and so we end up with different tradeoffs and choices :) The services running on our dev servers are updated dozens of times per day, and they roughly correspond to the non-code parts of a VM.

> Isn't this a matter of not reusing old VMs after a `git pull/checkout`, though?

Yes, but forcing people to rebase is disruptive. Master moves several times per minute for us, so we don't want people needing to upgrade as the speed of git. Some things you have to rebase for: the code you're working on. Other things are the dev environment around your code, and you don't want that to be part of the checkout as much as possible. And as per my earlier comment, setting up a fresh VM can be quite expensive in terms of developer time if test data needs to be configured.

Yes, but this still "freezes" the VM when the user creates it, and I've got no tools to force the software running in it to be updated. It's important that boxes can be updated, not just reliably created.

As just one reason why, many developers need to set up complex test data. We have tools to help with that, but they take time to run and each team has their own needs, so some of them still have manual steps when creating a new dev server. These devs tend to re-use their servers until our company-wide max age. Others, to be fair, spin up a new machine for every branch, multiple times per day, and spinning up a new VM might not be burdensome for them.

> I’d anticipate you would be equally as able to ssh to VMs on dev laptops. That’s definitely a prerequisite for making this work in the same way as you’re currently doing.

Our laptops don't receive connections, but even if they could, folks go on leave and turn them off for 9 months at a time, or they don't get updated for whatever reason, or other nutty stuff.

It's surprisingly common with a few thousand of them out there that laptop management code that removes old versions of a tool is itself removed after months, but laptops still pop up with the old version as folks turn them back on after a very long time, and the old tool lingers. The services the tools interact with have long since stopped working with the old version, and the laptop behaves in unpredictable ways.

This doesn't just apply to hypothetical VMs, but various CLI tools that we deploy to laptops, and we still have trouble there. The VMs are just one example, but a guiding principle for us been that the less that's on the laptop, the more control we have, and thus the better we can support users with issues.

> So the devs don’t have the ability to ssh to your cloud instances and change config?

They do, but I can see those changes if I'm helping debug, and more importantly, we can set up the most important parts of the dev processes as services that we can update. We can't ssh into a VM on your laptop to do that.

For example, if you start a service on a stripe machine, you're sending an RPC to a dev-runner program that allocates as many ports as are necessary, updates a local envoy to make it routable, sets up a systemd unit to keep it running, and so forth. If I need to update that component, I just deploy it like anything else. If someone configures their host until that dev runner breaks, it fails a healthcheck and that's obvious to me in a support role.

> Just to be clear, I think it’s interesting to have a healthy discussion about this to see where the tradeoffs are. Feels like the sort of thing where people try to emulate you and buy themselves a bunch of complexity where other options are reasonable.

100% Agree! I think we've got something pretty cool, but this stuff is coming from a well-resourced team; keeping the infra for it all running is larger than many startups. There's tradeoffs involved: cost, user support, flexibility on the dev side (i.e. it's harder to add something to our servers than to test out a new kind of database on your local VM) come immediately to mind, but there are others.

There are startups doing lighter-weight, legacy-free versions of what we're doing that are worth exploring for organizations of any size. But remote dev isn't the right call for every company!

> I’m referring to running everything inside a single VM that you would have total access to. It could have telemetry, you’d know versions etc. I wonder if there’s some confusion around what I’m suggesting given your points above.

I don't think there's confusion. I only have total access when the VM is provisioned, but I need to update the dev machine constantly.

Part of what makes a VM work well is that you can make changes and they're sticky. Folks will edit stuff in /etc, add dotfiles, add little cron jobs, build weird little SSH tunnels, whatever. You say "I can know versions", but with a VM, I can't! Devs will run update stuff locally.

As the person who "deploys" the VM, I'm left in a weird spot after you've made those changes. If I want to update everyone's VM, I blow away your changes (and potentially even the branches you're working on!). I can't update anything on it without destroying it.

In constrast, the dev servers update constantly. There's a dozen moving parts on them and most of them deploy several times a day without downtime. There's a maximum host lifetime and well-documented hooks for how to customize a server when it's created, so it's clear how devs need to work with them for their customizations and what the expectations are.

I guess its possible you could have a policy about when the dev VM is reset and get developers used to it? But I think that would be taking away a lot of the good parts of a VM when looking at the tradeoffs.

> What’s the size of the cloud instances you have to run on?

We have a range of options devs can choose, but I don't think any of them are smaller than a high-end laptop.

Some important differences from 2019:

* Code is off of laptops and lives entirely on the dev server in many (but not all) cases. This has opened up a lot of use cases where devs can have multiple branches in flight at once.

* Big investments into bazel.

* Heavier investment into editor experiences. We find most developers are not as idiosyncratic in their editor choices as is commonly believed, and most want a pre-configured setup where jump-to-def and such all "just work".

I work on this at Stripe. There's a lot of reasons:

* Local dev has laptop-based state that is hard to keep in sync for everyone. Broken laptops are _really hard_ to debug as opposed to cloud servers I can deploy dev management software to. I can safely say the oldest version of software that's in my cloud; the laptops skew across literally years of versions of dev tools despite a talented corpeng team managing them.

* Our cloud servers have a lot more horsepower than a laptop, which is important if a dev's current task involves multiple services.

* With a server, I can get detailed telemetry out of how devs work and what they actually wait on that help me understand what to work on next; I have to have pretty invasive spyware on laptops to do the same.

* Servers in our QA environment can interact with QA services in a way that is hard for a laptop to do. Some of these are "real services", others are incredibly important to dev itself, such as bazel caches.

There's other things; this is an abbreviated list.

If a linux VM works for you, keep working! But we have not been able to scale a thousands-of-devs experience on laptops.

> How do you make them interested in your company in the first place? Triplebyte did not really have a cost-effective solution for that

They absolutely did! It was getting companies to agree to skipping straight to the onsite after a 15-minute recruiter call.

This lets you skip the back-and-forth of screen scheduling and result chats. In turn, that saves weeks of time during a job search, and allows you to have all of your onsites within a short time period, and then and offers come in within a much narrower window of time. You can make apples-to-apples comparisons about which role you might take that way, so it's a much lower cost for a much greater payoff to spend a few hours interviewing with a company you weren't thinking of to see if it's a fit.

In my mind, this was the absolute killer feature. I am still at a Triplebyte job 7 years later that impressed me via their onsite, and I would not have thought to apply if they had not been on TripleByte's skip-to-the-onsite list.

> survival of the species is not aligned with the survival of an individual

The unit of survival is not the individual or the species, but the gene. Genes maximize their survival by combining via sexual reproduction with other genes over time. Any one combination of genes will be out-competed over time.

The reason for honest aging signals is that a gene survives longer by getting out of the way of its offspring's combinations with other, newer genes. Sexual reproduction is the only way to get access to new phenotype features.

It's not service for the collective. Hanging around in one individual is the genetic version of vendor lock-in.

From working at a CLEC (competing local exchange carrier) in the 90's:

This mindset goes back to the AT&T antitrust breakup. It was decided that phone companies would not be allowed to reject each other's traffic, because the larger ILEC's (incumbent local exchange carrier) would find reasons and excuses to cut off the CLEC's. This would be more or less a death penalty to those businesses, and the ILEC's had exactly zero reason to want the CLEC's to exist at all, so there was a lot of fear and rulemaking to prevent this.

Fast forward 30 years and the details have changed, but the mindset is largely the same. The fear is still quite real, and that's why phone spam isn't treated like email spam. If i.e. verizon cuts off incoming calls from a random CLEC in a midwestern state, that business is just over, done, that's that. It would be impossible to restore the business after your customers left, which they would do more or less instantly; there's no court remedy that would fix it. Great pains are taken to ensure that such an action is legitimate.

The rules are oriented around the idea that the ILEC's were evil antitrust actors, and the plucky CLEC's are the competition we need to protect from big ILEC's heavy hand. In a world of spam, that mindset is backward. And that mindset is changing, but because of the reasonable concerns, it's taking longer than we expect.

I hadn't heard this statistic:

> since a small minority of human drivers cause the vast majority of incidents

It's tough to find anything relevant on DDG or google, they come up with information about racial disparities in traffic stops...can you link anything to read about this?

Or perhaps "ourorobos" :)