Live data from Hacker News

GitHub’s engineering team has moved to Codespaces

github.blog

511–520 of 704 posts

Re: GitHub’s engineering team has moved to Codespaces

#511
post #343

Earlier quoted context omitted.

How is that different from now? If you work for a big company you already have your laptop controlled by MDM software which can do whatever it wants.

Whatever cloud dev environment you use will shove productivity metrics up your manager's ass. E.g. Employee A ran the tests 4 times an hour whereas employee B ran the tests twice an hour.

Just run the tests more times per hour. It's literally what you're getting paid to do!

Re: GitHub’s engineering team has moved to Codespaces

#512
post #469

Earlier quoted context omitted.

This is a problem that can be solved without Codespaces too. For example, if GitHub were to embrace Nix, every project could have a shell.nix file for all of their dependencies, and the new engineer bootstrap script that installs Nix could then just add an internal Nix binary cache (or use Cachix). Any time the shell.nix changes a GitHub Action could push the closure to the binary cache. With this setup, you can use…

-insert comment about that hacker news comment about how dropbox could be replicated with linux here-

I'm not sure that comment applies here. The suggest Dropbox replacement was more complicated than Dropbox, and had more steps. On the other hand, Nix is about the same amount of complexity, and same number of steps for the developer.

Yes, the parent comment looks a bit complicated, but that's just the one time setup, not something that needs to be done by every developer. And Codespaces will require some of that setup too; it's not like it'll magically know what packages and dependancies your project requires to build.

Re: GitHub’s engineering team has moved to Codespaces

#513

Earlier quoted context omitted.

There are plenty of engineers but few good ones. Hiring is brutal, especially now, so good developers can afford to be picky and find another semi identical job in almost no time.

I'm also not sure I agree that there are few good engineers. I think that's some rhetoric that we all say because we all think we're some of the few good ones. In my experience (FAANG, startups in the valley and startups out of state/country), strong engineering talent is not particularly difficult to find, but finding a good fit is the tricky part. And I would wager that eagerness-to-rage-quit is a pretty good indic…

Not a rage quit, but I absolutely would look elsewhere. Folks are allowed to have dealbreakers for where they work.

A lot of people "rage-quit" basecamp over their no politics thing. I probably wouldn't have, but to each their own.

FWIW, I have also spent lots of time at FAANG, startups, etc and haven't had any trouble finding a great fit. I have also never looked more than a week or two for a job when I wanted to leave, so that does factor into my willingness to leave if I'm not enjoying my job.

Re: GitHub’s engineering team has moved to Codespaces

#514
post #358

Serious question: if I were to use this, would Microsoft collect analytics on me (code written, keystrokes, mouse movements, sleep/work schedule, productivity metrics, etc) and monetize that data by using it to build some AI product like Copilot, or build a productivity dashboard so managers can fire people for not being productive enough (like Xsolla did), use it to serve me ads, or do some stupid/irresponsible/unet…

[deleted]

Re: GitHub’s engineering team has moved to Codespaces

#515
post #125

Earlier quoted context omitted.

I think people like not having their physical machine tied to their dev environment. IMO "the way" to do this is with ssh and tmux, not a web app. As long as people have choices I guess it doesn't matter.

> I think people like not having their physical machine tied to their dev environment. I'm curious to know if this statement is true. Most experienced developers these days have a regular desk and a chair where they like to code and focus. How prevalent is the move-and-code scenario?

I like it a lot.

My usually setup is chrome dev tools and some node servers fired up, so quite easy to replicate.

But I still prefer to just move my laptop around.

Re: GitHub’s engineering team has moved to Codespaces

#516
post #190

Earlier quoted context omitted.

That pricing is a ~70% markup over standard Azure rates. Companies typically buy laptops with an assumed 3 year lifespan; so, let's assume a high-end $3000 laptop, that would be ~$83/month. Of course, you need a computer to access Github Codespaces, so this isn't saving all of that money. Maybe companies can cut some costs by buying cheaper laptops? Or if you want a more apples-to-apples; a Lenovo ThinkStation P620 r…

Even with Codespace your company will still have to buy you a laptop, to run corporate VPN, security/virus software, background screen recording, and zoom/video calls. All of this will still need powerful reliable business grade laptop. The cost difference between laptop meant for remote development vs regular dev laptop is less than $1k. ($300 for CPU upgrade, $200 for RAM, $200 for SSD upgrade)?

:sigh: this is to close to home. Nothing like malfunctioning virus software + background screen recording to eat all your local machine ram and cpu cycles.

Re: GitHub’s engineering team has moved to Codespaces

#517
post #415

so at what point are we? Embrace? Extend? or Extinguish? https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...

Extend. [0] Microsoft already has accepted Linux into the Windows Developer Ecosystem (Embrace) and has integrated it in WSL. They added NVIDIA GPU drivers that only works on WSL. (Extend) GitHub Copilot also only works on VSCode and not on other editors. Soon they will probably move Copilot to only work on Codespaces. All of this is in the 'Extend' side. Guess what 'Extinguish' looks like? They will make it all free…

Microsoft does anything: "It's EEE"

Google does anything: "Whatever happened to Don't be Evil!"

Re: GitHub’s engineering team has moved to Codespaces

#518
There's more to choosing an editor than convenience. I learned a great deal about embracing free/libre software, learning new tools, and becoming comfortable at the command line by having my CS professor push us towards emacs/vim in school.

Nowadays with LSP there's even less of a reason to lock yourself into a editor as a service or paid editor. If you really love VSCode or Codespaces then more power to you, but I highly recommend giving something with a steeper learning curve a try for at least a few weeks to see what its all about.

Re: GitHub’s engineering team has moved to Codespaces

#519

Earlier quoted context omitted.

There are different risks, but there is not necessarily more risk. Does Codespaces have lower or higher than the availability risks of your current environment?

My current environment is my laptop, which I would also need to access codespaces. So by extension, codespaces is more risky than my current environment.

> My current environment is my laptop, which I would also need to access codespaces.

> So by extension, codespaces is more risky than my current environment.

That only looks at the hardware. There are many more pieces to the puzzle.

Re: GitHub’s engineering team has moved to Codespaces

#520

From the article: > The GitHub.com repository is almost 13 GB on disk; simply cloning the repository takes 20 minutes. Their problem seems to be mainly this. Which I'm surprised that they don't fix, but invent a workaround for. Deleting/rewriting a git repo's history is not impossible and often necessary for these kinds of cases.

I previously worked at a company on the team that managed the monorepo and the build system for the code within it. Our checkouts were 4.5GBS full. We had discussed performing yearly rollups, likely around Christmas for the current version. This would essentially be take a full checkout and `rm -rf .git && git init && git add --all` starting out with a new genesis commit. We'd keep the old "branches" in a separate archive only repository on our github and force push this new main copy to the working repository. And then provide guides and support for engineers to utilize the new rolled up repo and port any of their existing WIP.

The concerns were long lived branches that had WIP and I think also just misunderstandings about what was going to happen. We never did it.

Post reply on HN