4 ms·

> This is an elitist software engineer's take. No it isn't. This is MY take and I'm not an elitist software engineer. > People building on Excel isn't a resul

> This is an elitist software engineer's take. No it isn't. This is MY take and I'm not an elitist software engineer. > People building on Excel isn't a result of failure to educate, it's humans doing what humans do best—automating their own workload. No, it isn't. It is human behaviour alright, but it's cutting corners because it feels better to do what you already know instead of doing what was instructed. This is what we see in businesses from 100 to 1000 people happening time after time. Example: if you need to visualise your data from multiple sources company-wide, we'd have Tableau (and training, access, templates, portals etc) for example. That means you do it there as per instruction, and you don't go trying to setup some home-brew graph in excel that you manually regenerate every day and forget to generate when you are on vacation. > It's people using general-purpose computers as general-purpose computers. It's the closest to the personal computing dream that we've come, and likely the closest we ever will. Sure, do whatever you want at home, no discussion there. But since I already specifically wrote that, I suppose we don't need to keep repeating that. > The alternative in the real world isn't "everyone learns Python", it's "we lock normal business people out of computing and keep it in the hands of the trained and very expensive software engineers". No, it's not. The alternative is follow the workflows your teams and BUs have established and don't go off on your own. It works, it's proven, it's highly effective and attracts talent as a bonus. > That's not going to happen, and it's frankly not something we should want to happen. Maybe not where you are, but it's definitely happening here. And we want it to happen because the amount of data and the types of data don't work with excel. And the way people have tried to work around it by doing sampling and then saying "but it works on my machine" when it inevitably fails is a waste of time. > I think this kind of Excel denigration comes up so often in software forums because we're usually called in to rescue a business when their Excel workflow gets completely unmanageable. Perhaps, but what I wrote isn't Excel denigration, or denigration in general, it's real world scenarios where Excel wasn't the solution and people found out too late because they didn't know any better and they thought they were doing the right thing. Heck, replace excel with spreadsheet or 'workstation-based' and you have the same issue. > We miss the decades that the company ran very successfully without any software engineers on the payroll and see the giant spaghetti mess that made them finally decide it was worth the cost. You must have forgotten mainframes along the way, that's where the actual money was made, not spreadsheets. And if you create a 'spaghetti mess', that is something you can do perfectly fine with Excel, Access or just plain pen and paper. Creating a mess is at the core of end-user deficiencies when it comes to using a spreadsheet for non-spreadsheet problems. > But it's important to remember that these same businesses reached the point where they could afford to pay us to build something custom by building a successful business on top of Excel. No, it's not. It's important to remember that older software was written to emulate the physical world, but that was also what created boundaries and limitations. Desktops, folders, spreadsheets, word processors, rolodexes, telephones, paper mail etc. are not the 'best' solution, it just happened to be what was used when software was written. The software emulated the processes that existed to make it easier to understand what it means and how to use it for the people of that era. Practically everything has evolved beyond that, to the point where you have to educate new hires on what a file and folder structure is about if you're using those at work. Just like you have to educate older people that the way they used to do things is no longer how we do it today. In some ways, Excel is the COBOL of our generation. And that is not a good thing.

deleted 2y ago
[deleted]
jimnotgym 2y ago
>Example: if you need to visualise your data from multiple sources company-wide, we'd have Tableau (and training, access, templates, portals etc) for example. That means you do it there as per instruction, and you don't go trying to setup some home-brew graph in excel that you manually regenerate every day and forget to generate when you are on vacation. Then your CFO calls up and says, 'I have a meeting in 30 minutes, can you tell me the total cost of pensions for people who work out of the Singapore office on sales admin' and the BI developer never pulled the measures through for that, because nobody asked for it before... so you export it to Excel, do an xlookup, a sumif and a filter and keep your job...or put a request into IT to have it added, wait 3 weeks, and get fired. In the real world there are measures repeated week after week, and there are many more ad-hoc requests. Your mental model of the information required to run a business is way off.
- lolinder 2y ago
  Exactly. When a process is important enough and repeated often enough, it will move into a more formal system. But most of the time spent running a business is at the fringes of what has been automated and formalized, and this isn't an accident—the automated processes are there precisely because they reduce or eliminate the human time. That means most of the humans (outside of front-line customer support or similar) tend to be working on stuff that is substantially less well-defined than what OP is imagining. Which again gets to my point about the weird perspective on business that we have as software developers. We're called in exclusively to work on those parts of the business that are deemed sufficiently repetitive to be worth automating. That dramatically skews our perception of what running the business should look like.
  - oneplane 2y ago
    That's great, but has little to do with the 'excel is my hammer, therefore everything is an excel-shaped nail' problem. Sure, like I wrote (twice already), you might need to have some malleable rows in front of you on your local workstation for some ephemeral work. But the actual workflow happens in the ERP system. Or the CRM. Or the PIM system. Or in Tableau. Or Databricks. And my beef is with people who think their personal flavour of alternate software should bypass that, even when they have been explicitly told not to. When someone needs to stream the truth (data-wise), that comes out of those systems, not some kludgy sheet on someone's network share. Those are the rules that we set up. I don't understand why this is so difficult for everyone to understand (on HN of all places). These are general staff functions we practically have entire schools for, to make people work this way.

deleted 2y ago

[deleted]

jimnotgym 2y ago

>Example: if you need to visualise your data from multiple sources company-wide, we'd have Tableau (and training, access, templates, portals etc) for example. That means you do it there as per instruction, and you don't go trying to setup some home-brew graph in excel that you manually regenerate every day and forget to generate when you are on vacation. Then your CFO calls up and says, 'I have a meeting in 30 minutes, can you tell me the total cost of pensions for people who work out of the Singapore office on sales admin' and the BI developer never pulled the measures through for that, because nobody asked for it before... so you export it to Excel, do an xlookup, a sumif and a filter and keep your job...or put a request into IT to have it added, wait 3 weeks, and get fired. In the real world there are measures repeated week after week, and there are many more ad-hoc requests. Your mental model of the information required to run a business is way off.

lolinder 2y ago
Exactly. When a process is important enough and repeated often enough, it will move into a more formal system. But most of the time spent running a business is at the fringes of what has been automated and formalized, and this isn't an accident—the automated processes are there precisely because they reduce or eliminate the human time. That means most of the humans (outside of front-line customer support or similar) tend to be working on stuff that is substantially less well-defined than what OP is imagining. Which again gets to my point about the weird perspective on business that we have as software developers. We're called in exclusively to work on those parts of the business that are deemed sufficiently repetitive to be worth automating. That dramatically skews our perception of what running the business should look like.
- oneplane 2y ago
  That's great, but has little to do with the 'excel is my hammer, therefore everything is an excel-shaped nail' problem. Sure, like I wrote (twice already), you might need to have some malleable rows in front of you on your local workstation for some ephemeral work. But the actual workflow happens in the ERP system. Or the CRM. Or the PIM system. Or in Tableau. Or Databricks. And my beef is with people who think their personal flavour of alternate software should bypass that, even when they have been explicitly told not to. When someone needs to stream the truth (data-wise), that comes out of those systems, not some kludgy sheet on someone's network share. Those are the rules that we set up. I don't understand why this is so difficult for everyone to understand (on HN of all places). These are general staff functions we practically have entire schools for, to make people work this way.