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.
> 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).
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.
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.
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.
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.
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.
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."
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.
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.
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.
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.
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.
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!
33 comments
[ 4.7 ms ] story [ 46.7 ms ] threadI'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).
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.
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."
> 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.
> 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.
> 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.
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.
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!