Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I understand that many companies will be seduced by the offering and what could come next:

* No more source code on developers machine so better for security.

* No more development environment to setup and all the devs sharing the exact same settings: simplified onboarding of devs.

* No need for costly developers machines.

* No more infra to setup to host the source code repository, the CI/CD workflows (even if many companies already moved that to the cloud).

But as a developer I am worried what could also come next:

* dashboards for managers with all sort of stats on developers: code quality with arbitrary rules, productivity (number of lines of codes), number of stars from other developers, etc.

* being locked-in with the Microsoft toolchain all along from source code edition to deployment in Azure. For instance currently I chose to do my NodeJs backend development on vim with coc-vim and found it to be much lighter than Vscode (I have a very old developers machine)



They announced developer productivity analytics in the same keynote as they announced codespaces. It's not just coming, it's here!

Funny enough, after introducing the analytics stuff, they started the next section by showing that the more code you write the more security vulnerabilities you have.

Which is it, Github? Do I want to stay on top of your SLOC leaderboards so my manager doesn't fire me? Or does writing the most lines mean I introduced the most vulnerabilities so my manager should fire me? The answer depends on which product github is trying to sell you at that very moment.


Do I get points for deleting lines of code?


You should get double points!


Do you have link to the developer productivity analytics? Or is it stuck in video form at the moment? Very curious


Here is the HN discussion from the frontpage: https://news.ycombinator.com/item?id=23092966


> dashboards for managers with all sort of stats on developers: code quality with arbitrary rules, productivity (number of lines of codes), number of stars from other developers, etc.

How does GitHub Codespaces allow for any of this? All of this was already possible with plain git, no?


My thoughts:

* Some teams do this already with git data...but if it's free as part of a team's development platform then maybe the less sophisticated managers who don't know how to interpret the data will misuse it?

* If the editor is heavily instrumented then even more granular "productivity" metrics could be extracted, like time spent with the tab active, etc. which aren't available with a vanilla install of other editors. ¯\_(ツ)_/¯


Sounds like a form of (job?) security-through-obscurity, no? The data was always there, but not all managers were savvy enough to process it and weaponize it.

In the end, obscurity is just not a durable defense. Better to earn trust with good managers, and avoid companies that let bad managers flourish. If you don't have the ability to quit a bad manager or bad working environment, then no amount of tooling choices by GitHub/Microsoft was going to save you anyways.


>weaponize it

Oh boy. Had chills from my time as a Jr. Engineer at Accenture. Still remember the day a manager looked at me like I offended his entire family for saying that lines written didn't mean productivity achieved.


It can take years for some to learn that the real metric is how many lines were deleted.


You give managers too much credit.


How does something like this work when you have configurations not in source control? Access keys, passwords, IPs for database connectivity.


It would live in your own personal instance, just like how a lot of company confidential data lives in google docs and gmail today.


You can archive (2) with VS Code by having a development container defined in .devcontainer/devcontainer.json + .devcontainer/Dockerfile + Remote-Containers plugin.

I've been doing that in my company and it's awesome to have a reproducible environment for each project.


> dashboards for managers with all sort of stats on developers: code quality with arbitrary rules, productivity (number of lines of codes)

...down to number of keystrokes. Microsoft has a 25+ years history of spying on users.

> being locked-in with the Microsoft toolchain all along from source code edition to deployment in Azure

That's the real endgame. Lock-in has been Microsoft go-to strategy since the beginning.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: