Location: San Francisco Bay Area
Remote:Yes
Willing to relocate: Yes
Technologies:
Résumé/CV: https://www.linkedin.com/in/getravi (happy to send you a pdf over email)
Email: getravi at gmail
Tech-forward finance systems / data engineer (18+ yrs) at the intersection of FP&A, data infra, and internal tooling (currently at eBay; previously Sonder, Adobe).
I build systems that replace spreadsheet-heavy workflows using Python, SQL, Snowflake/dbt/Airflow, and Anaplan.
Recently focused on applying LLMs to real workflows (financial analysis, variance commentary, lightweight agents on top of data pipelines).
Interested in applied AI / data-product roles or forward deployment. Strong bias toward practical systems and shipping end-to-end.
What are those constraints? Really usable SQL for Business people can be learnt in a day long workshop or less time. If they can do Excel, they can do SQL too.
time, focus, priorities, or just curiosity to learn. people have their reasons. Nothing against SQL btw, but very difficult to make someone learn something, especially in authority. There must be people who have done it, it's not none or all, just needs curiosity & effort to learn.
Agreed. It matches my experience as well. I boil it down to personality and orientation than seniority in the org honestly. I have seen VP/Director level people who secretly tinker in SQL alongside delegation 99% of the time. Those who want to learn SQL will do it soon and the rest have some kind of mental block.
Never knew Improv existed. There are tools that are similar to the vision of Improv. I use Anaplan at work everyday and it is exactly what a modern cloud based SaaS version of Improv would feel like. It is a multi billion dollar company and it worked because it did not go after the spreadsheet space but played along nicely with it.
The Improv article concludes "the key strategy mistake was to try to market Improv to the existing spreadsheet market. Instead, if the product were marketed to a segment where the more structured model was a ‘feature’ not a ‘bug’ would have given Lotus the time to learn and improve and refine the model to a point where it would have satisfied the larger market as well." and Anaplan seems to not have made this mistake. They have carved out a niche in the EPM (Enterprise Performance Management) market.
Improv's model was poor though, it was based on cell positions and it was easy to double-count. Basically was bad at various semantic aspects. I worked on a small conpetitor back in the day and we competed on modelling, there were a number of others too.
I've also worked on Anaplan and and its modeling is also much better, so please don't lower it to any version of Improv! It isn't, or at least wasn't a little while back, good at cross-metric ("line item" to them") calculations and presentations, but still easier to get something complex correct.
The real mistake of Improv was that it wasn't 1-2-3 so Lotus didn't know how to narket it or sell it.
We thought about that, but particularly with `GROUP BY ALL` the problem is that we would get different results from SQLite. When a column is not mentioned in the `GROUP BY` clause in SQLite it automatically pushes a `FIRST` aggregate over that column. So for example, the following query:
SELECT city, COUNT(*)
FROM customers
In SQLite is transformed into:
SELECT FIRST(city), COUNT(*)
FROM customers
In our experience this is not a good default since it is almost never what you want, and hence we did not copy this behavior and instead throw an error in this situation. However, if we were to add an implicit `GROUP BY ALL` our transformed queries would now diverge, i.e. we would transform the above query to:
SELECT city, COUNT(*)
FROM customers
GROUP BY city
Having diverging query results from SQLite on quite basic queries would confuse a lot of newcomers in DuckDB, and potentially cause silent problems when query semantics change when switching databases.
We could definitely add a flag to enable this behavior, however.
I build systems that replace spreadsheet-heavy workflows using Python, SQL, Snowflake/dbt/Airflow, and Anaplan.
Recently focused on applying LLMs to real workflows (financial analysis, variance commentary, lightweight agents on top of data pipelines).
Interested in applied AI / data-product roles or forward deployment. Strong bias toward practical systems and shipping end-to-end.
Happy to connect.
reply