I built Excel for Uber and they ditched it

It's funny there's this idea that a company _might_ be potentially injured over code they do not want or know they had being made open source by its actual author, even though many of those companies will gladly use open-source tooling without ever contributing anything back.

Perhaps more soundly, though, in California – where Uber is headquartered – IP/Copyright for code is a huge legal question that the state and federal Supreme Court has no clear answer to. Sure, you obviously can't secretly clone Uber's entire stack, slap a new company logo on it, and start up as a competitor. But if you, as an author, wrote some code for a company under an IP agreement, then no-longer worked at said company, and then later adapted and expanded upon that code (or even started over, with the knowledge of what you learned from others' work): are you, at the originator, not legally allowed to be inspired by your past work? That's not something you, me, or even the company could decide.

Like almost every spreadsheet before it: Lotus 1-2-3, Borland Quattro Pro, VP Planner ...

Spreadsheets iterating on circ references goes back to the 1980s.

The first spreadsheet application, VisiCalc, didn't track dependencies: it evaluated cells left to right, top to bottom, IIRC.

Microsoft had a product called Multiplan that competed with VisiCalc. Not sure if that did iteration.

I think it used to be a setting in some programs whether circular references are flagged as errors, or iterate. Maybe it's still that way in Excel?

This spoke to me.

However, as anyone that has looked at my code can attest, I tend to also want my code (and its functionality) to be very pretty. I'm generally writing code that I will be maintaining, so it needs to be something that I can look at, in a year, and understand.

I'm currently in the final phases of a project that I will never announce here, and don't plan on taking much credit for, but it really is da schizz. It's that way, because no one is paying for it, and no one will make money from it.

Money both spoils everything, and also makes it all happen.

> (from the above comment) - A good engineer can solve any problem with clever code. A great engineer knows what problems aren’t really problems and probably an XLS download link updated daily would have been fine.

I saw the bullet list further down the substack page and it's still not good enough for this level of requirements gathering. Those questions describe the scenario, but asking them would not have arrived at this simple solution. Checklist thinking is a crutch and just overcomplicates the problem. All the signals here were organizational and social, and not a matter of improving a process.

This should be obvious, but people who are not involved with implementation details can't answer questions about implementation details.

"Just make it like Excel" is a super low quality answer from someone who has a completely different set of objectives. The only way forward would have been to consult with someone closer to the actual users and counter-argue from there. What's missing here is the courage to recognize weak assumptions and deliberately avoid writing any code until enough details are pinned down to get to an agreement from all parties, not just say yes to the person "in charge".

I've always enjoyed this article about building a spreadsheet in 100 lines of F#: https://tomasp.net/blog/2018/write-your-own-excel/ The expansion from that to the feature set needed here is manageable.