Live data from Hacker News

GitHub’s engineering team has moved to Codespaces

github.blog

291–300 of 704 posts

Re: GitHub’s engineering team has moved to Codespaces

#291
post #259

I've developed on a remote server for about 8 years now. It started when I was a contractor and my machine was simply too slow to run the project I was assigned. I did not have the money for a new laptop, but I could afford the ~55/month for a dedicated server with 32GB and 4cores. I have worked that way ever since. I've been fortunate enough to work at companies that run their own VM infrastructure which allow me to…

If you work from a park how do you manage your latency/connectivity to a remote server? It must get annoying fast when a pigeon flies over causing your hotspot to cut out.

I believe he's using the word "work" very loosely here.

Re: GitHub’s engineering team has moved to Codespaces

#292
post #259

Earlier quoted context omitted.

If you work from a park how do you manage your latency/connectivity to a remote server? It must get annoying fast when a pigeon flies over causing your hotspot to cut out.

Files are stored in memory locally so there’s no network trip when editing, only on save, and it’s kilobytes per edit in the worst case

[deleted]

Re: GitHub’s engineering team has moved to Codespaces

#293

Earlier quoted context omitted.

I recently set up a home Linux server and I've been doing my personal projects on it via VSCode's remote development (from my MacBook and my Windows desktop). The server isn't actually as powerful as those machines, but the convenience of having a single env regardless of client has still been fantastic (not to mention getting all the Linux niceties despite working from Windows). Doing it in the cloud probably carrie…

This mirrors my experience. It is nice not really having to care what type of machine I am given by my employer since my environment is going to feel exactly the same regardless. And who knows maybe since you have your server running headless it is effectively on par with your laptops. These days most of my cpu cycles on my laptop are spent on Slack or Chrome!

Hadn't thought about that angle, but yeah, I guess it really is splitting the load

Re: GitHub’s engineering team has moved to Codespaces

#294

Earlier quoted context omitted.

I can see how a web based IDE speeds up on boarding and reduces the friction in support and collaboration. But I wonder if it reduces the skills engineers develop over time?

What skills would developers really lose? Speeding up boarding seems like a win, not many skills are developed imo trying to set up you personal dev environment. It's mostly just frustrating when a company's tools don't work well on your machine.

Being able to manage the frustration could be one such skill. And also being ready to fix things instead of assuming that employer must set up a perfectly working environment for you.

I bet smaller/poorer companies may want programmers who are ready to fix tooling when it (inevitably) breaks

Re: GitHub’s engineering team has moved to Codespaces

#295

> "So we moved to 32 core, 64 GB RAM VMs. By changing a single line of configuration, we upgraded every engineer’s machine." On GitHub, that instance type is $2.88/hour or $2,073 monthly per developer for a single instance. (Granted, that's running 24/7 but still - wow, that's expensive for a single instance)

The kinds of bills that some large company development environments end up running are surprisingly high, but those companies also think the opportunity cost of losing productivity on application team developers to also very high. That's how you find companies that decide to hire very expensive teams to, say, add types to a dynamic language, rewrite a standard library, invest in massive parallelism to run thousands of CPU hour integration tests in 15 minutes, or many other projects like that which no normal company would ever consider. If it gets some project team to cut delivery times by 3 weeks, it's all considered worthwhile.

Where we run into trouble is when we try to copy the shape of those big companies, and the kind of initiatives they fund, into startups, or mid-range companies. In quite a few ways, those top companies are better at development, but the base costs are only worthwhile if you have a money fountain of real revenue that grows far faster than your dev expenses. Trying to copy them with very different conditions is going to lead to tough problems, possibly company killing, and it's the kind of imitation we see all over the industry.

So yes, someone like Github is going to have eye popping expenses, because the alternatives to avoid those expenses just don't make sense to them. If you are not working in a multi billion dollar company, their practices can be interesting, but it makes as much sense to emulate them as it'd make for you to hire an entire Formula 1 pit crew to keep your commuter car in good shape.

Re: GitHub’s engineering team has moved to Codespaces

#296
post #198

Earlier quoted context omitted.

What are they embracing, how are they extending it, and how do they plan to extinguish it? My understanding of EEE is that it involves taking some competitive product/standard, making a cool MS version of it, and then killing off the standard version - e.g. implementing a barely sufficient POSIX layer on Windows, getting customers who have "POSIX" as a purchasing requirement to switch, and then getting them onto the…

It's a slightly different flavor of the same thing. VS Code is an amazing tool that's getting huge adoption because of how awesome it is, and how open source and community centric it is, etc. They've gotten a lot of mindshare and dev love, that's the embrace bit. The next step is the set of closed source addons. Have you noticed that a lot of the new VS Code features are now in addons that are under a different licen…

Gotta love how the goal post just keeps moving forward.

Re: GitHub’s engineering team has moved to Codespaces

#297

Earlier quoted context omitted.

> Getting rid of local development means they have to worry a lot less about what's going on on their engineers' workstations. Wait, what?!? No, it doesn't. Their engineers' workstation software can read or edit their code just as easily as their engineers can. Going into the cloud just adds another liability, it doesn't take any one away.

I don't think so. Software running on your computer has wholesale access to your filesystem. If those files are accessible only via the web (or if you bother setting up ssh + pubkey, via ssh) that significantly reduces the surface area of possible attacks. Don't hate on "not being impossible" for "being less likely."

"Less likely" applies to random events. Sabotaging or stealing code has nothing of random in it. You can claim it becomes "harder", what it does, a very small bit that doesn't warrant anything like the claims on the GP.

All it changes is that the attacker will have to launch the browser or rewrite some part of it (what he can do, because the browser auto-updates with your access level), instead of simply taking the files.

Oh, and by the way, not all software running on your machine has complete access to the filesystem. Reading your code and changing your browser requires basically the same level of access.

Re: GitHub’s engineering team has moved to Codespaces

#298
post #259

I've developed on a remote server for about 8 years now. It started when I was a contractor and my machine was simply too slow to run the project I was assigned. I did not have the money for a new laptop, but I could afford the ~55/month for a dedicated server with 32GB and 4cores. I have worked that way ever since. I've been fortunate enough to work at companies that run their own VM infrastructure which allow me to…

If you work from a park how do you manage your latency/connectivity to a remote server? It must get annoying fast when a pigeon flies over causing your hotspot to cut out.

Hah! Thankfully that doesn't happen too often. Worst thing that happens is I forget to turn off my Hotspot when I get home and drop into a Zoom meeting on it and use all my 4g data on accident.

Re: GitHub’s engineering team has moved to Codespaces

#299

Earlier quoted context omitted.

I'm saying that, while a top-tier, software-as-a-service company might have a development environment that is hard to bootstrap -- because of all the ancillary things that run alongside the "monolith" -- your generalization that "Rails" makes a mess of a development machine is FUD. The Ruby/Rails part of this equation is not the issue. As always, YMMV and TACMA.

I didn't say Rails makes a mess of a dev machine. What I'm saying is that every project makes different sort of assumptions about how it's brought up in a dev environment, and these assumptions vary wildly between projects and stacks, and usually the older and more prominent a project is, odds are it will have the most unexpected impact on anyone's machine. This is going to be true for any combination of libraries, f…

> I didn't say Rails makes a mess of a dev machine.

I literally quoted you saying that in my first post. But hey, what do I know?

Re: GitHub’s engineering team has moved to Codespaces

#300
post #134

The amount of time I've seen lost to engineers spinning up (or fixing) development environments is staggering. This kind of thing is going to save SO much money. (I've run a team responsible for the tooling for a company's development environments in the past so this hits really close to home.)

Alternatively, they could have spent this money on fixing the dev stack. Maybe this was more politically viable.
Post reply on HN