We've got to stop sending files to each other
shkspr.mobi
shkspr.mobi
I'm far from a seasoned user of git(hub), but the way I use it is to do a whole lot of local futzing around with a bunch of intermediate files and then only git push the final sanitised, public consumption-ready versions which aren't actually possible without the unsanitised intermediate files that I choose to keep private and local.
Yeah, maybe there are access controls possible to setup for all that to make the whole enchilada "in the cloud", but why bother when you can just push the wheat and ignore the chaff? If it's all in the cloud there's more chance of accidentally exposing it to the world (which even happens with the above-described scenario).
And the line about git is just wrong. You don't git push something "to be approved". If you can push it then it is "approved" to wherever you pushed it to.
Storing data on your own computer is a security risk sure. There are places that prohibit checking out source code locally. That has nothing to do with git though, in fact those places generally tend to still use git. Which is a database for your files and changes. You just need non-local computers to edit, compile, test, etc. Which is entirely possible.
One organisation I worked for published the bonus scheme as a web page and I saved it and a year later when they were paying those bonuses they had changed the page silently without any notice it had changed. They refused to admit it changed when people called it out, until I provided the copy that matched everyone’s memory exposing management as liars. I was the only person that saved it, the workers were being short changed for £100,000s.
Hit the nail on the head. I even send emails summarizing hallway conversations I've had, just so there's a record of what understanding I came out of the conversation with. In part because ephemeral conversations (be they in person or over some IM system) often leads to misunderstanding and a summary can surface those misunderstandings, and in part to cover my ass when someone revised history.
It's not only to cover my ass but also to leave as many breadcrumbs in the trail to anyone that needs to read this in the future to understand what happened (including, most times, myself).
It's saved my ass many times and it's just a natural part of my workflow.
You can't control what the person does with it or who they share it with. For all I know they are just uploading it straight to ChatGPT. Therefore sharing files is loosing ownership.
On the other hand just because something is in a cloud doesn't mean it isn't yours. It can also be in your own self-hosted cloud.
See also: analog hole
Similarly, these kinds of measures ("it'll make it harder which is better than nothing") usually just ends up annoying legitimate users while not providing any actual security.
Example: screenshot. Now toss it in ChatGPT or tool of your choice and ask it to extract the content.
Maybe they are feeding it into a screenreader or a local LLM because that is what works for them, or because they suffer from challenges you aren't aware of and don't need to be. You still have the same "ownership" of any files on your computer and data within, from a legal perspective. What you are talking about isn't ownership, it's control. Control to hamper others' usage of data which they're already allowed to access.
That desire for technical control is an exercise in futility: If I wanted to share a piece of sensitive info, aside from copying it via a number of technical means, I can just talk to someone in person and say "I saw...", or perhaps a malicious actor will hack my computer and gain access to it via screenshots, packet captures, arbitrary logging, etc.
Thus, if you don't trust me to secure the contents of a file (whether due to incompetence or malice), and aren't willing to risk it, don't send it to me. Most people in the world don't send me their files, and I'm ok with that. Alternatively, and also common, is to send the file to people who are contractually bound to use it in accordance with a set of terms. For example: an employment contract; or a partnership agreement.
If you look at the venn diagram of 'things people want to send' and 'things people are willing to spend years of approvals and networking headaches to send' you quicky realise why emailed (or sometimes even on a USB) CSVs are the lingua franca of government data.
The author attempts to moderate at the end by saying sometimes you need a local copy. However, as this option becomes rarer, so do the tools that support it. Eventually, you won't even get to make that choice.
As for development, "merging" is far more complicated than for text documents and cannot be left to an automated system.
Is sharing files less secure? Surely. Is it worth it? Yes.
Sure emailing a copy isn't ideal, but it does have the advantage of saying "Here is a set of ideas that I've decided is complete" As opposed to "Watch my stream of consciousness and decide whether it's done or in mid-edit and act on it."
I agree with your concept but I wish more people treated email like rather than as a stream of consciousness or a series of one-line exchanges that would be better off as chats (in some situations, anyways)
Make zillions of copies. Share them around. Storage is a lot cheaper than the prospect of losing great piles of information at the whim of a taco.
However, we don't live in an ideal world. Sometimes sending a file locally is good enough and everything else is unnecessary complexity. Some files will never be updated, some files are updated infrequently enough that manually synchronizing them isn't a burden. Storing files on the cloud also doesn't prevent security breaches, because someone can download the file locally; it does mitigate them, but using a secure (company or government owned) laptop is a strictly stronger mitigation. Adding collaboration support to editors is hard; Git synchronization (with manual push/pull) works well enough if you know how to use it, and Git has other purposes (e.g. commits annotate changes so they can be reviewed later, branches allow one user to experimental changes that don't affect their main branch); it's hard for me to imagine any non-negligible advantages of a collaborative editor over Git with experienced developers, and plenty of situations where it's much worse. One use case where collaboration provides a major advantage is brainstorming, hence tools like Google Docs, Figma, and Zoom's whiteboard.
If I want to edit a Google Doc, my edit must be expressed in terms of the Google Docs interface. If there's a Vim macro that could make that change in moments, it doesn't matter, because I'm not editing text: I'm consuming an API through a web UI. This is why, when I write a Google Doc, I usually draft it in Vim, compile to markdown, and then paste the formatted text into the doc. My clipboard offers me an interoperable workflow that the Google Docs UI does not.
This is why tools like Kubernetes use declarative yaml instead of interactive buttons and knobs. If your medium for communicating information is yaml, you can generate that yaml however you want, and update everything instantly. If your medium for communication is restricted to a set of buttons and dials, you're severely limited in terms of how you express information.
> OK, you're on Office 365 and I'm on Google - so we'll have to work a little harder to set up access.
You're going to have to use files, is what. You're going to download your Google Doc as a .docx file and upload it into 365. And then, unless you want to convert to .docx again, you're going to have to switch to 365 entirely. Google and Microsoft cannot interoperate imperatively with each other's APIs, but they can both parse the same declarative document files.
"When should we pass data vs exposing an interactive interface" is an essential question in software architecture, and someone's making the same mistake here that you see in so much over-abstracted enterprise Java. Sometimes an interface just makes things worse.
I was almost happy when I saw Google Docs has Gemini built in, until I realized it was just another lame model (my go-to has been Gemini Pro 2.5 but I think Docs uses Flash 2.0 or another low-cost model with no option to upgrade).
> A copy is outdated the moment it is downloaded. A copy has no protection against illicit reading. A copy can never be revoked.
In many cases, these are features, not bugs. Importantly it is not obvious a priori when it is a feature or a bug. Sometimes whistleblowers share files "illicitly". Sometimes governments try to remotely delete their mistakes.
Collaborative sharing is great, really. I enjoy it. I use it as much as I can.
But there are many moments when it is best (in numerous ways) for me to just make a spreadsheet. Or a Word doc. Or whatever.
Why? Well it might be muscle memory. Or it's just easier. I'm quite familiar with the way Word formats and indents text. Many other wiki/collaborative doc tools do it some other way, and that means I have to learn that other way. Such an ask is often counterproductive to the task at hand. Replicate this chain of thought for your tool of choice.
Also, sending a file often provides the highest probability that they (receiver) can OPEN it. That's key. I was using a Notion board with a client, saving us all of back-and-forth and send/receive, and guess what: the company blocked Notion. Unblocking will take forever.
But I know my client can open my Word and Excel files. And yes, these are risks!
> It wasn't that he was ignorant about what computers could do, but his entire mental model was built around files.
Yes, this is very common. The problem is that the people without technical expertise are the ones creating the business processes. They need to hire more engineers to show them what needs changed.
> And git! Don't get me started on git! The best minds of a generation stuck in a paradigm of downloading files to their local machine, making changes, then emailing git pushing them up to be approved? Madness!
This is taking it too far. No, the engineers should be the ones who get to deal in files because they are cognizant of the limitations - so long as they can adhere to best practices. Where this falls apart is when you get people saying "you don't need branching, just use main." To prevent that, stronger gatekeeping is needed.
Files for me, not for thee - unironically.
The problem with git is that it has to do a 3-way merge. But there is much more data. Basically every keypress can be recorded and taken into consideration by the merge algorithm.
1. A good enough diff/merge tool for common non-text documents 2. A good enough interface to git
Forgot the part about building and running the software.. The argument is even dumber with that omission higlighted.
Thanks for reading :-)
A copy is always available. A copy is naturally a versioned checkpoint. Having a single author regularly publish an authoritative copy means people always receive a version that is ready and that has been deliberately published rather than something a half dozen authors are in the middle of live editing. It means you can compare versions to see changes.
>And git! Don't get me started on git! The best minds of a generation stuck in a paradigm of downloading files to their local machine, making changes, then ~emailing~ /git pushing/ them up to be approved? Madness!
There is no central server in git. It's often used that way, yes, but git itself is a wholly decentralized database that propagates changes via diffs, with each person controlling what they do or do not allow into their personal graph node. Approvals are important to keep mistakes, errors and general slop out. A request to pull indicating readiness, and code reviews to guarantee it. Working in files is reasonable, as these are the assets that the compilers will be working with. Forcing compilers to download each individual compilation unit from a tagged central database because you're ideologically opposed to the concept of files is more than a bit ridiculous.
The idea of exclusively collaborating via editing using online editors or webdav shards or whatever with no local copies probably sounds great if you don't care about being able to work when there's no network, or using custom tooling, or doing anything that isn't custom built into your IDE, or to build and test without requiring an entire architecture of overly complex per-dev environments constantly being remotely rebuilt on some overburdened and expensive centralized platform.
Thin clients increase control at the expense of user experience.
It sounds awful to me.
They’re useful as artifacts and I agree that living collaborative efforts shouldn’t be represented by files. For that we have databases and can construct pretend files from them.
But you know what a database is? Yep. Files.
This is what every shared online document platform has problems with. RCSes have the least.
I want an experience more like Google Docs and less like emailing diffs to a mailing list.
You stop then test.
I'm sure you have good ideas about better workflows here but I don't think they're as obvious to other people as you maybe assume?
So you make a branch, a bunch of you discuss and edit in real time. Once everyone is ready, you stop and test.
> So you make a branch, a bunch of you discuss and edit in real time. Once everyone is ready, you stop and test
What if you want to test your work out, and don't want to wait until everybody else has finished with their work and stopped working to test? What if you don't want to try to coordinate 100 different instances of "everybody stop working (but also make sure the build isn't broken), I want to run tests" per day?
So now you have to get everyone into the same headspace at the same time and schedule coding sessions across timezones?
What if two people independently feel like doing some quick incompatible changes late at night? Do they have to message everyone on the team to see if it’s OK? Or do they make a branch of the branch of the branch to test it by themselves? How is that more convenient? And in that world, how can you do those tests privately, without everyone on the team (plus the service you’re using) being able to see them? And what happens when you don’t have an internet connection (or your service is down) but you want to continue working?
I agree with the parent comment, there are too many unanswered questions in your proposed scenario.
The whole blog post in general feels incongruent, and it’s not surprising to me you’re getting conflicting feedback. You’re conflating different scenarios and proposing broad vague ideas which are not only impractical for a multitude of scenarios, they remove user agency and give more power to corporations, which is exactly the opposite of what we should be doing.
Your “one person” rebuttal doesn’t work, because one person is not sabotaging themselves in other files of the same project.
I've seen teams develop on a single target system, all of them bashing on the same source code base at once. It sort of works with a well-tuned team, that communicates well, and is capable of dealing with the resulting inconveniences, up to maybe 3 or 4 developers. Probably helps to have dynamic scripting languages in use by most of the devs so you aren't trying to time your compiles with each other's actions. And they still stepped on each other more than I would have been able to tolerate. There's no way this scales.
For non-code documents, by all means share. English prose doesn't crash if you start editing page 5 while someone else has an incomplete sentence fragment they're in the process of changing on page 2. But trying to edit code that way doesn't scale for squat.
From this point of view, whether it's "files" or "a database" or whatever that's being developed on isn't relevant. The point is that I actively do not want somebody else's half done work randomly getting integrated with what I'm working on right now.
This is fine in text documents (to an extent, obviously references to sections of text that no longer exist can happen) because different sections are not as inextricably linked to each other.
Not having a private playground is one of the big drawbacks of all the modern cloud SaaS stuff. If I want to play around and learn something, suddenly that affects everyone else. It shouldn't.
edit: I've see the author's reply, and I guess the original piece was mainly a call to develop better ways of doing things, rather than a claim that they already exist and we should hurry up and start using them. I'd still be interested in more detail on what is fixably wrong with git, though (as opposed to the annoyances that are corollaries of necessary features)
You should keep whatever you want locally. But if you're sharing with someone - especially something sensitive - you probably need access controls.
Not sure how this differs from "sending a file to someone and having them promise not to send it to others".
The only thing "shared links with access controls" adds is real time sync. Which seems to be the point of your article? I'm very confused.
Because that's just an abstraction; they can still make a local copy anytime. Access controls don't magically close the analog hole.
In other words, streaming (or real time collab) is just sending copies of the file over and having their computer promise to delete it afterwards. But if we have control of our own computing (and we should), we can just override that and not delete the data that we already have.
Also, just in case: no, adding even more laws or social rules (i.e. bullying) because "collaborative docs feels different from copied files" is wrong. People have a right to remember and a right to control their computing.
Data in the cloud can be exported and copied same as a file would if you just shared the file.
Now you have another endpoint to worry about, its security, database costs, privacy, rogue employees accessing it, etc.
People's photos were leaked more from iCloud account hacks then their personal phones.
> Data needs to live in a database - not an Excel file.
> Access should be granted for each according to their needs.
I mean, for enterprise users it's pretty hard to beat an Excel file in SharePoint.
You could model the data, put it in a relational database, and build a simple web app for CRUD operations, but unless you're adding additional business logic, I've noticed a lot of the time you end up with a table view that's not as powerful as a spreadsheet and maybe a form to enter data.
I definitely agree that it doesn't make sense to e-mail spreadsheets around, but persistence and user interface are different layers.