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.
GitHub’s engineering team has moved to Codespaces
511–520 of 704 posts
Re: GitHub’s engineering team has moved to Codespaces
#512Earlier 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-
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
#513Earlier 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…
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
#514Serious 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…
Re: GitHub’s engineering team has moved to Codespaces
#515Earlier 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?
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
#516Earlier 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)?
Re: GitHub’s engineering team has moved to Codespaces
#517so 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…
Google does anything: "Whatever happened to Don't be Evil!"
Re: GitHub’s engineering team has moved to Codespaces
#518Nowadays 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
#519Earlier 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.
> 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
#520From 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.
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.