Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • I don't really agree, moreover I haven't had the same experience at all.

    I find engineers almost never using spreadsheets, ever for clearly tabular data. My coworkers certainly never use nested-ifs. Many times they will put a crappy table into jira instead, which multiple team members will be overwriting each other's work.

  • While putting formulas in cells is confusing a single use script somewhere on the file system is also terrible and looking at it isn't all that obvious what is going on either. If you put everything in a db you need the ancient art of SQL Kung Fu. Great if you can, to bad if you can't. I like joins, it instantly confused the hell out of the uninitiated. You can make the query complicated enough that even a seasoned champion needs a warm up before lifting.

    I remember my first thought looking at excel. They force name and number everything which is exactly like using single letter variables, they are only allowed for simple things. Using row numbers is even worse. Each additional col of numbers makes it harder to find things and it invites mistakes.

    I'm not complaining, each solution survived because it has great advantages. JSON and XML have their place too ofc.

    My gut says that after learning the advantages and disadvantages we should be able to make something better.

    I put CSVs in html documents, use JS, run from the file system, output is CSV usually. I haven't tested the limit of html files but if you put a comment at the bottom the rendering engine ignores it efficiently.

    One more bad solution for your collection.

    by econ
  • I don't use spreadsheets much myself. But I'm not against them as a means of interfacing with non technical people used to using them.

    And I have used them as an alternative to a UI with very poor UX that developers came up with for a team of material scientists to use. This thing was basically unusable. Sometimes, it's just easier to go where the users are rather than to try to get them to use something new or different. These people were dealing with a lot of specifications in PDF form. Loads of tables basically. So, spreadsheets were a good fit as that was what they were doing anyway. They loved it. Soon after they discovered databases, python and sql. So there is that.

    The reason spreadsheets are widely used is because nothing better really came along that did the same job for everyone. There were of course lots of tools for specific use cases that are somewhat widely used now. But most of these tools are fairly niche compared to spreadsheets.

    These days getting data in and out of spreadsheets is not that big of a deal with AI coding tools. A lot of white collar workers are starting to use those. So, switching to something better/appropriate is much less of a challenge now than it used to be.

  • Coders get a little sniffy about Excel sometimes, but it's so good at achieving 80%-ness across multiple axes that I can't see it being displaced.

    - the lowest barrier to entry for pretty much anyone in corporate life. Boot PC, there it is.

    - rapid data exploration. Just put something in a cell. Play around.

    - extensive self-, community-, pro-, and AI help.

    - an impressively powerful programming engine. Well, two really, one of which survives after 30 years and multiple murder attempts by Microsoft. You can build complete applications, UIs, database front ends, etc.

    - serious tooling for power users via toolpaks and plugins

    - just enough tooling to add visual polish to outputs.

    Excel isnt the best at many things (I still pine for Improv, tbh) but it's good enough at a lot of things for that not to matter, and its so easy to get started, the allure is hard to ignore.

    Gsheets comes close, but still (to my mind) smells amateurish for power users. Maybe that's my problem rather than Google's.

  • As a spreadsheet user first, this just reads as programmer prefers programming.

    Many times the spreadsheet is a collaborative document. One way to use spreadsheets is you use it for a number of iterations, get your outcome quickly, let stakeholders give feedback and adjust the approach. Then once it becomes stable, then you turn it into a database/app/script. Errors in spreadsheets are obvious to more users than errors in code because your work is shown, not hidden.

    Taking a csv file and writing bash is not the answer. If you are doing that, you should probably get back to work/research.

  • Reviewing the individual formulas in an excel report is psychotic. Normally what I would do when checking someone elses work for errors is spot check a couple of the values in a column and calculate them by hand to see if they matched up. Either that or just implement the step myself in excel and see if I got the same output.

    That's a lot like reviewing someone's regular expression. Like I'm not going to read through a 100 character regex to see if it matches semantic versions, I'm just gonna pull it up on a regular expression tester and see if it does what it should.

  • The humble spreadsheet is the most robust data analysis tool of our lifetime and the two exceptions provided by the author (fit-on-screen data, temp storage) ignores a variety of uses that several comments itt reference.

    The key value IMO - as other have said - is that it's sharable to non-technical folks.

  • You can do horrifying and amazing things with Excel. Samsung’s Austin fab, at least circa 2020-ish, was generating machine labels with it. These are paper cards, roughly 2” x 4”, which carry the following information:

    * Machine name / number

    * Owning technician’s name, shift, photo, and phone number

    * Owning engineer’s name, shift, photo, and phone number

    My team had something like 250 machines spread across 4 shifts. We had to redo cards anytime we gained or lost someone on any team, which often included rebalancing the workload. Luckily, someone had made an Excel macro that connected to a MSSQL DB that had employee information (IIRC, it didn’t have confidential information like pay in it; I think it was used for generating badges), pulled all of the required fields, and automatically filled the template. Send them to the printer, cut them apart, and go place them.

    My contribution while there was to implement a crude pathing optimization that tried to assign contiguous machines to a given technician, to minimize the amount they had to walk for weekly checks. It kinda worked; better than nothing, anyway.

Explore Birbla archives