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/unethical thing with it that will ultimately end up hurting me in the long run?
Because I feel like the answer to that is yes, and I can already see myself in the future writing something angry in the comments section of an article on HN that exposes some evil/stupid shit Microsoft did with this, or happened as a result of this.
I'm not against the concept of using a thin client for development, but it just doesn't seem smart to me do it in such a way where you have to place trust in a company that, throughout their entire existence, has consistently proven that you should not trust them, because they have no incentive to (and thus never will) act in your best interests. It's like if Facebook released their own web browser and "promised" to respect your privacy; you'd be an idiot to believe them.
If a business is paying for this product, then THEY (not you) are the customer. And in that context - yes, Microsoft may be asked or build a product for managers to manage their workforce, particularly if remote. This could involve presence tracking, engagement tracking (ie, do you open alerts / read your bug reports) etc.
One approach would be to monitor what management considers productive / successful employees and also on employees who have gone on PIP's - then train the AI on that data set. You'd then be able to drive various alerts to manager and HR dashboards (ie, if a manager was failing to address alerts / manager their team it would be surfaced up a level).
Dystopia may be coming indeed. Remember, usually the key issue is not if product is a paid product, but are YOU paying for it. If not - someone else is the revenue source, and Microsoft et al will serve them. Maybe the individual licenses will not have this "management" layer add-on as an option.
But I think a very real chance of something like this occurring! If not right now eventually. In Sci-fi this is an inevitability (monitored through a smart watch or something etc).
> One approach would be to monitor what management considers productive / successful employees and also on employees who have gone on PIP's - then train the AI on that data set.
I look forward to the papers on how to slack off on your job while the AI classifies you as "a straight shooter with upper management written all over him". Possible title: "An adversarial approach to the TwoBobs Productivity Classifier"
I really hope that if this happens, DPAs bring the hammer down on everyone involved (both MS and companies using it) in a useful timeframe (i.e. before it has become socially acceptable because "everyone is doing it" and there are no consequences).
It doesn't matter who is paying for the product. You could pay for the product and they could still add usage terms about monetizing and sharing your personal data.
I think that any workplace that would do this in the future, is already doing similarly toxic things. This isn't an excuse - there's a danger in commodifying and making things like this even easier - but there's already shit workplaces out there with plenty of red flags.
How about moving all our code off GitHub while we're at it?
In this worst case scenario (which hasn't happened yet), I'm sure GitHub would expect the good will of open source projects and contributors while simultaneously being the boot on their face in the workplace.
As slownew45 points out, Github does not make money from individuals who use it for free. Of course such use will become increasingly difficult over time for Microsoft pinheads to justify from a business perspective. Telemetry, full-on surveillance and ultimately subtle manipulation of individual software authors seems an obvious choice to try to justify why Github should continue to allow non-paying individuals to use their repository.
The Facebook web browser. Never say never. If we knew what we know today about privacy, we would have pointed out the idiocy of anyone choosing to use a web browser released by Google.
> The Facebook web browser. Never say never. If we knew what we know today about privacy, we would have pointed out the idiocy of anyone choosing to use a web browser released by Google.
Google were already making money off targeted ads at that point. There was even an outcry about GMail scanning people’s emails several years before Chrome was released. But you could probably argue that we didn’t fully appreciate just how bad things would get at that stage. Many of us were just happy to see Microsoft get some competition.
Lol, like Microsoft paid the billions to give it out now for free. Besides, do you want your index funds to do well? Because that's exactly where the proceeds go to.
If your employer decides that they need such an analytics dashboard, one that is spying on every keystroke, then they will have one. That one doesn't depend on you working on a laptop, or in a remote environment - the company owns and is administrating that laptop, and they can install everything they regard as necessary.
Therefore the real question is if Codespaces is helping to get your job done; I guess that depends on the complexity and structure of the code, the complexity of the build environment/how you work with the CI environment and how the project is being deployed. I guess that this complex of issues will increasingly dictate how things will get done - if these are too complex, then you are better off with a remote environment.
Upon re-examination: if github/microsoft is owning the analytics data gathered from monitoring the keystrokes, then they are a third party, and could possibly make that data available across time; so that a prospective employer can get a view on past performance of a candidate, or the new employer will have access to analytics data gathered on you while working at a previous company. Now that one has the potential to make the whole thing much more sinister. There might be a big difference between the situation where your current employer has a keylogger on you, as compared to the keylogger sitting in the cloud. Grandparent poster Bogwog has a solid argument here.
It all depends if the industry will act this way or not, I still hope that there is some level of desency left somewhere, because being too paranoid about all of it will not get me anyway either. Also the utility of all this analytics data is limited, for example they could possible get the 'number of lines of code' written by someone, but it is impossible to judge how essential all these lines of code were to the business. Also there would be a significant backlash, if they get too invasive on the privacy of developers. (that's the moment for the video where Steve Balmer is flipping out on stage and shouting 'developers' https://www.youtube.com/watch?v=I14b-C67EXY )
Don't underestimate trivial inconveniences[0]. There's a difference between being able to install employee surveillance in principle, and having it handed to you on a golden platter.
Some manager may toy with an idea of getting IT to install and manage monitoring software, but ultimately reject it as not worth the cost. But if the company starts to work over something like Codespaces - even if only for purely technical reasons - then suddenly they'll find themselves having a dashboard for free, and for sure they'll start using it.
On second thought, the move to remote environments may have an interesting side effect: if people are no longer familiar with setting up their local development environments, then it will be a bit harder to set up their own side projects to tinker and try out new stuff; in a reality where everyone is working on a remote/preset environment, we will have just another small, but very significant inhibition to deal with our own side projects.
now there is a bit of an irony - github helped open source, now this development will be very helpful to corporate software developers, but might turn out to be harmful to open source as such.
It's going to be paid by your employer which leads to GP's concern about,
> or build a productivity dashboard so managers can fire people for not being productive enough (like Xsolla did)
Which is more likely. If your employer sets something like this up - will they use it to calculate a productivity score and use that for lay offs? Seems rather probable to me.
Microsoft Outlook/Office 365 costs money, but they still analyze your activity and report so called "productivity score". Maybe not sell, but I have no doubt they will analyze the data if they can.
I would like for MS to collect information that would make the product better. If there is a feature that I am always using, i want them to know it so that they can either improve it or not get rid of it.
Context is hugely important, and equally important is not to get sucked in by the HN echo chamber - that is, consider the MS of _now_ as opposed to that of 15 years ago which HN likes to bash (and give a free pass to other companies doing nefarious things). The FB example is considering the FB of _now_ and not 15 years ago.
In terms of the biggest companies in the sector, MS has been doing much more for developers and developer productivity than others. At the same time it's not a monolith and so you should not expect boyscout behavior either.
Privacy is a concern, and the onus is on you the user to ensure that you remain in control of your data. When using a service (any service), the answer is to always be ready to bail at a moment's notice. That means using source control and not tying yourself to a specific ecosystem.
Not sure if that's supposed to be an argument for using/trusting MS.
The levels of user and privacy hostility they went to (and are continuously going to) with Windows 10/11 makes me see this as a strong argument against.
The MS that's killing their own single most popular product, Windows, with anti-user features, is the MS of now. Releasing VS code and WSL doesn't redeem their sins.
By the same reasoning, since we're talking about data collection, and that data doesn't just disappear in most cases, consider the MS, FB and Google of 15 years in the future. Given the changes already mentioned, what can we reliably say about them, other than that massive change is at least possible, and possibly even likely?
This is why I don't like Google collecting data on me now. Not because I don't trust them now, I for the most part still think them trustworthy, but 15 years is a long time and there's no way I can intelligently trust that they will act in a certain way 15 years from now, given the available information at my disposal.
And that's with a company that I think is heavily incentivized monetarily and has a strong employee culture of keeping data private and in-house. Until there are better laws protecting my data or a clear legal relationship with me and an entity with regards to my data, I think the only prudent course of action is to keep as much information about me as possible out of their and others hands.
That's because people here have grown up and see the world for what it is, how products like these play out, how incentives around them are structured. Most of the cool things like this are bait.
Seriously. It takes extreme naivety to take a SaaS business at face value today. Patterns of exploitation are well-established and easy to spot. Once you see this a couple of times, including in offerings you got so excited about - or worse, you get burned by them personally - it's hard to be anything but bitchy about tech.
The comments may be negative, but the bigger problem is that they're also not wrong.
Look how tech is employed against lower wage workers. It is a good idea to be extremely vigilant about anything "reporting". I think people working in tech have a responsibility to not behave like 14-year old fangirls.
The business incentive is quite easy. It is to evaluate code monkeys and to quantify development efficiency in the eyes of a salesmen, those that approve projects at Microsoft and possibly GitHub. They want to offer services to large corporate entities and they deem this valuable. Call it collaborative and something-cloud and you have your green-lit project.
The road is to quantify the work in small packages is a decent one though, dissect a problem until only trivial tasks remain.
Still, I think your intuition is pretty much on point. But with anything, just take the features you like. If your business can dictate this for you, search for other businesses. Contrary to popular belief, there are a lot of those, although pay might indeed be a bit lower.
So, maybe? But these products already exist. Your company doesn't need to pay Microsoft to get that data, they can install stuff on your work machine and get all that info right now.
Semi serious answer: couple of years ago we devs used to joke about putting ourselves out of business by teaching AIs how to code. I guess the joke's no longer funny; I also guess current situation shouldn't be a surprise.
What would be valuable is to know which ecosystem, languages and tech people are investing time and resources into. These are the ones you need to prioritize for your dev tools. For instance, Microsoft decided to invest in supporting Rust https://docs.microsoft.com/en-us/windows/dev-environment/rus... as well as making sure .NET works on all OS.
> or build a productivity dashboard so managers can fire people for not being productive enough (like Xsolla did)
When a competitor decides to start using these, it's awesome. You get a nice window of opportunity to poach high performers.
> My friends, I’m here to tell you I was a Codespaces skeptic before this started and now I am not. This is the way. ~@iolsen
I don't actually doubt that this (and the 4 other glowing employee quotes) are real, but even assuming they are, I can understand people remaining skeptical about the sample size of 5 being broadly representative of the 100s (1000s?) of engineers at the company.
Also slightly hilarious that "This is the way" is a Star Wars callback referring to a character blindly following dogma before eventually realising the error of their ways...
On the other hand, there's quite a few "hints" littered throughout the article that their current setup is a bit of a beast, so I can definitely imagine some engineers being relieved to be able to get such a behemoth off their physical laps/desks: I guess if the local development experience is sufficiently brittle & frustrating, any alternative may seem welcome.
I’ve very recently become a GitHub engineer, and I got pre-access to the beta too and I must say - my absolute favourite thing about CoseSpaces is being able to dev on a repo you don’t work on regularly and probably wouldn’t contribute if it meant having to set up environment etc. It’s really nice to just dip into a project with a working environment in seconds, make your PR and then move on.
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 whatever local tool you want and, as long as environment variables are respected, they’ll just work. The only requirement on your end is to either run nix-shell first, or to use direnv and ask it to load the nix env for you.
The downside is you still are compiling locally, so you still need sufficient CPU/memory resources, but that’s it.
Unfortunately most companies still aren’t paying any attention to Nix.
How does it work when you work on several packages at once,e.g. a lib and an app using it? Is it a monorepo, do you configure both dependencies to be locally editable copies, etc.? For example patching an upstream open source project that is a blocker for your app.
This was my first idea for introducing Codespaces to my team -- set up the infrastructure to be able to spin up a codespace on our less-used component repos where people don't have a local dev environment prepared.
I'm a big fan of capturing the toolchain(s) with the repo. I have had to hack this for embedded toolchains out of necessity for years (decades?) using VirtualBox on a Mac. I still have a Windows 95 VM sitting around containing a copy of Keil or something that is the only known way to rebuild the code for a certain weird-ass micro from some consulting gig in the late 90's. I wonder if it still boots? Hopefully, that customer forgot about me...
I've been playing around with a homegrown version of this. It's really not that hard: just set up a docker context to your home lab server and use VSCode remote containers.
I've been able to remove WSL from my PC: Docker desktop was gouging itself on resources. I can now also shut down my desktop and continue exactly where I was on my laptop, and visa-versa. I don't have to pull WIP commits back and forth between the two machines.
It's a major leap forward, and there is no need to use GitHub infra.
I also started doing this, but using containers locally (on a Mac). The ability to have a set dev environment without needing to install local programs or compilers is great. And really once you flip to this model, it doesn’t matter if you’re running your dev in a container or remote VM. So long as you can get a command line to your dev environment, it really doesn’t matter where it is.
VS Code remotes are magic. I use a light version of it for 100% of my development on windows with WSL, but I also use it to log into a mac server and edit files on that.
I have no idea what actually went into developing the feature, but I would have to suspect that Electron would have contributed to making the separation of an app client vs server easier than something totally "native".
> Also slightly hilarious that "This is the way" is a Star Wars callback referring to a character blindly following dogma before eventually realising the error of their ways...
My friends, I’m here to tell you I was a Codespaces skeptic before order 66 and now I am not. Good engineers follow orders.
Brittle local development in from what I've seen is either due to another symptom of tech debt - an aging monolith with too many different build systems, dependencies and what have you that you end up with way too many Docker containers or the need to have a very long doc for newcomers with "run this script here, then that script there, unless it's a Monday, then run this script over there". Or a team that's gone all-in on a distributed microservices architecture with lambdas all over the place and a dozen or more repos and it's literally impossible (yes there's LocalStack but...) to get a faithful end-to-end local environment up and running.
The nightmarish local development experience of either case are symptoms of deeper issues than local development itself being a problem.
Not about Codespaces, but about Web IDEs in general, they're amazing. I've not used Codespaces but I have used what is being talked about here [0]. It's one of the biggest productivity improvements I've seen from Google. I never really have to think about what packages or software is setup on my laptop and I can change laptops or computers while having the entire state of my IDE preserved. It's a pretty amazing experience.
The only people who I don't think would instantly like this sort of thing are people like game developers who basically don't do any unit testing of their code and run the binaries they generate. For those users you could find quite a few ways around that.
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.
If you read the article, that's an option with Github's code spaces setup.
> Visual Studio Code is great. It’s the primary tool GitHub.com engineers use to interface with codespaces. But asking our Vim and Emacs users to commit to a graphical editor is less great. If Codespaces was our future, we had to bring everyone along.
snip
> From there, GitHub engineers can run Vim, Emacs, or even ed if they so desire.
> 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?
So you're telling me that the next GitHub outage could take out my dev environment and give me an afternoon off? Time to convince management that we need to switch to Codespaces!
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?
In the context of my comment of having a free afternoon off - having my local environment messed up means that I'll need to spend my afternoon fixing it instead, whereas having Codespaces go down is essentially an announcement to the entire engineering team to go take the afternoon off as there's nothing we can do
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 work this way. And as someone who likes to work in different places, like the park, being able to download docker images while on a Hotspot and it not go through my data plan is amazing.
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 carries some risks for a business that need to be factored in, but I'm sold on the thin-client dev workflow. I'm wishing I could do it at my day job so my laptop stops screaming at me from all the Docker containers.
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!
Agreed, this setup is super nice for personal work! Adding a raspberry pi as a jump box with wake on lan saves some money on electricity too. I've been using that with a big desktop computer instead of a server and it pretty much works for remote development while out of the house.
I've been doing something similar for the past few years. I have a development machine running tmux + vim that I can connect to via ssh / mosh. Biggest issue I've run into was high latency while in Europe (since my box is in the US), but otherwise it works great, even on flaky connections. The ability to download / build large docker images with a beefy computer is a very nice feature as you mentioned.
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 think the point is that a small random drop in latency affects the local connection, but not the remote server. So, if your SSH connection is a little flakey for a minute, that’s fine. The remote server is itself stable. It is also likely connected to a much bigger pipe, so pulling in a remote container is much faster than if you were doing the same thing from your laptop in the park.
If you’re worried about your SSH connection being stable, mosh is another option.
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.
> I could afford the ~55/month for a dedicated server with 32GB and 4cores
Umm... you spent 55128 = ~$5000 over 8 years. You could have bought 3 top-specced laptops. A good $1500 laptop will last at least 2-3 years. You would also get some resale value out of your laptop when you upgrade.
It hasn't been the same remote server for 8 years :) I don't pay for a server like that anymore now that I'm employed full time and one is provided for me.
And I was barely coming out of homelessness at the time. 1500 doesn't just pop out of nowhere.
You did just remind me of the time when I was contracting for that company, they flew me out to California but I didn't have enough money on my card to cover the incidentals fee at the hotel they booked for me. Thankfully an employee came through for me. That was pretty embarrassing.
I'm not sure why you're phrasing that math as if it somehow shows it was a bad idea. It is in fact possible to be able to afford a small monthly cost, but not have enough in the bank to immediately drop ~$1500 on a laptop, especially if you're just starting your career.
According to you they paid roughly the same amount as it would have cost to buy laptops and upgrade them relatively frequently, but amortized over much smaller monthly installments.
And their system would have been elastically upgradeable.
On top of that holding on to money and spending it later is generally better than spending it now, because $X is usually worth > X future $ because of inflation/lost ability to invest.
I've had this vision for over a decade and it is awesome to see we are finally making measurable progress towards it.
What I'd really like to see is a WebRTC type interface that overlays this to provide some kind of collaborative environment on top of it. I'm thinking of a built in voice chat as well as multi-author editing within the same codespace. Imagine it like pair programming. I'm in FileA.ts and I can see a little avatar icon of another dev in FileB.ts (maybe surfaced through the Explorer and/or the file tab bar). The voice chat could even be location aware so if we are in the same file/package then we are able to chat. I'd go so far as to allow multiple editors to affect the same file within the codespace so I could see the other dev edit the file in realtime (like coderpad or other interview tools).
I imagine a workflow where a feature/ticket is mapped to a codespace. One or more devs are assigned the codespace and they work together until the feature is completed. Incremental changes are stored up until a "build" action is submitted, resulting in the current contents of the codespace being built and deployed to an internally/publicly accessible endpoint. This might also result in a "snapshot" which could represent a commit to a sandboxed repo. The codespace goes away once the feature is completed resulting in a single check in to a master branch which would go through regular code review type processes (probably a squashed version of their local snapshot's changes).
> _I'm thinking of a built in voice chat as well as multi-author editing within the same Codespace._
You should try Live Share! VS Code Live Share enables you to collaboratively edit and debug with others in real time, regardless what programming languages you're using or app types you're building. It also supports voice chat:
This isn't exactly what I'm proposing since it seems to be based around sharing my code. I may be misunderstanding the documentation and examples however. Live Share appears to be me inviting people to connect to my personal session.
I see a codespace as a shared destination. It lives independently of any individual. I can hop in and out whenever I want and it continues to live.
To expand on this, it reminds me of how way back in the day we used to use MSN Messenger (and then Skype) to facilitate work chat. The model there was a contact list, a list of individuals I could reach out to and connect. There were group chats as well, but the primary mental model was closer to a phone call. Then Slack came and changed the model so that channels were the default, shared spaces were preferred over personal chats or ad-hoc groups. I don't want the default to be "I have my session and may invite others to join". I want the default to be "there is a shared workspace I connect to that others might be currently active in".
You might even imagine an interface similar to Slack channels (or Teams if that is your world). I could have multiple codespaces as channels that I can switch between. Within each codespace there may be active several devs. I can jump in and out. You could even setup permissions like "read only" spaces or whatever.
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 runs ~$2800 for 32 threads and 64gb memory. DIY would also land somewhere around that $3K mark; a Threadripper 2950x (32 thread) is $1100; 64gb of memory is around $250.
This, of course, is the most expensive option they have; the more standard option would be 4/8; for which you would pay ~$85/mo (all the time, normal work hours), for the privilege of a machine that's far less powerful than any laptop any of our developers have. For god's sake, my M1 MacBook Air is an 8/16, with four of those cores far more powerful than any three year old Xeon Azure has running. And it was like $1400.
I understand maintaining dev machines isn't the easiest thing in the world. I have never once worked anywhere where it was such a problem that the company would justify tens of thousands of dollars in spend. Because it kind of is one-or-the-other; time invested in making Github Codespaces work for your company is time not invested in maintaining local dev environments. And Github's ideal end-state is companies totally rely on Codespaces, so the local dev environments languish.
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)?
I don’t think they’re trying to save on hardware costs here. This is to prevent any kind of friction and wasted time when switching between branches/environment.
If your dev costs you $100/h, you only have to save them +/- 5 hours of faffing around with branches/dependencies every month to make it worth it (assuming a 8 hour workday).
>I understand maintaining dev machines isn't the easiest thing in the world. I have never once worked anywhere where it was such a problem that the company would justify tens of thousands of dollars in spend.
Look, this is yet another product targeting naive VC funded startups. Milking the cows until they bleed.
It's not worth it right now. The economies of scale could add up to make it break even, if not be cheaper.
Big could, of course. But considering it takes new devs at my company ~3 business days to get up and running (and we're a React shop), it could be worthwhile.
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.
This was the thing that jumped out at me! I'm not sure how the VSCode application interacts with these to potentially put them to sleep, but dang that is $$$ for a dev machine at the scale github is operating at.
I guess lucky for them to be owned by Microsoft now and so that's just a cost of doing business. I have a hard time believing they could have even considered an approach like this if they were still paying for hardware out of pocket.
If spinning up/down is fast+smooth (e.g., no reconfiguring stuff each time), you could drop that down to ~40h/week taking you to under $500/month. Still pricey, but combined with not having to pay the ~70% markup another commenter mentioned, it could be under $2,000/year.
Add on top of that, spinning down should be automatic. I've worked on bespoke platforms like this where it wasn't. Devs would often forget and/or be more willing to run long running tasks after work hours. The net result was pretty much having to assume an instance would be online 24x7 unless there were at least gentle pokes to disable instances.
While that does sound quite expensive, companies typically have a limited budget for employee laptops, but appear to have almost unlimited budget for cloud hosted testing environments, which usually have many instances (and services like RDS / Redis etc)
And that's on top of the price for every engineer's machine that is used to access the instance...
Sure, you might not need to buy machines that are as beefy (although I bet you'll still need a decent machine to run all your chrome/electron windows) but enterprise maintenance on these machines is still a significant cost.
I definitely don't think one can look at this from the 'saving money' angle.
I feel like all of the problems in the blogpost are solvable without moving everyone to this crazy web development environment. To quote one of the proponents:
> I do solemnly swear that never again will my CPU have to compile ruby from source.
...yeah, why was that even happening? Why not distribute pre-built artifacts? I feel like the whole docker ecosystem only exists because people forgot how to distribute software and/or python/ruby and friends make deployment so hard.
Back in the day (ahem), I’d have solved the problem by building new .deb or .rpm packages and letting the OS manage the updates for us. This is a lot harder for languages like node/js, ruby, python, etc… Dealing with a system level packages vs local packages is hard, so almost all management happens out-of-band. Older versions of packages was/is still an issue for many distro-managed libraries. And different projects have different requirements.
In the end, I’m largely okay with this… I’d rather have my choice in local OS and be able to work on my client of choice. I see the rise of containers was more of a response to heavyweight VMs as a dev environment.
But it’s good to remember — these are not unique problems and we’ve solved them all before.
I feel I'm swimming against the current of contemporary dev practices, but I actually believe trying to run as much of your apps and development locally is important. Not exclusively, but at least from time to time I think shutting off your network connection and seeing what happens is important. It flushes out all sorts of assumptions, especially around dependencies, you may not have realized you had. If you at least occasionally code in a local, non-networked environment, I think you end up with more robust code.
My job now has no ability to run our code locally and its terrible. I work on APIs which at the end of the day is an HTTP server making and responding to requests. When I make a change its impossible to test locally which is terrible.
The same issue applies to serverless technologies (at least last when I used them). It was extremely difficult to run serverless services locally, debug issues etc.
Having the cloud is great, but nothing will beat being able to run things locally.
It just gives you so much more control. You're not locked into a specific editor or tool chain, you can integrate with whatever other local tools might be specific to you, etc
This is a great feature, something to complement existing development approaches, but I'm always going to prefer my own setup where I have everything configured exactly how I like it.
> It just gives you so much more control. You're not locked into a specific editor or tool chain, you can integrate with whatever other local tools might be specific to you, etc
My experience aligns very strongly with this. A local stack lets you add debug/print statements anywhere. There is no "magic", you can see the thing run on your machine. The freedom is unmatched.
I can strongly second this. I currently work on a serverless project and running/debugging code locally is one of the biggest pain points. Over time I've gotten better at mocking out a bunch of stuff to try and get the code I care about running, but it's a really rough process.
There are of course risks that the local setup process will differ from the prod environment in a serious way. Even with good automated test coverage I feel less confident about the code I commit here than most other places I've worked.
Readit News
Because I feel like the answer to that is yes, and I can already see myself in the future writing something angry in the comments section of an article on HN that exposes some evil/stupid shit Microsoft did with this, or happened as a result of this.
I'm not against the concept of using a thin client for development, but it just doesn't seem smart to me do it in such a way where you have to place trust in a company that, throughout their entire existence, has consistently proven that you should not trust them, because they have no incentive to (and thus never will) act in your best interests. It's like if Facebook released their own web browser and "promised" to respect your privacy; you'd be an idiot to believe them.
One approach would be to monitor what management considers productive / successful employees and also on employees who have gone on PIP's - then train the AI on that data set. You'd then be able to drive various alerts to manager and HR dashboards (ie, if a manager was failing to address alerts / manager their team it would be surfaced up a level).
Dystopia may be coming indeed. Remember, usually the key issue is not if product is a paid product, but are YOU paying for it. If not - someone else is the revenue source, and Microsoft et al will serve them. Maybe the individual licenses will not have this "management" layer add-on as an option.
But I think a very real chance of something like this occurring! If not right now eventually. In Sci-fi this is an inevitability (monitored through a smart watch or something etc).
I look forward to the papers on how to slack off on your job while the AI classifies you as "a straight shooter with upper management written all over him". Possible title: "An adversarial approach to the TwoBobs Productivity Classifier"
(/s if this was not clear)
even if you are paying for it, it's quite possible that they also have other revenue sources that conflict with your interests.
0: https://news.ycombinator.com/item?id=25198713
Dead Comment
Replace Facebook with another major ad company, and you are basically describing the most popular browser right now.
0. https://blog.stackblitz.com/posts/introducing-webcontainers/
In this worst case scenario (which hasn't happened yet), I'm sure GitHub would expect the good will of open source projects and contributors while simultaneously being the boot on their face in the workplace.
The Facebook web browser. Never say never. If we knew what we know today about privacy, we would have pointed out the idiocy of anyone choosing to use a web browser released by Google.
Google were already making money off targeted ads at that point. There was even an outcry about GMail scanning people’s emails several years before Chrome was released. But you could probably argue that we didn’t fully appreciate just how bad things would get at that stage. Many of us were just happy to see Microsoft get some competition.
I still try to, but it’s a lost battle already. (Don’t use Chrome, BTW.)
Github at this point needs to be open source, atleast then they would be an easier way out.
Open source needs to pull its head out of its collective ass and not hand over its entire workflow to private companies.
Github may be the single greatest execution of embrace/extend/extinguish in computing history.
Therefore the real question is if Codespaces is helping to get your job done; I guess that depends on the complexity and structure of the code, the complexity of the build environment/how you work with the CI environment and how the project is being deployed. I guess that this complex of issues will increasingly dictate how things will get done - if these are too complex, then you are better off with a remote environment.
It all depends if the industry will act this way or not, I still hope that there is some level of desency left somewhere, because being too paranoid about all of it will not get me anyway either. Also the utility of all this analytics data is limited, for example they could possible get the 'number of lines of code' written by someone, but it is impossible to judge how essential all these lines of code were to the business. Also there would be a significant backlash, if they get too invasive on the privacy of developers. (that's the moment for the video where Steve Balmer is flipping out on stage and shouting 'developers' https://www.youtube.com/watch?v=I14b-C67EXY )
Some manager may toy with an idea of getting IT to install and manage monitoring software, but ultimately reject it as not worth the cost. But if the company starts to work over something like Codespaces - even if only for purely technical reasons - then suddenly they'll find themselves having a dashboard for free, and for sure they'll start using it.
--
[0] - https://www.lesswrong.com/posts/reitXJgJXFzKpdKyd/beware-tri...
now there is a bit of an irony - github helped open source, now this development will be very helpful to corporate software developers, but might turn out to be harmful to open source as such.
It's going to be paid by your employer which leads to GP's concern about,
> or build a productivity dashboard so managers can fire people for not being productive enough (like Xsolla did)
Which is more likely. If your employer sets something like this up - will they use it to calculate a productivity score and use that for lay offs? Seems rather probable to me.
If they can sell the product AND sell developer productivity metrics to management, they will.
In terms of the biggest companies in the sector, MS has been doing much more for developers and developer productivity than others. At the same time it's not a monolith and so you should not expect boyscout behavior either.
Privacy is a concern, and the onus is on you the user to ensure that you remain in control of your data. When using a service (any service), the answer is to always be ready to bail at a moment's notice. That means using source control and not tying yourself to a specific ecosystem.
Not sure if that's supposed to be an argument for using/trusting MS.
The levels of user and privacy hostility they went to (and are continuously going to) with Windows 10/11 makes me see this as a strong argument against.
This is why I don't like Google collecting data on me now. Not because I don't trust them now, I for the most part still think them trustworthy, but 15 years is a long time and there's no way I can intelligently trust that they will act in a certain way 15 years from now, given the available information at my disposal.
And that's with a company that I think is heavily incentivized monetarily and has a strong employee culture of keeping data private and in-house. Until there are better laws protecting my data or a clear legal relationship with me and an entity with regards to my data, I think the only prudent course of action is to keep as much information about me as possible out of their and others hands.
https://rentry.co/areweweloveopensauceyet
Seriously. It takes extreme naivety to take a SaaS business at face value today. Patterns of exploitation are well-established and easy to spot. Once you see this a couple of times, including in offerings you got so excited about - or worse, you get burned by them personally - it's hard to be anything but bitchy about tech.
The comments may be negative, but the bigger problem is that they're also not wrong.
Deleted Comment
The road is to quantify the work in small packages is a decent one though, dissect a problem until only trivial tasks remain.
Still, I think your intuition is pretty much on point. But with anything, just take the features you like. If your business can dictate this for you, search for other businesses. Contrary to popular belief, there are a lot of those, although pay might indeed be a bit lower.
Deleted Comment
That's not the most valuable info at all.
What would be valuable is to know which ecosystem, languages and tech people are investing time and resources into. These are the ones you need to prioritize for your dev tools. For instance, Microsoft decided to invest in supporting Rust https://docs.microsoft.com/en-us/windows/dev-environment/rus... as well as making sure .NET works on all OS.
> or build a productivity dashboard so managers can fire people for not being productive enough (like Xsolla did)
When a competitor decides to start using these, it's awesome. You get a nice window of opportunity to poach high performers.
Is this satire? A little too on the nose, you know cause Google…
I don't actually doubt that this (and the 4 other glowing employee quotes) are real, but even assuming they are, I can understand people remaining skeptical about the sample size of 5 being broadly representative of the 100s (1000s?) of engineers at the company.
Also slightly hilarious that "This is the way" is a Star Wars callback referring to a character blindly following dogma before eventually realising the error of their ways...
On the other hand, there's quite a few "hints" littered throughout the article that their current setup is a bit of a beast, so I can definitely imagine some engineers being relieved to be able to get such a behemoth off their physical laps/desks: I guess if the local development experience is sufficiently brittle & frustrating, any alternative may seem welcome.
With this setup, you can use whatever local tool you want and, as long as environment variables are respected, they’ll just work. The only requirement on your end is to either run nix-shell first, or to use direnv and ask it to load the nix env for you.
The downside is you still are compiling locally, so you still need sufficient CPU/memory resources, but that’s it.
Unfortunately most companies still aren’t paying any attention to Nix.
That sounds incredibly useful actually. Is that the main sales pitch for codespaces?
Deleted Comment
I've been able to remove WSL from my PC: Docker desktop was gouging itself on resources. I can now also shut down my desktop and continue exactly where I was on my laptop, and visa-versa. I don't have to pull WIP commits back and forth between the two machines.
It's a major leap forward, and there is no need to use GitHub infra.
(Or who hosts it)
I have no idea what actually went into developing the feature, but I would have to suspect that Electron would have contributed to making the separation of an app client vs server easier than something totally "native".
My friends, I’m here to tell you I was a Codespaces skeptic before order 66 and now I am not. Good engineers follow orders.
The nightmarish local development experience of either case are symptoms of deeper issues than local development itself being a problem.
The only people who I don't think would instantly like this sort of thing are people like game developers who basically don't do any unit testing of their code and run the binaries they generate. For those users you could find quite a few ways around that.
[0] - https://www.quora.com/What-does-Googles-web-IDE-look-like
> Visual Studio Code is great. It’s the primary tool GitHub.com engineers use to interface with codespaces. But asking our Vim and Emacs users to commit to a graphical editor is less great. If Codespaces was our future, we had to bring everyone along.
snip
> From there, GitHub engineers can run Vim, Emacs, or even ed if they so desire.
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?
So by extension, codespaces is more risky than my current environment.
Deleted Comment
Doing it in the cloud probably carries some risks for a business that need to be factored in, but I'm sold on the thin-client dev workflow. I'm wishing I could do it at my day job so my laptop stops screaming at me from all the Docker containers.
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!
If you’re worried about your SSH connection being stable, mosh is another option.
Deleted Comment
> I did not have the money for a new laptop
> I could afford the ~55/month for a dedicated server with 32GB and 4cores
Umm... you spent 55128 = ~$5000 over 8 years. You could have bought 3 top-specced laptops. A good $1500 laptop will last at least 2-3 years. You would also get some resale value out of your laptop when you upgrade.
And I was barely coming out of homelessness at the time. 1500 doesn't just pop out of nowhere.
You did just remind me of the time when I was contracting for that company, they flew me out to California but I didn't have enough money on my card to cover the incidentals fee at the hotel they booked for me. Thankfully an employee came through for me. That was pretty embarrassing.
I can get a $55/mo dedicated server right now and code for 30 days straight and get paid. Or I can save for X months for a laptop.
Also the server price will most likely go down over the years or I could get a beefier one for the same money. The laptop will depreciate every day.
According to you they paid roughly the same amount as it would have cost to buy laptops and upgrade them relatively frequently, but amortized over much smaller monthly installments.
And their system would have been elastically upgradeable.
On top of that holding on to money and spending it later is generally better than spending it now, because $X is usually worth > X future $ because of inflation/lost ability to invest.
What I'd really like to see is a WebRTC type interface that overlays this to provide some kind of collaborative environment on top of it. I'm thinking of a built in voice chat as well as multi-author editing within the same codespace. Imagine it like pair programming. I'm in FileA.ts and I can see a little avatar icon of another dev in FileB.ts (maybe surfaced through the Explorer and/or the file tab bar). The voice chat could even be location aware so if we are in the same file/package then we are able to chat. I'd go so far as to allow multiple editors to affect the same file within the codespace so I could see the other dev edit the file in realtime (like coderpad or other interview tools).
I imagine a workflow where a feature/ticket is mapped to a codespace. One or more devs are assigned the codespace and they work together until the feature is completed. Incremental changes are stored up until a "build" action is submitted, resulting in the current contents of the codespace being built and deployed to an internally/publicly accessible endpoint. This might also result in a "snapshot" which could represent a commit to a sandboxed repo. The codespace goes away once the feature is completed resulting in a single check in to a master branch which would go through regular code review type processes (probably a squashed version of their local snapshot's changes).
I think he had everything in your first couple paragraphs working in 1968!
https://www.youtube.com/watch?v=B6rKUf9DWRI
You should try Live Share! VS Code Live Share enables you to collaboratively edit and debug with others in real time, regardless what programming languages you're using or app types you're building. It also supports voice chat:
https://marketplace.visualstudio.com/items?itemName=MS-vsliv...
I see a codespace as a shared destination. It lives independently of any individual. I can hop in and out whenever I want and it continues to live.
To expand on this, it reminds me of how way back in the day we used to use MSN Messenger (and then Skype) to facilitate work chat. The model there was a contact list, a list of individuals I could reach out to and connect. There were group chats as well, but the primary mental model was closer to a phone call. Then Slack came and changed the model so that channels were the default, shared spaces were preferred over personal chats or ad-hoc groups. I don't want the default to be "I have my session and may invite others to join". I want the default to be "there is a shared workspace I connect to that others might be currently active in".
You might even imagine an interface similar to Slack channels (or Teams if that is your world). I could have multiple codespaces as channels that I can switch between. Within each codespace there may be active several devs. I can jump in and out. You could even setup permissions like "read only" spaces or whatever.
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)
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 runs ~$2800 for 32 threads and 64gb memory. DIY would also land somewhere around that $3K mark; a Threadripper 2950x (32 thread) is $1100; 64gb of memory is around $250.
This, of course, is the most expensive option they have; the more standard option would be 4/8; for which you would pay ~$85/mo (all the time, normal work hours), for the privilege of a machine that's far less powerful than any laptop any of our developers have. For god's sake, my M1 MacBook Air is an 8/16, with four of those cores far more powerful than any three year old Xeon Azure has running. And it was like $1400.
I understand maintaining dev machines isn't the easiest thing in the world. I have never once worked anywhere where it was such a problem that the company would justify tens of thousands of dollars in spend. Because it kind of is one-or-the-other; time invested in making Github Codespaces work for your company is time not invested in maintaining local dev environments. And Github's ideal end-state is companies totally rely on Codespaces, so the local dev environments languish.
Its not worth it.
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)?
If your dev costs you $100/h, you only have to save them +/- 5 hours of faffing around with branches/dependencies every month to make it worth it (assuming a 8 hour workday).
Look, this is yet another product targeting naive VC funded startups. Milking the cows until they bleed.
Big could, of course. But considering it takes new devs at my company ~3 business days to get up and running (and we're a React shop), it could be 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.
I guess lucky for them to be owned by Microsoft now and so that's just a cost of doing business. I have a hard time believing they could have even considered an approach like this if they were still paying for hardware out of pocket.
Kudos to the team for figuring it out though.
I do wonder how many VM's they have running though at different points of the day and how many spares they have prepared.
A powerful laptop is a drop in the ocean compared to how much cloud VMs cost per developer.
Sure, you might not need to buy machines that are as beefy (although I bet you'll still need a decent machine to run all your chrome/electron windows) but enterprise maintenance on these machines is still a significant cost.
I definitely don't think one can look at this from the 'saving money' angle.
> I do solemnly swear that never again will my CPU have to compile ruby from source.
...yeah, why was that even happening? Why not distribute pre-built artifacts? I feel like the whole docker ecosystem only exists because people forgot how to distribute software and/or python/ruby and friends make deployment so hard.
Back in the day (ahem), I’d have solved the problem by building new .deb or .rpm packages and letting the OS manage the updates for us. This is a lot harder for languages like node/js, ruby, python, etc… Dealing with a system level packages vs local packages is hard, so almost all management happens out-of-band. Older versions of packages was/is still an issue for many distro-managed libraries. And different projects have different requirements.
In the end, I’m largely okay with this… I’d rather have my choice in local OS and be able to work on my client of choice. I see the rise of containers was more of a response to heavyweight VMs as a dev environment.
But it’s good to remember — these are not unique problems and we’ve solved them all before.
The same issue applies to serverless technologies (at least last when I used them). It was extremely difficult to run serverless services locally, debug issues etc.
Having the cloud is great, but nothing will beat being able to run things locally.
It just gives you so much more control. You're not locked into a specific editor or tool chain, you can integrate with whatever other local tools might be specific to you, etc
This is a great feature, something to complement existing development approaches, but I'm always going to prefer my own setup where I have everything configured exactly how I like it.
My experience aligns very strongly with this. A local stack lets you add debug/print statements anywhere. There is no "magic", you can see the thing run on your machine. The freedom is unmatched.
There are of course risks that the local setup process will differ from the prod environment in a serious way. Even with good automated test coverage I feel less confident about the code I commit here than most other places I've worked.