> sometimes I wonder if most of us do the job to play with silly tools rather than actually make shit.

Yes? I thought this is common knowledge.

Here's a universal tool whose potential is limited only by one's imagination, and yet most of the jobs in our profession are at best boring - the high-paying ones usually involve making actively harmful things that shouldn't exist in the first place (see e.g. whole adtech for starters), and most of the rest are so mired in office politics or business constraints that the outcomes are guaranteed to be shit. A lot of strangeness in the dev culture can be viewed as coping mechanisms.

Meanwhile, after doing this work long enough, you end up realizing that disturbingly many SaaS tools offer much less utility and worse ergonomics than an Excel spreadsheet.

Often I can do what I need in a few minutes in excel where à programmer would take hours and not give me what I actually asked for. And in excel I can modify and update my work. Where a programme solution is static and needs tons more hours for every change needed.

Often we see people claiming that "This new thing is the spreadsheet killer, like ai at the moment. People have been saying this forever but spreadsheets are still here. And there's a good reason for it.

There are only two things I've seen that ever came close to actual "spreadsheet killers" - MS Access and computational notebooks (Jupyter, Observable webapp). And it so happens that both are very similar in principle to Excel spreadsheets. They're optimized for certain paradigm (reactive cells, RDBMS CRUD, reactive cells accepting code and outputting rich content), but otherwise don't constrain you - instead, they invite you to build your thing incrementally, figuring your problem out as you build the solution, with full visibility into intermediate states.

The only way AI has a chance of killing spreadsheets is if it replaces a Real Programmers, by becoming a tool that lets anyone interactively build arbitrary apps, for free (on the margin), with near zero turnaround.

> Often I can do what I need in a few minutes in excel where à programmer would take hours and not give me what I actually asked for

That's likely not down to the tool, more likely a complex requirement you understand but they don't. (And are you sure you're getting the right answer? IIRC an analysis showed 10% of spreadsheets have errors - devs do care about good results, and that does take extra time)

> Where a programme solution is static and needs tons more hours for every change needed.

Hmm. Sounds like there's something wrong here, with your guys or some aspect of the business (and sure, excel is not a bad tool, just to be clear).

Economics. The scarcity of devs always leads to rationing and its related sources of friction. From the "requestor" standpoint, friction could dominate the cost of getting things done.

What I think more people should appreciate is that in any business process, computer or otherwise, there's a speed/generality/correctness/accountability tradeoff.

AI sits at the "speed" corner. Excel, a fully dynamic interactive programming language with one type "cell", gives slightly better correctness and accountability. Coalescing process into program continues to move you to the other end. Once you start employing typechecking and later formal verification, you get more correctness and accountability - BUT at a cost of development time, AND generality. The correctness is achieved precisely by being tailored to the specifics and rejecting the general.

This can apply to entirely physical processes. Some "aerospace" grade parts are very similar to normal parts .. but with a huge overhead of accountability. Because getting the right outcome matters.

This is huge. Programmers and programming are not the problem. the process is. For a wide variety of uses, the cost of programming erases the value added.

No. Most of us work to deliver

> Here's a universal tool whose potential is limited only by one's imagination

And it crashing, and it being limited in capacity, and not being as flexible as SQL (in areas SQL is good at). It's not a universal tool, good as it is.

By universal tool I meant a general-purpose computer equipped with tools letting you program it.

> No. Most of us work to deliver

I mean, yes, of course - but "playing with silly tools" is one of many methods of delivering without losing your mind in the process.

I work to earn money, I work to feel useful, I work for the challenge, etc. I do not really work to deliver adtech or LoB features. That's just a (un?)fortunate byproduct of the process.

There's a very "bikeshedding" property at work where the fewer "real" consequences come from a decision, the more heated the discussion gets because it's purely opinionated.

(there are also a number of HN commentators who are reliably noisily wrong about things, but not in such a blatant way that they get obliterated in downvotes, and one of them started that top level thread)

See pineapple on pizza. It's fun to discuss precisely because of how trivial it is, not despite it.

We should create an internal tool that relies on a framework which needs quarterly code changing updates for a yearly(?) administrative process with less than 24 candidates?

IMO the arguments people make in frontend are similar to the infinite scaling requirements in back end that require 10X overpriced machine rental.

Whether or not the current site could ever be appropriate for all 10 billion users, a developer wants the universal skills tuned to the top end.

A university HR employee OTOH probably realizes they won't code themselves if they end up at the largest employer on Earth.

As in religion, it's the minor differences that lead to major wars.

Major differences let you say "well that's just what THOSE people do". It's not a threat to your sense of self.

Minor differences challenge your own sense of self, and thus must be destroyed.

Hey, it’s not just playing with the silly tools. It’s showing how smart I am by displaying my arcane knowledge of the silly tool.

Excel is superb for automating/number crunching short lived business processes or those that are one offs or change rapidly. Especially if you don't have technical resources available to do it any other way.

The biggest issue they had was not understanding that the data from one area (Wales) was in a different format from the others - an integer that represented rank (lowest being best) rather than a test score - that would probably still not been noticed if they'd used something else.