> He simply couldn’t believe that I’d written a full spreadsheet engine that ran in the browser.
I can't believe it either, and I don't mean this in a good way.
Apache POI lets you run headless Excel. You import and interact with sheets programmatically in Java. We used this in my old workplace for exactly the same reason (functions, cell references, the whole thing), it worked great.
You found the ‘circ’ problem with a bit of luck. What about all of the other hidden little quirks of Excel that you would ultimately run into down the road? Are you really going to build and maintain a full blown Excel clone in JS? Is this really the objective of the frontend team?
It seems to me like a bit of googling and >90% of the work here could have been avoided. As an added bonus it would have been done by the backend team instead.
> It seems to me like a bit of googling and >90% of the work here could have been avoided.
I had a deadline and the only idea on the team for shipping a working product, and I shipped a working product on time.
Uber ran (runs?) their own data center. Getting a Windows machine/VM procured to actually run Excel would have taken an act of god. I was able to spin up a new front-end service in about thirty minutes. And I had some code that sort of kind of already worked, so I wasn't starting from scratch. Keep in mind that this system needed to be used by multiple people with different sets of data simultaneously.
> Are you really going to build and maintain a full blown Excel clone in JS? Is this really the objective of the frontend team?
If they'd have kept asking for more features and Excel parity, I suppose we would have considered it. But they didn't.
Certainly I don't expect many people would have chosen to do what I did. But the thing worked (and surprisingly well). If all you took away from the post is that it was a big complicated project, I'm afraid my writing has failed to convey the message it was attempting to convey.
A little over ten years ago I worked in the Excel Services team that makes the consumer-visible Excel Web App and also the SharePoint-integrated Excel Services product (server side processing accessible via API or web UI).
I loved seeing the genuine joy our PMs had whenever they found an honest to goodness calc bug and could get it reproduced and fixed in The State Machine. It was also a delight to see the web app approach parity with the desktop client experience -- we got to listen to a wide swath of users and build out the stuff we thought would be most useful to the most folks. And I loved our group PM's insight about what the heck Excel could be good for versus purpose built BI tools, other web sheet apps, pure SQL, etc.
This is a very fun kind of product to create and it's awesome that you were able to ship it in a way people could use!
To be fair, he wrote a spreadsheet engine that could run one particular spreadsheet. Admittedly a complex one, but it was a fixed set of functions that he needed to implement and not and endless tail of things that people expect Excel to do. I think I'd probably have argued more about the UI spec and down some Excel behind the scenes but it is a familiar UI if you've got lots of number inputs all over the place.
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.
Project requirements are never fixed, they’re always evolving.
It was only a matter of time before users would’ve complained about features being missing/broken, especially since what they’re used to is Excel and this was meant to replace it.
> "The city teams only know how to use Excel, just make it like Excel."
With those expectations, sooner or later someone would have said "hey wait a minute, why isn't this like Excel? Excel knows how to do X, but this can't do X! I thought we talked about this, just make it like Excel!", repeat until you have a full blown Excel.
I think one of the biggest growth areas for junior engineers to reach mid-level and senior is recognizing when you're re-inventing the wheel. E.g. If you are given a programming task to do anything related to Excel or the Microsoft Office suite, it's worth googling it first, because some engineer somewhere was probably tasked with doing the same thing a decade ago and has written a blog post or made a GitHub repo for it.
It's not just junior engineers. Senior/management can fall into this trap as well.
At one of my former companies we had a small problem with whitelisting cloudflare IP's that don't typically change super duper often but definitely cannot be assumed to be static. My boss at that time decided the solution was this big initiative he called "whitelist maker" and assigned it to me. I don't remember what implementation details he wanted, but it was some insane rube-goldberg machine to basically pull down this list: https://www.cloudflare.com/ips-v4 and then put it into some terraform code.
I ended up quietly killing the project during a re-org and used the cloudflare provider, which conveniently provides the forementioned IPv4 list as a data source in 1 line of code. Done, 5 mins work. He had scheduled out an entire quarter and half of a team's resources for it.
That's true, it's misleading to say this is a mistake only junior engineers make. Perhaps the real lesson is in having the maturity to put your ego aside and reflect clearly on whether you are solving the right problem in a sustainable way before jumping into the how.
As a generalist sysadmin sometimes I wonder wtf is in the future for me but at least I can say I made sure our data guys have a really good compute node instead of a crashy laptop cluster and dollar store excel. Are you guys REALLY sure about the no-ops dream?
You make a small small backend-for-frontend that translates requests from the browser to calls to the Apache POI library and return the information to the browser, probably as some kind of json representation.
I can't believe it either, and I don't mean this in a good way.
Apache POI lets you run headless Excel. You import and interact with sheets programmatically in Java. We used this in my old workplace for exactly the same reason (functions, cell references, the whole thing), it worked great.
You found the ‘circ’ problem with a bit of luck. What about all of the other hidden little quirks of Excel that you would ultimately run into down the road? Are you really going to build and maintain a full blown Excel clone in JS? Is this really the objective of the frontend team?
It seems to me like a bit of googling and >90% of the work here could have been avoided. As an added bonus it would have been done by the backend team instead.