> 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!
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).
stinkbeetle · 8h ago
The diatribe appears to be sarcasm but I can't really understand what he actually advocates for. You can't "living document" source code by having a bunch of people all edit it at the same time like a google doc.
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.
OutOfHere · 7h ago
I am not going to take it sarcasm. I will take it quite literally for the nonsense that it is. Sarcasm is a subjective label that has no objectivity, and so it is best if discarded when not made explicit.
bccdee · 6h ago
Well I guess that's okay if you're not interested in understanding what other people are saying. Anyway, if you're looking for total objectivity, I'd suggest that you avoid interpreting things other people say altogether. Conversational English is an extremely subjective language.
No comments yet
donatj · 9h ago
Until there is some agreed upon open solution I don't have to pay for every month in perpetuity, and can script against as easily as reading a file from my local file system, I'll take files.
n4r9 · 8h ago
Counterpoint: when the product manager attempts to revise history about what was specified for a certain feature at a certain point in time, I'm often able to search my emails for a copy of a powerpoint they'd sent round with wording to the opposite effect. Yes, version history is a thing on collaborative docs, and our documentation processes should be a lot better, but timestamped copies are a sometimes the best way to track what happened with a piece of dev work 10 years ago.
ClaraForm · 8h ago
Bingo! A file sent out creates a specific paper trail and accountability for all parties. If I want to make sure there’s a record of me sending documentation to someone, I’m not relying on giving them write permission to the critical piece of text… this isn’t even about distrust but about clarity for all parties in the file transfer.
edent · 8h ago
Access logs do the same thing. You can see when access was granted, a notification sent, and when/if they accessed it
ClaraForm · 8h ago
Access logs + maintaining backups + version control + relying on the hope that no one’s cat runs on their backspace key during the session where access control says they logged in … that’s the stack you’re recommending vs sharing a file in an email and saying “have a nice day”.
PaulKeeble · 7h ago
I have in the past taken to saving a copy of a web page or document and just keep it in my downloads directory for this very purpose, files aren't big or problematic to use usually. There is a lot more space on a local machine than is usually allocated in enterprise drives and email its a much better place to keep most things, all be it you have to do another backup solution if they matter.
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.
JohnFen · 7h ago
> Counterpoint: when the product manager attempts to revise history about what was specified for a certain feature at a certain point in time, I'm often able to search my emails for a copy
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.
piva00 · 7h ago
Similarly I tend to overdocument everything, everywhere: emails with summaries from in-person chats; messages confirming something decided/agreed upon during a meeting; commit messages with details about why and how something non-obvious was decided and implemented; code comments linking to documents when some product decision was made that I objected to; comments on tickets about decisions/discussions; PR descriptions referencing documents related to the task.
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.
cadamsdotcom · 36m ago
Files are bad; they’re also the least bad thing so far.
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.
Basketb926 · 9h ago
No files, no ownership, all hail our cloud overlords
FinnKuhn · 9h ago
The author is not against files, but against sharing files.
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.
dirkc · 8h ago
If the other party has read access you can't prevent them from reproducing/sharing it. You can make it cumbersome, but not impossible.
FinnKuhn · 8h ago
That is correct, but putting a hurdle like this into place will stop the majority of people that don't know what they are doing and are just going to upload your sensible data to all sorts of places.
bccdee · 6h ago
We're talking about Google Docs. Ctrl-A Ctrl-C takes moments, even in read-only mode. Sure, some hypothetical technology may be able to prevent this, but that's just not how people share documents online right now.
CaptainFever · 8h ago
Most people know how to screenshot or take a picture.
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.
nullwarp · 8h ago
To be fair you can't really control that either. Nothing stops someone from just copy and pasting or taking a screenshot of the data.
CaptainFever · 8h ago
Or, even if somehow all digital attempts are blocked (e.g. DRM), they can just take a picture and run OCR on it.
See also: analog hole
grvdrm · 8h ago
I’d argue it’s basically impossible to control usage no matter what.
Example: screenshot. Now toss it in ChatGPT or tool of your choice and ask it to extract the content.
ImPostingOnHN · 8h ago
> 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.
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.
baazaa · 9h ago
Because security locked-down anything more tech-savvy. Tbh I think the only 'allowed' way of sending data out where I work is to build an API and surface it from a data exchange platform so locked down the incompetent security team barely knows how to get data into it or out of it.
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.
threemux · 8h ago
Dead wrong on Git, not to mention the general, inherent issues with locking your ability to freely share your data behind the monthly plans of cloud vendors. No, local sync isn't a replacement as it's often in a non-free binary format. Cross vendor compatibility issues are waved away as "having to work a little harder". Rarely has a sentence done so much work.
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.
theturtle · 7h ago
The basic problem with his outlook is, as the US is experiencing now, what happens when someone who is not you decides the information you want or need shouldn't be available or exist at all?
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.
bccdee · 6h ago
Collaborative editors are imperative; files are declarative.
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.
noahjk · 6h ago
I've been thinking about that lately since I am working on a set of collaborative documents for a personal project (non-technical) which I also supplement with AI. I don't know of a good platform which 'normal people' can easily use but which can use markdown under the hood to avoid the constant hurdle of translation between rich text and md.
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).
graybeardhacker · 8h ago
We have a number of "living documents" that are the specification for the project I'm currently working on. It's terrible. There's no easy way to know that changes have been made or what they are. Sure, there's red-lining and history. But it requires me to visually scan the document for changes every day, sometimes ever hour.
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."
grvdrm · 8h ago
> 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)
wisaacj · 9h ago
This post was brought to you by Big Cloud
armchairhacker · 7h ago
This is true in an idealist sense. Obviously storing all your files in a shady commercial cloud, with bad network and no local fallback, is a bad idea. But there are potential alternatives: the server could be run by a trusted person in your local community, the files could be stored entirely locally (with synchronization running in the background), editors could handle upstream changes and show other users, conflict-resolution algorithms and editors could provide manual review for difficult conflicts (like Git but better support for non-text), etc.
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.
gatinsama · 9h ago
I don't agree with the take. Computer abstractions should take cues from the real world that we are more familiar with, where objects have properties that we can infer in the digital world, like moving, copying, etc. This makes it easier to reason about and predict behavior.
1970-01-01 · 8h ago
The answer, if anyone actually cares, is to give people training on database queries. It's basically a lost art to the current generation.
grvdrm · 8h ago
This reminds me of the broader right tool for the job approach.
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!
jollyllama · 8h ago
My view on all this has become a very elitist one.
> 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.
000ooo000 · 7h ago
>downloading files to their local machine, making changes, then emailing git pushing them up to be approved
Forgot the part about building and running the software.. The argument is even dumber with that omission higlighted.
eisbaw · 9h ago
git is the solution, not the problem.
_rutinerad · 9h ago
Now you have n problems.
theandrewbailey · 8h ago
git is the solution for code collaboration, but not for document collaboration.
NoGravitas · 2h ago
Only because we don't have:
1. A good enough diff/merge tool for common non-text documents
2. A good enough interface to git
amelius · 9h ago
until you have merge conflicts
mbeavitt · 8h ago
Merge conflicts are a blessing - they tell us exactly what the problem is...
amelius · 8h ago
But if you recorded the intent of the editing operation, there wouldn't be a problem in the first place.
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.
doublerabbit · 9h ago
git is the solution to a even bigger problem.
Herring · 9h ago
Yes this is a powerful argument against discrete packets of information ... delivered to my browser as a series of discrete file packets (HTML, CSS, JS) that are now cached as a local copy on my machine.
hiAndrewQuinn · 8h ago
This is what I immediately thought as well. Discrete packets of information has always been to me the closest one can get to useful immutable state without actually casing the universe in amber.
edent · 8h ago
When you send a copy of my post to a friend, do you save it as as PDF or do you send them a link?
Thanks for reading :-)
rpdillon · 8h ago
I often share archives of posts rather than the link. The web is a pretty hostile place.
AstralStorm · 5h ago
To the OP, when GitHub fails or internet connectivity is down, you're going to be thankful for the local copy that you can later synchronize.
This is what every shared online document platform has problems with. RCSes have the least.
knome · 8h ago
>The modern workforce shouldn't be flinging copies to each other. A copy is outdated the moment it is downloaded. A copy has no protection against illicit reading. A copy can never be revoked.
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.
bubblebeard · 8h ago
For developers, kerping local copies are crucial for several reasons, as is the benefits git provides (amongst other similar versioning systems) outside of simply sharing files.
donatj · 6h ago
I disagreed with this post, but it getting flagged is silly. It caused a TON of actually interesting conversation and debate despite the initial disgust it caused everyone, including myself.
mbeavitt · 9h ago
Just curious - what do you see as being a viable alternative to the current git paradigm?
I want an experience more like Google Docs and less like emailing diffs to a mailing list.
jstanley · 8h ago
Having a private local copy of the codebase is a feature. It means I can make whatever changes I want to the code without anybody else even knowing. And once I've finished mucking about with it and learning what I need to do, I can tidy it up into something I'm ready for other people to look at.
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.
gmueckl · 8h ago
Even in the hypothetical scenario that sources only exist on a server, there would still have to be branches and personal workspaces for lots of reasons. But there'd be none of the current ridiculously overblown git ceremony around sharing a branch with a colleague if you want them to have a look.
mbeavitt · 9h ago
I can't imagine the horror of tracking down a regression and finally fixing it, only to find someone else edited another section of the codebase, ruining all my efforts.
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.
HPsquared · 9h ago
How do you test something if multiple people are making changes at the same time?
jerf · 8h ago
You don't. Having isolated code bases for each developer and a well-defined merge procedure is a feature, not a bug.
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.
edent · 9h ago
How do you test something is working if one person is making changes?
You stop then test.
jstanley · 8h ago
You're going to ask everyone else to stop working while you test something? Even if they agree, what if they continue working in between your changes? What if they are halfway through something and the code won't even compile until they're done?
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?
edent · 8h ago
Not sure if you've ever used git, but developers usually create a branch before editing.
So you make a branch, a bunch of you discuss and edit in real time. Once everyone is ready, you stop and test.
latexr · 8h ago
> a bunch of you discuss and edit in real time.
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.
pjc50 · 8h ago
Once you have branches, you have merges, so you're back to a version of git that's somehow less convenient.
ImPostingOnHN · 8h ago
How do you personally do that branching without git? What tool(s) do you use?
> 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?
latexr · 8h ago
I think what your parent comment is getting at is “how can you reliably test your changes if someone else is changing something else somewhere which may interfere with what you’re editing”.
Your “one person” rebuttal doesn’t work, because one person is not sabotaging themselves in other files of the same project.
ImPostingOnHN · 8h ago
Once everyone is done collaboratively editing, how do you control changes to the file in actual source control (in other words, commit a known configuration and receive formal,audit-sufficient approval from others to integrate the changes into source control)?
retsibsi · 9h ago
Yeah I was just about to ask the same thing! I'm a bit of a luddite, maybe, in that I tend to prefer what I'm already used to -- but I can generally see the other side of the argument. When it comes to git, though, I genuinely don't get what is being proposed as the alternative, let alone why it would be an improvement.
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)
slowcache · 9h ago
I was also wondering this. I don't want my codebase to be a shared word document, how will it ever be in a compilable state?
Retr0id · 9h ago
The idea of google-docs-like collaborative code editing is intriguing, but it's hard to imagine it being practical. I could see it working quite nicely for e.g. pair programming on a feature branch, but at some point you need to merge that branch.
klabb3 · 8h ago
Sounds like the author is advocating for SVN.
42lux · 9h ago
Someone got burned by their own process, more abstractions won't fix that.
tempfile · 8h ago
This article takes dramatic flair to the point of caricature.
> 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.
drcongo · 9h ago
What's git doing in there?
tines · 9h ago
No, I don’t think I will. Enough of this “you will own nothing and you will be happy” crap. It’s my damn computer, I want control.
edent · 9h ago
As I say, "Look, there are some times when you need a local copy."
You should keep whatever you want locally. But if you're sharing with someone - especially something sensitive - you probably need access controls.
mittensc · 8h ago
> especially something sensitive - you probably need access controls
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.
ipython · 8h ago
Fantastic point. Hard to scale stealing data from files stored in a physical location. Easy to scale exfiltrating data via credential stuffing.
CaptainFever · 8h ago
> 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.
TYPE_FASTER · 8h ago
How you store the bits, how you transmit the bits, and how you visualize the bits are three very different things.
> 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.
tgv · 9h ago
Is this some form of sarcasm I don't get?
gostsamo · 8h ago
They lost me on git. Some docs need to be shared and with good idea who, how and when should edit it, the rest of the audience can read and observe the latest sota of the doc. Some stuff has intermediate states and unnecessary biproducts which are nobody's business and loading a common server from 9 to 5 and then keeping it idle the rest of the time is both wasteful and annoying for all participants. Knowing what is your use case is kinda important and spending five minutes thinking about it might prove helpful.
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.
No comments yet
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.
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.
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.
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.
See also: analog hole
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.
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.
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).
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)
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.
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.
Forgot the part about building and running the software.. The argument is even dumber with that omission higlighted.
1. A good enough diff/merge tool for common non-text documents 2. A good enough interface to git
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.
Thanks for reading :-)
This is what every shared online document platform has problems with. RCSes have the least.
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.
I want an experience more like Google Docs and less like emailing diffs to a mailing list.
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.
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.
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.
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 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.
> 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?
Your “one person” rebuttal doesn’t work, because one person is not sabotaging themselves in other files of the same project.
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)
> 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.
You should keep whatever you want locally. But if you're sharing with someone - especially something sensitive - you probably need access controls.
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.
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 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.