Right. Spreadsheeds already delivered on their promise (and then some) decades ago, and the irony is, many people - especially software engineers - still don't see it.

> Before spreadsheets you had to beg for months for the IT department to pick your request, and then you'd have to wait a quarter or two for them to implement a buggy version of your idea. After spreadsheets, you can hack together a buggy version of your idea yourself over a weekend.

That is still the refrain of corporate IT. I see plenty of comments both here and on wider social media, showing that many in our field still just don't get why people resort to building Excel sheets instead of learning to code / asking your software department to make a tool for you.

I guess those who do get it end up working on SaaS products targeting the "shadow IT" market :).

▲

ben_w 18 hours ago | parent | next [-]

>> Before spreadsheets you had to beg for months for the IT department to pick your request, and then you'd have to wait a quarter or two for them to implement a buggy version of your idea. After spreadsheets, you can hack together a buggy version of your idea yourself over a weekend.

> That is still the refrain of corporate IT. I see plenty of comments both here and on wider social media, showing that many in our field still just don't get why people resort to building Excel sheets instead of learning to code / asking your software department to make a tool for you.

In retrospect, this is also a great description of why two of my employers ran low on investors' interest.

▲

rwmj 16 hours ago | parent | prev [-]

Software engineers definitely do understand that spreadsheets are widely used and useful. It's just that we also see the awful downsides of them - like no version control, being proprietary, and having to type obscure incantations into tiny cells - and realise that actual coding is just better.

To bring this back on topic, software engineers see AI being a better search tool or a code suggestion tool on the one hand, but also having downsides (hallucinating, used by people to generate large amounts of slop that humans then have to sift through).

▲

TeMPOraL 16 hours ago | parent [-]

> It's just that we also see the awful downsides of them - like no version control, being proprietary, and having to type obscure incantations into tiny cells

Right. But this also tends to make us forget sometimes that those things aren't always a big deal. It's the distinction between solving an immediate problem vs. building a proper solution.

(That such one-off solution tends to become a permanent fixture in an organization - or household - is unfortunately an unsolved problem of human coordination.)

> and realise that actual coding is just better.

It is, if you already know how to do it. But then we overcompensate in the opposite direction, and suddenly 90% of the "actual coding" turns into dealing with build tools and platform bullshit, at which point some of us (like myself) look back at spreadsheets in envy, or start using LLMs to solve sub-problems directly.

It's actually unfortunate, IMO, that LLMs are so over-trained on React and all kinds of modern webshit - this makes them almost unable to give you simple solutions for anything involving web, unless you specifically prompt them to go full vanilla and KISS.

▲

rwmj 15 hours ago | parent | next [-]

I'm constantly surprised that no one has mainstreamed version control. I see so many cases where it could be applied: document creation and editing, web site updates, spreadsheets ... even the way that laws are amended in Parliament [1]

[1] https://www.gov.uk/guidance/legislative-process-taking-a-bil... https://www.gov.uk/government/publications/amending-bills-st...

▲

gedy 11 hours ago | parent | prev [-]

> But this also tends to make us forget sometimes that those things aren't always a big deal. It's the distinction between solving an immediate problem vs. building a proper solution.

I agree about the "code quality" not being a huge issue for some use cases, however having worked at places with entrenched spreadsheet workflows (like currently), I think that non engineers still need help seeing they don't need a faster horse - e.g. automate this task away. Many, many times a "spreadsheet" is ironically used for a very inefficient manual task.

	▲	TeMPOraL 8 hours ago \| parent [-]
		> Many, many times a "spreadsheet" is ironically used for a very inefficient manual task. Right. But spreadsheets and "shadow IT" aren't really about technology - they're about autonomy, about how the organization is structured internally. No one is choosing a bad process from the start - spreadsheets are the easiest (and often the only possible) way to solve an immediate problem, and even as they turn into IT horror stories, there usually is no point at which the people using it could make things better on their own. The "quality solutions", conversely, are usually top-down and don't give users much control over the process - instead of adoption, this just breeds resistance.