Comment by flashgordon
6 years ago
Damn It. Where are these problems today? Or is it a matter of just choosing between getting paid vs passion? As a hirer in a FANG, I feel ashamed at how much we put some of the smartest and hard-working people to work on yet-another-crud-rest-api.
All the engineering companies that aren't software engineering companies. I work for a largish civil engineering and urban planing consultancy and we deal with all kinds of hard and interesting technical problems like this all the time.
The main downside is that the software development culture in these companies are at least a decade behind the state of the art and you will have to deal with weird things like TFS 2012 and no one having heard of the phrase "Unit Test". On the upside since there is no software development culture in place, there is less argument when you tell them you're moving all your code to gitlab and want to use F#.
I work at one of those rare manufacturing companies here in the bay area(pay isn't anywhere close to what FAANG median is).We tend to use Excel for everything from manufacturing quality Pareto charts, SPC charts and its a Big mess.All I hear from Big tech enterprise tech is IoT and datalakes but no immediate solution that aggregates all this data in manner that can be consumed by various LOB Apps that can do things with the data. So I am in the process of building one right now. But You are right. FAANG along with every other unicorn is running after the NBT, wherein there is so much more to automate in well established Non-big tech(Dino tech) like P&G case below.
You can do nearly anything in Excel/Office with VBA, from automating manual processes, to BI reporting, to gluing together any and all data sources, it's just that CS type geeks hate it and refuse to learn it.
Being limited to only Office for a few months has not made me think "how horrible it is not to have real tools", but rather "how amazing is the amount of money and effort people waste on 'enterprise solutions' that are both orders of magnitude more expensive and inferior".
On the other hand I once had the enviable task of converting a spreadsheet to SQL - minus the data import, the calculations in Excel ran for hours, after the conversion the stored procedure took about 2 minutes to run.
And this was something that the business had to do daily - you can imagine how effective it was to start the calc in the morning, have it hog all your CPU for hours then get the results after lunch if you were lucky and did not have to restart the whole shebang.
Yes, Excel is brilliant at communicating with business users and getting stuff done quickly. But it does not scale and has some problems with the normal software development flow - just try to put your Excel files in version control and you'll see what I mean...
1 reply →
>> the amount of money and effort people waste on 'enterprise solutions' that are both orders of magnitude more expensive and inferior".
Let me give you another perspective: One of the reasons the Enron scandal happened was because traders for a major canadian bank,my former employer, kept the trades on their deskop Excel and audit and risk had no way of knowing the actual risk to the bank. When I was hired to build an expensive enterprise app that allowed only limited set of financial models, every single user hated it at first: it was both orders of magnitude more expensive and inferior". But the bank now has full uptothe minute knowledge of its risk exposure and the system has proven itself.
2 replies →
I agree that people waste a lot of money on solutions without really understanding the problem.
I think the solution is rarely automate with VBA - however, using Excel with a little bit of VBA can be a useful first step on prototyping what a solution could look like.
But people do waste a ton of money on enterprise solutions that are just overkill for a given problem. This usually occurs in organizations where management has no real technical background and those who do don't have any real authority.
Damn It. Where are these problems today?
They're still here. When we had to generate reports for municipalities, and ingest new data from non-tech sorts of people. What did we choose? Excel 2003 XML. Because it's what we could import easily.
I feel ashamed at how much we put some of the smartest and hard-working people to work on yet-another-crud-rest-api.
Why? Excel is inherently poorly specified and the file format support matrix is a bit… unwieldly. Interoperability is terrible, any sort of multi-user use case becomes an exercise in archaic procedures, and the various scripting languages, while powerful, are janky as fuck.
See my other answer...
Cannabis tech is where these problems are....
And i have a big network and some amazing work being developed....