I only use Google Sheets(mayberay.bearblog.dev) |
I only use Google Sheets(mayberay.bearblog.dev) |
Pivoted out of there lol
The existing workflow was all down in google sheets, and it scaled to at least 10 states. There were growing pains, sure, but it seems like a monumental waste to spend an hundred years of dev effort replacing an existing working system that cost the price of a Google enterprise installation.
This sentence made me feel like I was reading a young Gen-Z kid's tech complaint at a small company.
and of course Google sheets with its synchronous use model is doing the same
Why? It's easy and quick to code complicated things these days. It's nice having custom dashboards and functionality that fits exactly with what you need. Way more professional.
I'm sure Google Sheets are fine. But I've been seen truly ugly Google Sheets with way too many tabs and horizontal scrolling. Clunky cells that seem to expand and have their own scrolling universe with different laws to everything else. Why can't I simply click the cell to copy it all, nope, let's try double-clicking the cell, I just want to grab the contents to the clipboard, nope. Now it expands and I'm scrolling the whole sheet and have lost my place because Google Sheets tries to snap to rows or something. Damn I hate this memory of navigating someone's horrible Google sheet.
https://www.seangoedecke.com/the-simplest-thing-that-could-p...
https://www.levels.fyi/blog/scaling-to-millions-with-google-...
All I can guess is you have some browser extension interfering? Maybe one that is blocking certain calls Google uses and the sheet doesn't load until they time out?
If you're running an adblocker or blocking trackers or anything like that, try disabling those to see if that makes a difference. Otherwise check the network tab of the dev console to see what seems to be slow.
100% -- this is YAGNI (or you-aint-gonna-need-it) and should be among the first things you think about when starting a new project.
You can whip up whatever you want now with an LLM. And with JS it will save whatever you want in indexeddb or pouchdb and export to whatever formats like csv. Why lock into google?
The only issue was that I had to run the script myself, since my friends were less technical. I'd probably see if I could setup a workflow in Github Actions to do it for me if I were to do this again.
And five years later I consulted companies who had business critical solutions built in MS Access that were not scaling anymore (concurrent users, faster database etc)
Applied to this article: Yes, you can use Google Sheets for all sorts of tasks, but eventually you will need to move on to a more robust solution.
And with native python it has, I can query snapshots from Jira, add inputs etc.
So much simpler, you open Calc's window and just hop faaaast through sheets. Rather than opening your browser, typing URL, entering Jira, getting into correct board etc.
Need a to-do list? There too, just another sheet. Need to track your deployments? Just pull it into yet another sheet.
The sheet is everything you really need.
The ease, collaboration/sharing, and array formulas win out over the faster speed for calculations, better shortcuts, cross-workbook linking, and customization in Excel.
That said, it's been a few years since I've tried Excel so would love to hear someone convince me to try it again.
For all of them, Microsoft has a more complete feature set...but for 99% of things (and anything with lots of collaboration), I prefer Google Work Suite or whatever it's called this month.
2010's: I use Google Sheets for everything
2020's: I use Etherpad[0] for everything
[0] Or any other alternative for that matter
Due to both the third party doctrine as well as FAA702, the feds do not require warrants to access, copy, process, and store indefinitely all information you provide to Google.
Good luck!
A spreadsheet gives you a DB, a quickly and easily customized UI, and iterative / easy-to-debug data processing all in a package that everyone in the working world already understands. AND with a freedom that allows the creator to do it however they want. AND it's fairly portable.
You can build incredible things in spreadsheets. I remain convinced that it's the most creative and powerful piece of software we have available, especially so for people who can't code.
With that power and freedom comes downsides, sure; and we can debate the merits of it being online, or whether this or that vendor is preferable; but my deep appreciation for spreadsheets remains undiminished by these mere trifles.
It's the best authoring tool we've ever devised.
EDIT TO ADD: the only other thing that seems to 'rhyme' with spreadsheets in the same way is: HyperCard. Flexible workbench that let you stitch together applications, data, UX, etc. RIP HyperCard, may you be never forgotten.
And for those who can, Appscript gives your spreadsheet super powers.
For those who don't know, you are not stuck with writing JS in the Appscript integrated web IDE that comes with Google sheets (though honestly it's not too bad itself).
Using clasp, you can develop your code locally in an IDE of your choice, in typescript and have a build step compile those to js, and have clasp push it to spreadsheet.
Once you have the tool chain set up the DX is quite nice.
1) Everything runs on the server, including triggers and even custom functions! This means every script call requires a roundtrip, every cell using a custom function requires a roundtrip on each change, and it feels much slower than the rest of the UI.
2) You can't put a change trigger on a cell or subset of cells, only on the whole sheet. So you have to manually check which cell the trigger happened on.
3) Reading and writing cell values is so slow (can be a second or more per read or write) that the semi-official guidance is to do all reads in a bunch, then all writes in a bunch. And it's still slow then.
4) A lot of functionality, like adding custom menus, silently doesn't work on mobile. If your client wants to use Sheets on mobile, get ready to use silly workarounds, like using checkboxes as buttons to trigger scripts and hoping the user doesn't delete them.
Overall I got the feeling that Google never tried to "self host" any functionality of core Sheets using Apps Script. If they tried, it'd be much faster and more complete.
Here you go: https://visualdb.com/
Pretty sure something fairly similar is built-in these days.
And yes, not the greatest way to proceed once you know what you want, but a heck of a way to iterate quickly and identify the actual requirements.
it works fine initially, but for long term it's usually more productive to have custom software.
100% agreed. Creating a spreadsheet is declarative programming, and Excel (and now Google Sheets) has made more developers than any other platform (probably by an order or two of magnitude).
I do not know a business that was not CRITICALLY dependent on Excel for actual business operations through the 90s and 00s...and the same is likely true today.
There are plenty of tools for that. Airtable comes to mind, or if you want to use your own database try: https://visualdb.com/
I worked in a computer lab in college, ca. 1989. One of my colleagues was in the mechanical engineering program, and had a bias generally for "solve the problem" over "elegant solution" or "appropriate tool" concerns. (I love the guy to this day, to be clear.)
When he first came to work at the lab, he was the only guy to have installed FORTRAN on his workstation. It didn't work well.
Then he discovered Lotus 1-2-3 and its macro language. He DELIGHTED in making the rest of horrified by creating all sorts of boundary-pushing utilities in Lotus macros. To be clear, he was at least 50% "doing a bit", and leaning into the "engineer only knows one tool" gag we'd all been riffing on. But he was still doing absurd stuff in Lotus that would've been better built in, say, Turbo Pascal or Turbo C.
I had no idea back then that this pattern would become so prevalent.
> especially so for people who can't code.
One day you are writing ‘sum(a2:a201)’ the next you do some conditional formatting and so the complexity builds up very slowly with your needs.
With sql, day one:
‘SELECT SUM(Column) AS Total FROM Table;‘
Way more complicated. Way more powerful too, but most people don’t need the power until much later.
And you have to work in the console which is an unfamiliar ui for many.
It’s not impossible, but very high overhead in comparison.
That's it. It's the math notation from high school, plus cell references, which can be inserted by clicking a cell.
Years after we broke up, a new company she joined required her to take a VBA training course, and she texted me and told me I was right, VBA was easy and her biggest challenge was being patient while the other students struggled.
I spun up a local Grist instance in my org, using SAML with our org's email authentication. It's intuitive enough that I've replaced a few shared spreadsheets with it (now with rowwise permissions) and powerful enough that I've also replaced a few internal CRUD apps.
It's not in any way a spreadsheet, you can't use rows correctly and everything is stuck in columns. Not to mention the forms you use for input are not user friendly compared to a simple understandable coloured cell
Minor point, but I would say that people who can construct formulas, are indeed coding.
Nobody wants to explain to IT that they need to install Python on their machine, or drivers for sqlite, or - god forbid - get a proper database. Because that requires sign-off from several people, a proper justification, and so on.
There's Decker https://beyondloom.com/decker/
It is also a very bad co-authoring tool imo unless you have a very tight team and processes of how to use spreadsheets. I would not mind if I was using it alone. But spreadsheets encourage a certain naive "visual" approach to structuring data in them that can become an issue if you want to import the data to actually process it somewhere and your coworkers don't really understand this well.
Spreadsheets can be useful, however:
1. Speaking about excel in particular, localisation issues are an absolute nightmare if you happen to live in the wrong country (commas vs dots for decimal points) especially while importing CSV files (which is already unnecessarily complicated in excel). If somehow you don't notice these issues, you end up with wrong data without understanding there the error came from.
2. If your coworkers do not really understand very well how spreadsheets work, you quickly get to become really frustrated with issues coming up when you have to import a spreadsheet for actual processing. Datetimes with different forms, coloured boxes being meaningful, mixtures of text and numbers and whatnot.
Yes a big part of it is "people problem" rather than "technology problem" but imo spreadsheet technology (excel, google sheets etc) encourages a variety of practices that make it less reliable. If the technology gives you the freedom to mess up too easily, imo it is not just a people problem.
I have a couple of spreadsheets that I use on a weekly basis, and I found it easiest to build both of them from scratch, despite the tons of examples floating around for exactly my use cases, and despite it being my first time building anything with a spreadsheet in 10+ years.
On the bright side, after using these spreadsheets for a week, I lost all desire to write apps to do the same things. Google Sheets is a good-enough UI and solves sync across different computers and mobile.
i might have used it for burned CDs too, I can't remember. at work i had access to burning CDs at scale back then, I just don't remember when the blanks became cheap enough that nobody would notice my pilfering and and whether i still used my mac. i did burn disk backups to CDs
Give me a spreadsheet with a world cksss user interface and then you’ll have something!
Also what you're looking for is called Microsoft Excel. Every one else is doing webshit UIs which can't be world-class by definition, because they hardly scale to real workloads :).
Excel used to have its own video game as an Easter egg.
They can emulate behaviour of databases; but the missing parts missing will haunt you. Spreadsheets are a jack of all trade, mastering nothing, haunting you with everything;.an amplifier for the Dunning–Kruger, where people are misguided about data-quality.
Spreadsheets are indeed a great tool, but the implementations we have today are bad, with too many booby traps, not enough safeguards, not even much comfort for those with higher demands.
Yeah a DB where any user can accidentally hit the spacebar and erase a formula, and never see any warning that their outputs are now horribly inaccurate.
What Problem?
If someone shares a sheet with me, it’s for the intended purpose of sharing data and/or visualizations of that data.
I’ve always been a huge fan of spreadsheets, and the rare times I’ve encountered them being misused, it was a long time ago, and not near enough to make me an “anti-spreadsheet” person.
It sounds like these anti-spreadsheet people need to find a new place to work and/or new coworkers.
Either way people shouldn’t be anti-spreadsheets because some people misuse them. That doesn’t change the fact that they’re a great tool for tracking/sharing/visualizing data.
though, much programming is poor and often can be accomplished better in a spreadsheet given the situation and use case...
You need experience to see the shorcomings of spreadsheets. No version control. No tests. In general it's good for things that don't need to evolve, but stay the same (most likely because they're short lived).
[0] https://news.ycombinator.com/item?id=33611431
[EDIT] An example of a comment from that thread pointing in this direction:
> In general, you adapt to the excel owner's quirks, not vice versa. If you don't like it you should create an excel sheet of your own and copy/paste, which people also do.
> I knew a project manager who's job seemed to be reconciling multiple versions of a spreadsheet with different authors.
When solving a problem, solve the problem you have, not the problem you think you might have in the future, or the problem you wish you had. Your solution will prove inadequate in the future, but you are unlikely to correctly predict in what way your solution will be inadequate.
but you can choose a current solution that does not block nor inhibit a future solution. As they say, always keep your options open, and don't vendor lock-in yourself into a corner.
One inadequacy could be complete dependency on a vendor who accidentally locks you out of all your services or starts scalping you with ever higher fees. That one is quite predictable here.
That should, with no extra work, solve future problems.
Like do you really need a dashboard on day 1? Or reports on day 2? Sometimes you just need a log of data. And the columns can grow and shrink.
This was not because it was a Google product (we used plenty of competitors' products) but because it is so easy to make them good enough for the task that you can move on to getting the job done instead of administrating getting the job done.
And then, of course, if you want reproducibility, you just check in Colab notebooks into the source control.
Is that the case? I find that super interesting. No sexy Slack or Teams type of thing?
There's also the ticket system. Sheets are commonly used by various PMs and TPMs for high level tracking, but IC eng stick with the tickets.
It works fine.
Right or wrong, it takes a certain amount of chutzpah to put forth such a definite opinion after less than a year in the workforce.
What OP probably misses is the "there ain't nothing so permanent as a temporary solution" thing. I too embrace quick and dirty solutions but only if I have total control over the lifetime of that solution. If someone's going to ask me to deliver it immediately and then build a castle on top of it... I might insist on using a tool that has more up front cost.
Not saying the author isn't onto something: using the simplest tool that will get your job done -- and bonus points if you can reasonably use the same tool for several things -- is a decent principle to live by. Using an existing tool is great, when it meets your needs without too many difficult trade offs.
And where they work, it seems like business requirements are scrapped and rewritten every couple months, so the whole "temporary-haha-yeah-right solution" problem doesn't really rear its head.
The rest of us have to deal with the difficult mess several years down the line, because "we'll throw it away and write a new thing once we need to scale" is something that very rarely actually happens.
Of course, the author has no experience of a year down the line, let alone several years down the line.
I have an Expense Tracker UI within Google Sheets that allows me to submit expenses to the main sheet (currently just over 5000 rows of expenses over the last few years)
I only just recently vibe coded a web UI tool that uses a Google Service Account to add expenses to this Google Sheet for me, and then created a Progressive Web App from that so I could do everything on my phone.
In summary, Google Sheets is sometimes all you need instead of a database for very simple applications (and built for an audience of one)
Not to say there aren't features I wish I could easily have. I could of course build it, and I've "started" so many times, but after a few hours of the typical boilerplate code you have to deal with, I'd always give up and go back to my surefire solution.
(This was before vibe coding, so I may take a stab at that)
The spreadsheets looked dated when I started working here, 7 years ago.
2 years ago, my latest manager tried to move the department off these spread sheets to the corporation wide system. Another corporate wide system is set to replace the system we still aren’t using by the end of 2026.
I suspect we’ll still rely on our spread sheets in 2027.
One thing I would add is, sometimes when you need some extra complexity that's too difficult to express or build in Google Sheets, one step above it is Google Colab (or any other Jupyter notebook).
Before building a full blown app, I always ask myself: 1. can this just be a spreadsheet? If not, 2. can this just be a Jupyter notebook?
And yes, the integration between Sheets and Colab is great.
I know of the gspread package for python... but I can't see how that gives you anything but the raw data from the sheet. any graphs and interaction (!) and such you would have to redo in jupyter.
Or maybe that it doesn't make that much sense to look for a most important program.
- Donald Knuth
Start with a gsheet, when it breaks build something else.
Google Sheets was phenomenal for prototyping apps and getting quick feedback from users back when I used it in 2015-2020. Back then they had this janky implementation of Mozilla Rhino underpinning their "Apps Script" engine and it still beat the pants off of anything else you could use for free.
Certainly you can shoot your feet with the various spreadsheet-isms but if you're diligent about keeping raw data pure (preferably in a completely different sheet inaccessible to users) it does a bangup job of quickly shoving a UI in front of users and letting them realize what they want and iterate on it before calcifying it into a more rigid system.
Spreadsheets are the best tool to quickly spin up and make changes to data.
I've always thought about a tool to make a 'front-end' version of spreadsheets that end users use, where the layout can be a bit more freeform (i.e. build reports and dashboards in spreadsheet, then 'select' these reports and paste them into a front end WYSIWYG tool).
I use Google sheets myself from time to time, but I regularly do backups of the sheets I'm working on, or anything important I have access to. I've been in the hole before, for reasons I still do not understand, and it was one of the most frustrating "customer support" processes I've ever experienced, and it took years.
One thing to note is that a spreadsheet (OPs insistence on calling it "Google Sheet" is amusing after years of hearing people call it "excel", it's a spreadsheet, people!) is a poor-man's relational database, with most spreadsheets having a single table, or multiple tables but modeling no relations. And you can't model relations in a spreadsheet in any meaningful way (imposing constraints, checking integrity, etc).
Written from the perspective of someone who makes a living providing a SaaS for (among others) inventory control, for which a spreadsheet is a direct competitor. Also, from the perspective of someone who has seen a lot of customer spreadsheets with inventory, not one of them in any way correct or containing good data.
I wonder what the best non-mega corp solution there is for this.
For a non web interface, things like libreoffice can be good too but I think that you are asking for a web version..
I am not sure if libreoffice has a web version, it seems that they do but I can't find much information and I might recommend crytpad personally so.
Some of them are AirTable like which is CRM focus, but I just want a really simple spreadsheet that is easily accessible and not from Big Tech.
Edit: Depending on your reasons for avoiding big tech, you may want to research the owner of Only Office, which was a Russian company but apparently isn’t anymore? You might want to also try CryptPad, which is based off of OnlyOffice and recommended elsewhere in the comments (which reminded me).
A truly shining example to google doc alternative.
It would be great to have some kind of syncthing <-> cryptpad drive, then it can be very nice alternative to even dropbox. Not sure what the development is ATM.
1. A lot of people are creating dashboards / CRMs - either they don't have any one selling them verticalized Software or its too expensive. 2. Some people have verticalized Software and they use Sheets so that they can share data with others without paying for per seat SaaS while not worrying about what the new members can read/write into 3. Lots of financial modeling and planning - From a chain of Cafe's in Laos, to Startups raising funding. 4. Lots of teachers trying to do scheduling for their school while ensuring that the teachers get enough of a break. We have seen this in Colombia, the US and Italy 5. A lot of market research and enrichment
A Spreadsheet really is the IDE of a billion people. You can try us here https://tabtabtab.ai/
I've recently been experimenting in Apps Script to write my own (physical) book collection record system with a USB barcode scanner. So far I have nothing polished enough to show, but it is a very cool platform. I found it a bit frustrating that I couldn't just import NPM packages, but at the same time it's a good excuse to embrace simplicity and skip a library like Axios, and rely on its built-in fetch()-like API.
1: The original YouTube video has since been taken down, but you can still view it through the Wayback Machine:
https://web.archive.org/web/20161118170705/https://www.youtu...
- My own rough business accounting (download all bank statements and do some pivots and graphing. Real accountants do the real thing, but I like to have a version that makes sense to me and that is up to date)
- Personal accounting finance tracking for sharing expenses and tracking living costs over time
- Consolidated asset tracking across different projects/accounts etc, just a quick summary that's not perfect but spending 10 minutes a month manually updating it helps keep it in my head too.
- A lot of project management (we also have real PM tools, but I keep my own sheets because it's easy and it makes sense to me)
- A bunch of quick analytics (I also use metabase, but sometimes it's just faster to create a graph in sheets)
Most of the time the sheet is not the _main_ tool I use, but it is the easiest and most useful one, while the others have better integrations, safety mechanisms (I often end up with +500 or whatever in a copy-paste formula error and sometimes don't catch it), and collaborative measures (if you have 2+ people editing the same sheet you're usually going to have a bad time)
Sharing is the killer feature. Not that you can't share with Office 360 these days, but many of us were sharing Google Sheets years ago when the rest of the world was still sending Excel files as email attachments, and there hasn't been much reason to switch.
Probably not used by many, but if you need to break out of basic functions, some may find working in Javascript preferable to VBA.
Sharing Excel sheets and keeping them in sync is tedious. (Even with O365/OneDrive)
This may also include sharing between your own devices.
But google sheets is so much easier if you have more than one person interacting with the data. It just works, easily, every time. Even with 365 or whatever for MS products, they're more cumbersome.
It sounds crazy, but it’s the best tool for so many random things, and here’s why I stick with it:
It Just Works: There's zero fuss. I don't need to install anything, I don't need to save it, and I don't need to worry about the format. It's always there, and it saves automatically.
It's Simple to Share: If I need to show something to my spouse, a coworker, or anyone, I just send a link. No one needs to sign up or download some special app. Everyone can open it right away.
It's the Perfect Checklist: For managing my own stuff—like a budget, a travel plan, or even just tracking a personal project—a sheet is faster than any fancy app. I can make columns that say "Done," "To Do," or "Waiting," and that's all I need.
For most of my personal data and quick shared work, trying to use a dedicated software package is just overkill. Sheets is the easiest way to organize information in a clear, digital table. It's the ultimate low-tech solution to high-tech problems.
However, the other side of this double-edge sword is its fragility, when data or logic grow in complexity, it raises more errors than it should. That's when a niche product gets its chance to chime in.
I think even a complicated spreadsheet that can be directly edited and modified by the actual business stakeholders is preferred.
Your 'trifles' are the biggest screw-ups from functionality to INFOSEC.
You can use version control with Excel spreadsheets, though it's not very good. It's called "track changes" and even has a limited capacity to approve/reject changes from other people.
Very few people uses that feature, especially not the people who have built a Rube Goldberg machine to run their business processes, but you could do it if you wanted to.
Any flaws with Excel haven't been due to the actual program or data, but just how the files are managed within projects. Labyrinthian sharepoints, files being forgotten about on network storage, etc.
Not sure of that. Examples:
https://www.sciencedirect.com/science/article/abs/pii/S01679...
He sold the business for $400M. No outside capital, he was the only owner.
But it's likely that, as these things go, they added much more features and visualizations on top instead of just a like-for-like replacement.
TL;DR that company was bootstrapped successfully on just a spreadsheet.
Absolutely don't. The one who built the spreadsheet will have changed companies and the "business logic" and the knowledge will be gone with them. You're now stuck with a blackbox that no ones knows the specs of but everybody depends on.
Turns out when you make relatively simple software, it doesn't really need maintenance. How often do you need to maintain a function like f(x)= mx + b? If it works it works.
Maybe Spotify won't be taken down overnight, but they can lock me out for various reasons such as misdetecting an IP address (Google wouldn't let me log in at all when they thought I was in Russia, when I was at 31C3 in Hamburg, Germany, a conference where they afaik use some temporary IP space — I don't know what consequences that would have nowadays)
Hacker News also: if there are things here you want to keep, store them yourself
Facebook chats, Signal, etc.: download the data in a format you can decode if there's anything you want to keep. Make sure you can decode this Signal backup format if your phone dies
The usual rule when making backups is that you need 3 copies, one of them offsite. A cloud storage service counts as an offsite copy, but you still need two more, typically one on your computer and one in cold storage (ex: external hard drive).
Treat cloud storage like you treat your hard drive, it can fail at any time. The failure modes are different: mechanical failure vs losing access to your account, but the end result is the same: the system is unreliable and you have to engineer around it.
I managed to set up private self-hosted versions of an email client, photo viewing app, and barebones alternative to Docs and Sheets. Switched from Google to Kagi, and Chrome to Brave, but generally keep my own bookmarks of sites to use rather than using search engines.
I still run a skeleton Pixel, but the storage is almost exclusively just a very limited range of apps I use. I managed to get Google One storage from about 700GB to about 700Mb over the course of the last month or so.
I also set up my first home server with RAID NAS. It's on my list to spin up an OpenOffice container or something I can use to replace Google Sheets. That will let me delete my Drive data; next is Google Photos and eventually Gmail.
I’ve looked, I’ve never found anything that seems to both cover all the bases and not feel like a bad Microsoft clone.
I tried Nextcloud a couple of years ago but found it really buggy and slow. Even the basic notes editor on Android was absolutely terrible. Absolutely no comparison to what I'm using now, Obsidian with Syncthing.
Can anyone recommend a good sheets alternative other than Nextcloud?
Nothing like that should happen if you're paying for even an individual Workspace plan. You get a phone number for customer support, and it works.
Google shuts down free accounts when it believes they're being used for fraud/spam. And because scammers and spammers create them at virtually zero cost, and will fake activity to build account credibility until using them for nefarious purposes, that does mean legitimate free accounts occasionally get caught.
Regular backups are important no matter what though. Obviously Takeout exists, but there are lots of third-party automated backup solutions as well that will automatically convert Sheets files to .xlsx as part of the backup process. I use one that backs up nightly to my NAS.
Last I was a workspace Admin, you had to login to get the phone number and the code to dial once you called.
It certainly did get you to a human. Unfortunately, they were not empowered to actually help with any of the things I needed help with, even when it would just be filing a enhancement request with the product team (they just tell you to post in the unmonitored product forum)
I've seen several believable tales of Kafkaesque billing issues leading to Workspace accounts being suspended. It took months to get them to do invoice billing.
I don't believe this after decades of past experience with them trying to find any human to contact. Have you seen the phone number yourself? Normally they just give you the runaround trying to navigate a maze of support pages.
Just don't use any Google services. Not free, not paid (why would you send them money???!?!). Not for personal stuff, not for work projects. Not for throwaway data, not for important data.
When companies buy services from others they often ensure that the contract has protection from things like this. They have clauses that the data belongs to them. They have clauses about what happens if the company is sold. They have clauses about abandoning the product. They have a number of other things added that I'm not aware of.
You as a single individual (and often as a small business) don't have the power to get that into a contract. However you still should read the fine print - you should go elsewhere if it the fine print is against you.
We already pay nearly $90/mo for 6 seats!
Anything we made would have _never_ been as good a UI and would have stopped us from being able to publish new content. The other nice thing about them is you can scale the integration effort. You can download a sheet from GS as a CSV then upload that in an admin page and you can probably ship that feature today. A tiny bit more effort and you can add a 3rd dimension to the data by finding an XSLX library and exporting the page as an Excel workbook. Eventually you can do something with their API where you just click "reload data from the master sheet" and you can generate all the data you need to preview the changes on the frontend. That's what our Airtable integration looked like. Airtable was very "pull this in via API" native and had a better way of expressing higher dimensional data in cells which matched nicely with Postgres storing arrays in cells.
While powerful, this assumption also creates rigidity that a pure spreadsheet doesn't have. You can't, for example, do some quick scratchpad analysis off to the side of your data, or quickly subtotal a few rows with an adhoc formula. For that type of flexibility, you need a pure spreadsheet, which is the camp that Row Zero falls in (along with Excel & Sheets).
So, to answer your question - they're solving different problems. Some spreadsheet usage may be better served by a visual (or actual) database, which is why that sector has exploded in the last decade. But not all use-cases fit that criteria - the flexibility of the pure spreadsheet remains an incredibly powerful thing.
If the business stakeholders can edit said spreadsheet, they can code. Not well probably, but they can.
So, theoretically, they should be able to open a python script or whatever and hack away. A lot of calculations are actually much easier and straightforward in a real language as opposed to Excel.
But they won't, partially because developers would never let them.
You can do that in a spreadsheet-database hybrid such as Airtable.
Yes. Do you have a paid account? It's in the Google Admin console. It gives you a PIN to enter when you call.
By the time they do get big enough to hire internal IT, the Rube Goldberg system is entrenched. Then by the time they get big enough again to need an internal dev team because off the shelf SaaS no longer cuts it, it’s too late. It’d take too many dev resources too much time and money to fix the spreadsheets, design databases, and start popping out web apps.
Plus the software development process is too rigid for how fast business requirements can change. The accounting department will just do it in Excel in an afternoon instead of being willing to wait 2+ weeks for the next sprint.
So we end up at a place in big enterprises where only some things get successfully moved to something more robust but there just isn’t enough resources (or will to allocate those resources) to tackle every spreadsheet, and so there are always key parts of the business that will forever run on Excel.
When people want off-site backups, the server owner can say they've already taken care of that. I'd say that having a copy under your own control is a separate checkbox we should include!
The third backup being in a decoupled system on site is what you now count as your ”offsite” backup. Having this last copy is non-negotiable, no matter how many 9s S3 claim to have.
I’ve worked in academics and industry around biologists, chemists, physicists, statisticians, bioinformaticians, and all varieties of engineers.
I’ve never seen “huge swaths” of anyone expected to learn R for anything outside of a few niche areas in statistics and bioinformatics.
What people are expected to know is how to use a spreadsheet. What people are often given is Microsoft Excel, and essentially nothing else. A lot of companies wouldn’t dream of letting random employees install or use R or Python.
It’s not ideal. But some battles can’t be won and aren’t worth fighting. Which is why people use Excel for so many things.
I never seen R being used, when Excel doesn't work out, it is something like Tableau instead.
If you multiplied the custom software development effort and cost to the multitude of places and use cases people in an organization are using spreadsheets I think you’d quickly find that it’s infeasible. And that’s not even taking into account how much value the adhoc-ability of spreadsheets adds to the equation. Most spreadsheets can be completely refactored or thrown away in a rather trivial manner. The sprint nature of software development screens out most things that could be spreadsheets. I’ll build it in an hour instead of waiting 2 weeks to get on the next sprint.
The software development process is too rigid for rapidly changing business needs. Having to spec out requirements and such is often an unknown and something you’re doing live in the moment when creating the spreadsheet itself.
Huge contrast with MS approach to this
If all you want is to see previous versions, just make the files read-only after saving them and increment a number in the file name every time you change something.
Wait what, how does (did?) that work?
And more importantly (I can find the opus files myself): can/could it retrieve my account data to know which songs to download?
I've been able to partially reconstruct my music from localStorage, downloaded songs on my phone (yay for having root and access to that data folder), and memory, but it's still incomplete
Fwiw, here's my own little contribution to getting song data from Grooveshark, in my first blog post: https://lgms.nl/blog-1 (not my first blog site though). Happy to meet other fans :D
Those users are accustomed to doing their work in a spreadsheet so it makes it harder to automate the process.
Spreadsheets are amazing tools, but they must not be used as the source of truth.
To an accountant, excel spreadsheet is a source of truth. There is no undetermined behavior. They can look at the calculations underlying the spreadsheet and understand what is happening, no different than a developer looking at source code. They do in fact have their own forms of unit tests considering these data are audited in a far more rigorous fashion than most any code that ships with unit tests.
I'm also wary of just moving from one product to another, with the hassle of transferring things over constantly, security breaches, product sunsetting and all of those sorts of things.
I'll give Nextcloud a look out of curiosity.
It looks a bit dated like MS Office, but it does the job and since it used MS Office formats, I can edit the documents with Libre Office or other sofwares. And using the API, I can programatically access those files.
It saves (both locally and to self-hosting) to JSON and, exports to PDF and HTML. And then I wrote a script to convert docx files over when I migrated from Google.
Haven't found a good self-hosted Sheets alternative yet.
What's (to me) much more exciting to me is the incremental local backups they're working on. I've iirc looked into how to decode these big backup files, and copy them off my phone semi-regularly, but this being rsyncable will make the process much faster
Even if it works for desktop clients also, that still needs to be set up using a data matrix scanned by the mobile device (or if that's already done before you lost the origin device, you can "simply" extract the faux-encrypted sqlite format that the desktop client uses, albeit with having to recompile this encryption extension for Sqlite manually — ask me how I know..)
In other words, one of the core use cases for a spreadsheet is that it empowers a broad swathe of users (broader than Tableau or PowerBI) to quickly extract insights from their data to fill immediate needs.
Or at least, that's a core use case if you can get your data into a spreadsheet without too much trouble.
The problem corporate IT/Dev folks face isn't that an idea started as a low-code tool, but rather that the low-code solution is often dumped on them with no budget or desire to improve it to be more reliable and maintainable.
At least until something fails... and usually in dramatic fashion that then wakes leadership up to the idea that maybe we should invest more into this critical business process. If the company didn't go under in the meantime.
I imagine that's because it's not really a technical problem, but an issue with how the whole organization (mis)handles complexity, and we collectively [1] still struggle to model/name a lot of those problems.
[1] Yeah yeah, I see you there in the back, you excited cyberneticist bubbling with enthusiasm to share... but I mean as a practical widespread matter.
As I see it the limitations of spreadsheets are what keep them from becoming the official way of doing things. At some point most of the stuff in the spreadsheets has data provenance in a properly managed IT system somewhere. If companies could get rid of this part of IT they would suddenly find themselves in a trillion dollar pit of lost money/inventory, As the spreadsheet mess spiraled out of control with no source of truth.
Other software that I use and write is version controlled and has tests to catch errors, mistakes, typos. Those tests regularly find and prevent problems! Likewise version control.
Could we get the same with spreadsheets? Seems difficult but not conceptually impossible, particularly with LLM assistance.
Also I remember Row Zero the demo on your home page was impressive. You guys were S3 engineers too, good to know your project took off. :)
You can create a super quick Python app with visualization and whatnot in about the same time as a spreadsheet. But then it's not online. And it's not best practice.
Web is just a fucking beast and then developers go in and add additional complexity.
It would probably be a much simpler web app if you made it just, like, a bunch of PHP scripts thrown in a folder. But they won't do that.
I guess Google Sheets invalidates some of my arguments, but Excel certainly does not. And, even if the feature is there, I've never seen them applied.
That's a feature of any SaaS. Adobe frequently shuts down ETLA customers due their own invoice processing failures. I can think of three significant government subdivisions that were unable to access any M365 service for 1-10 days as a result of a reseller change.
The real lesson here is that you need to understand the failure domains of the technology your business depends on. Your business is as good as the contracts you rely on. We're relatively good at preparing for IT failure, but not so much the other stuff. For small businesses, key revenue generation could be stopped by an employee doing something dumb with a corporate card.
Resellers handle a bunch of compliance paperwork necessary for the government, and are also contracted for migration and support needs.
None substantiating the "most AI-kafkaesque process imaginable to regain access" upthread though. I mean, I don't know what you're citing specifically, but yes, obviously: business relationships like everything else get tangled up sometimes. People's electricity gets shut off incorrectly, people's Doordash orders arrive with the wrong stuff, phone bills arrive without the promised discounts; everything sucks, kinda.
But if you're paying the solution is to call your support contact and have them sort it out. And that works at Google the same way it does everywhere else.
This is true of MS Excel's scripting language (VBA) as well. Worksheets are objects with events; cells are objects without (VBA-accessible) events.
It may be an issue with scaling and efficiency.
Not only is scripting Google Sheets indeterminently and syrupy slow, it also imposes an arbitrary limit on how long your code can run, making a lot of applications not just inefficient but impossible. Running your code in google's cloud doesn't make spreadsheet api calls any faster, it just limits how long you can run, them BAM!
To get anything non-trivial done, you have to use getSheetValues and ranges to read and write big batches of values as 2d arrays.
https://developers.google.com/apps-script/reference/spreadsh...
It's easier to just download the entire spreadsheet csv or layers and bang on that from whatever language you want, instead of trying to use google hosted spreadsheet scripts.
I think that’s a consequence of the fact that multiple users can simultaneously edit a sheet. Yes, Google could special-case the “you are the single user of this sheet” case, but that’s extra work, and, I think, would be fairly complicated when handling edge cases where users frequently start and stop editing a sheet.
No, it's not. Built-in functions like SUM recalculate instantly, and custom formatting rules (e.g. "color green if above zero") get applied instantly, even when there are multiple users editing a sheet. Running custom functions and triggers on the server is just a decision they made.
Arbitrary AppScript isn’t guaranteed to be idempotent. You have to run it only once.
That's entirely different from another entity denying you access to your data.
It's also ironic that we're considering docx etc as open formats these days.
For storage platforms like Dropbox or Onedrive, it can be as simple as ctrl+c'ing the data out of there every now and then
For Spotify, you can do the GDPR export and check that you can open it somehow. Even if it's not super readable, you can figure that out (with a tech friend or LLM perhaps) if you turn out to ever need it
For Signal, I've got no idea. The format is hard to work with for hardcore techies. They really really don't want you, ahem, attackers to get that data in the clear. (Two-sided coin). Make sure to turn on the backups, write down the passphrase, and take them off your phone every now and then, and hope there's a restore method when you need it
It happens all the time where I work. I don't want to be specific, but we have lots of examples here. In some cases people don't like the core software, so they work around it by tracking things on a spreadsheet. And sometimes that spreadsheet disappears (in one case, it was being kept on an XLSX on a USB thumb drive, but the thumb drive got corrupted and we lost some very important data.)
To say that it was a nightmare was an understatement. They were willing to dump vast sums of money to get something better, but they'd homebrewed so many human processes to deal with the spreadsheet that they struggled to adapt to a more conventional way of doing things.
With that said, it's still a great tool for the job because the different stakeholders can inspect it.
Lol. Go to literally any bank. They all have a legion of accountant,analyists that's sole job is to maintain their little fiefdom of spreadsheets that only they understand.
If most people knew just how held together by string,tape and gum the banking industry is there would be a run on the banks.
There is also always some 75+yo part time guy that maintains some sort of critical system. He always says, "I want to retire but they keep throwing more money at me"
Otherwise, I find them to be great deliverables.
May be due to the fact you're a single datapoint and not omnipresent at every company. What a weird argument.
Doesn’t really change the point.
As of this writing, there are twenty-two comments on this thread about airtable. All but four are either you or responding to you bringing it up.
I think it’s fair to say that whatever its advantages may be, it is relatively unknown, and therefore a higher-overhead entree into programming than straight up spreadsheets.
Just learning about it or finding fit for purpose takes more time than diving into a spreadsheet. And as always the argument is not that spreadsheets are more powerful or better, but that they are much easier and more incremental to learn and start with.
No because the datagrid in MS Access is too rigid and doesn't have the extensive slice-&-dice features of MS Excel. My first consulting gig was creating customized MS Access applications. Despite that experience, I use MS Excel today because I know that MS Access is too limiting.
>No because the datagrid in MS Access is too rigid and doesn't have the extensive slice-&-dice features of MS Excel.
i'm not saying it worked or worked well, but i'm pretty sure the point of Access in the office suite was so that you could access Access (get the clever marketing?) data from within Excel and then do all the excel things you were used to.
anyone know if that worked or didn't? DDE and all those other projects were always pursuing this as a dream
Access was pretty amazing on its own back in its day, ignoring its multi-user limitations. It glued together a relational database, visual query builder, GUI/Form Builder, and reporting. You could create forms with sub forms that linked tables together. Also had a datasheet view. All of this without touching VBA code, but VBA was there when you needed it.
Does it have atomic transactions yet? That's the main thing keeping me using small databases like Access even when a mere spreadsheet would do otherwise.
The maintainability of the resulting systems was not great, but they did the job and worse is better I guess..
Kind of an open source Google Forms/ Access where you could deploy front ends very quickly and have it hit a DB
Or try Airtable.
Can we make a programming language that will save developers from that? Maybe, but that would be very hard and that's not what Apps Script is trying to do. It already allows non-idempotence, trusting developers to write idempotent code when they need to. So it could run on the client just fine.
Drive was easy enough to download everything off, but the real pain in the arse was Google Photos. I had something like 250 individual 2GB zip files and the supplementary metadata was separated off of the image files themselves. I had to put together some Python scripts to clean up all the different file naming formats over the years (PIXL_YYYYMMDD, IMG_YYYYMMDD) into just YYYYMMDDD, and reattach the metadata, and then check through that everything was safely downloaded before deleting the Google Photos.
Google Photos had some weird caching issues where it kept showing images I'd deleted and emptied from the bin, which was a little concerning. They were only appearing on my phone and persisted multiple times after clearing the cache. I couldn't find them anywhere in the phones internal storage.
The only reason I can imagine why nobody implements this, is that they like the status quo where it's hard to switch to their service, but equally hard to switch away. Once this becomes commonplace (e.g. because vendor A makes users aware it's a thing by implementing it for migrating from vendor B), vendor B will "retaliate" and A will have to truly be better than vendor B to retain said users
That is all to say, this might yet totally be a viable and legally unblockable business avenue for a third party to initiate. I'm just not sure there's enough demand to warrant (read: pay for) the effort involved. Maybe if you can have an LLM read the api docs of the service where you want to do the import and autogenerate a mostly-working version?
Even though Excel is proprietary too, it's ubiquitous enough that people don't have to worry about it.
And then, if somebody makes a change in the database, a trigger will update the spreadsheet
Such a two-way binding makes it possible to continue relying on spreadsheets for UX, all the while the data is not locked in there and we can also have other processes handling the data (a web app, some cron job, etc)
Maybe market it as an API for excel or something
See here to understand what you are missing out by not using a database: https://visualdb.com/comparison/#integrity