If everyone thinks it's a terrible idea, why does it get used?

Sometimes I encounter phenomena that seem to be almost universally reviled, yet still seem to be put in practice. I guess the thing that started this thread was HireVue interviews, you know, the ones where you record yourself with nobody else on the other side. Pretty much everyone I asked including people with hiring authority and recruiters tell me it’s a terrible way to hire people, yet people still use it and participate in the interviews.

Other such things I have observed:

  • Buying SAS (not to maintain legacy systems but actually building new stuff)
  • Pretty much anything from Oracle
  • Tableau
  • Management consultants

I mean if these things were so great I would have thought I’d hear more positive things about them from people, other than puff pieces from the companies that are selling these things. But I don’t really. I even talked to an executive who told me how stupid management consulting was but I was like, uhhhh aren’t you an executive with the power to not hire them?

I’m pretty sure that many companies may not want to be “implicated” in endorsing a given product. And the people actually using the product don’t have sufficient “clout” to be an effective “spokesperson”. (Who cares what “Vorian Atriedes” uses and thinks about “SASacle”?)

Probably, but may not have “support” to not use them and retain upward mobility.

I don’t mind HireVue. I’ve been on both sides of it and thought it was useful. When I was on a team doing a lot of hiring, we definitely filtered out some applicants based upon how they answered those questions. Saved me some time setting up phone interviews.

SAS is a tremendously powerful and useful tool. The only people I ever hear complain about it don’t know how to use it and/or are responsible for departmental budgets and don’t like the cost. My team has actively looked at replacing SAS and there isn’t a better tool for 95% of what we do. When you add in the fantastic customer support, the value of the tool exceeds the cost.

Not everyone thinks these things are terrible. Most of the complaints I see about the things you have listed are about how companies implement them, not the product itself. It’s like complaining about the new hammer you bought when your trying to pound in a screw. It’s not a problem with the hammer.

1 Like

Some might argue that it’s too powerful.

As in, “you can do sooooo many things with this that you get lost in what you should actually do.” That is, the defaults for some of the commands aren’t useful for all situations (some are useful for general statistical work, but are terrible for insurance work). And the learning curve for these things can be fairly “long” relative to other tools (e.g., Emblem for doing GLM’s).

(sharing a nitpick!)

Or steep, if you are expected to learn it quickly (or else).

But, that is correct adjective for describing something that takes a long time (time on the X, amount learned on the Y) to learn.

1 Like

This describes Excel perfectly as well. Would you advocate for not using Excel?

1 Like

No; and I would classify Excel in the same category as being “too powerful”. It’s often misused for something for which a different tool would be far better. Furthermore, the processes within Excel are far more transparent than in SAS.

Most of what you need to design effective workbooks can be taught in one or two days. If you want to go all PowerUser, that might take some additional time; but no where near the time needed to get some of the basics down for SAS.

As you post this from a computer running Windows. You normie.

I have no idea what you mean by “more transparent”. Can you please elaborate?

Yes, it takes more time to learn to be a basic SAS programmer than it does to learn Excel. It also takes more time to learn to use a backhoe than a shovel. A more powerful tool usually requires more learning. A tool that is able to process huge amounts of data should be approached with a great deal of understanding. To be a good data programmer requires a lot of time and effort which is why they are so rare.

Fixed, cuz most people lack the desire.

See a value in the “data” and want to know how it was “created”? Click on the cell and you’ll see if it was “plopped” there (fixed value) or it was referenced from elsewhere (think VLOOKUP function) or was calculated (you’ll see the formula).

Note: I’m not considering the use of VBA in these statements.

The rest of this only supports that Excel is not on the same level of “powerful” as SAS; per the original question.

Would and have.

Creepy, Crustacean.

I think one could probably learn the basics for certain functionality of SAS in a day or two; going all PowerUser would take additional time.

I think it would be a lot quicker to learn to run a GLM in SAS than in Excel.

Generally speaking, if you’re using Excel & SAS for similar purposes, you’re using at least one of them wrong.

1 Like

So your problem with a programming language is that you can’t understand what it is doing unless you read the code? I’m not being snarky with that question. I agree that it is more convenient, in a way, to be able to see how a number is calculated in Excel because the value and the function are in the same place. I don’t consider that more transparent. An Excel file can be just as obfuscating as a program, even with VBA aside. A lot of clarity has to do with the creator and the creation process.

Another vote for SAS. I’m sure there are other tools that are just as good, but i find SAS easy to read and maintain, and it does the job.

I’m surprised Tableau is on Smoothie’s list. I’ve never used it, but everyone i know who has use it loves it, and wishes my employer would buy it.

It’s not my problem (but I understand what you’re saying here, though). We often develop solutions for business problems that require someone else to agree/approve that may not have the level of understanding of “code” that we do.

And when reviewing another’s work–especially code that may not have comments/documentation to provide intended processes–Excel is more transparent (INDIRECT aside, you can follow the data flow w/o hunting through stuff). That’s not an argument for using Excel, but it is Excel’s (sole) advantage as a tool, IMO.

But where the “problem” lays in “understanding code” is those management types that don’t want to invest time to learn/understand code and simply demand something that is “easily understood.”

FWIW, management is changing now (especially with data science on the rise as a career track); but this is where I’m getting at.

I find it easier to review SAS than a complex excel spreadsheet. But there’s really not a lot of overlap between “stuff I might do in Excel” and “stuff I might do in an actual programming language”. I mean, I guess if I need to manipulate a small quantity of data, maybe a couple thousand rows or fewer, I might do it in Excel if the rest of the process is in Excel, so as not to have to the overhead of “another software package”. And if I’m processing data in SAS anyway, I might use it to generate a triangle. But those are pretty much the only overlaps I can think of.

SAS sucks.
There, I said it.
PROC you!!

1 Like

For me it’s a matter of how complex the process is and how much data there is.

Figuring out five-plus rows of someone else’s nested “IF” statements in Excel is a nightmare. That said, if the data isn’t too monstrous you can simply add more columns and calculate several values and have a simpler “IF” statement at the end to pick the appropriate value.

In general I find Excel simpler to follow because everything is in one place, but much depends on the quality of the spreadsheet design / code.

A well-written SAS program is easier to follow than a poorly designed spreadsheet, certainly.

That’s pretty universally true, though:

A well-written A is easier to follow than a poorly written B for pretty much all values of A and B.