This is so true. People in the US just don't understand the level of economic and industrial espionage that happens in China on a daily basis. I was responding to an unrelated breach at an unnamed tech company back in mid-2000s time frame and had a side bar conversation that went like the following:
Them: "Yeah, we just opened a tech center in Xinjiang and ... wow, we've had quite the rash of lost ID badges there recently"
Me: "Have you considered that they're not 'lost', but rather 'sold' for profit?"
... silence ...
I don't know if executives are aware but just don't care, or if they're simply incompetent, but China has productized industrial espionage on a massive scale. GE Aviation was a victim more recently: https://www.cincinnati.com/story/news/2022/11/16/accused-chi...
I've watched key, core engineers and technical leaders work for US and European companies, develop their next generation products, then turn around and design and develop essentially the exact same thing for the Chinese market. They then build a company, in China, that makes essentially the same product, but for the Chinese Market, and with Chinese investors, etc.
Examples: Thoratec/Abbot Heartmate III & CH Biomedical
Auris/Verb/J&J Robotic & Digital Solutions & Renovo Surgical
The ironic thing, is that some of these companies after success in China are working to sell and be competitive in the US and Europe.
It's not even secret or under the table anymore, it's overt and largely accepted as the way it is in our industry. A brave new world.
The other factor, is that it is very very difficult for a foreign company to do business and protect their assets in China, so often the wise companies don't even try. They often just license their stuff for the Chinese market to a Chinese company. That way they at least have a chance of not having it all just stolen.
To be honest, the way you put ut, the story feels OK to me.
There are many truly bad examples, e.g. the arm china story, but engineers doing their thing is not one of them.
What alternative is there? The only protection there ever was for taking business secrets was patent enforcement, civil lawsuits or prison. If a foreign government won't cooperate on any of those things, what can you do?
The only answer humanity has ever come up with is something like a government intelligence agency, where everything is obfuscated by clearance levels and need to know compartmentalization, and any violations are handled criminally, with armies of full time counter espionage people. That just wouldn't work in the corporate world.
Just out of curiosity: can't these companies be sued by the IP holding company when they try to sell outside of China, and be forbidden to sell their products in US and Europe?
I still remember the agency I worked for getting in an industrial designer to create some beautiful cases for some iBeacon hardware we were building. They looked great.
We organise a Chinese company to do the injection moulding and are sent samples that look pretty good, so we decide to use them. Few weeks later we see OUR cases on Alibaba/Aliexpress.
The West/other countries aren't perfect either, but that's not what we're talking about here. _Everyone_ I know who has worked with Chinese manufacturing/businesses has a "they ripped us off" "they sold our hard work to someone else" "they provided lower grade x than was agreed".
And the counterarguments always come down to: "yeah but the West does X" or "you're just being racist".
Chinese companies, especially the ones that do business on Ali-X _LOVE_ this as they can get the IP and use it for $0 and then undercut the original producer of the equipment. Plenty of makers find that their designs on Tindie etc are ripped off and appear on Ali, too.
Snowden revealed, among other things, that the NSA did state espionage on Brazil's state oil company, Petrobras
https://www.nytimes.com/2013/09/09/world/americas/nsa-spied-...
https://www.theguardian.com/world/2013/sep/09/nsa-spying-bra...
https://g1.globo.com/fantastico/noticia/2013/09/nsa-document...
International relations are based on reciprocity. I sincerely think that if the US didn't think that industrial espionage would be a legitimate activity of intelligence agencies, they wouldn't practice it themselves.
Yes, agencies would be very excited for this sort of capability. Do they get it as a matter of course that easily? No. There are layers of accountability, legal authorities, and (warranted) push back from commercial entities.
https://www.nytimes.com/2017/03/03/technology/uber-greyball-...
https://www.theverge.com/2014/8/12/5994077/uber-cancellation...
See for example the case of DEAR systems, which is a cloud-based WMS that is particularly useful for intelligence as to how much (US) importers are paying for worldwide goods, and what is the cost of shipping from A to B.
It was bought by a chinese company not long ago. That's 1 example.
https://www.prnewswire.com/news-releases/cin7-acquires-dear-...
Except if you're arguing that western companies are bound by stronger ethics, in which case I'd like to see some evidence.
I wouldn't say people in the west are "better people in their hearts" but they absolutely follow more strict norms regarding honesty and theft. This is one of the main reasons why companies pay a premium for workers in the west when they could hire from other places.
One example: accounting scandals in the US are rare. I don't think anyone trusts accounting figures for public companies from India or china.
> in which case I'd like to see some evidence.
The alternative to trust is enforcement. The evidence you are looking for is the prevalence of the latter principle in systems that deal with things of value.
Though I cannot provide evidence for this offhand beyond anecdote and the corruption perception index.
As soon as they start playing along and seeing this stuff in an alarmist way, they'll turn the narrative and report on it constantly.
Since I also wear a security hat, when doing code reviews, architecture and devops stuff, it is surprising how much stuff regular developers never think about in regards to security.
Back in my day this was called "competition" and worked for the consumer, not against them. I find the espionage factor to be theatrical hogwash trotted out by the corporate types. We americans love competition, right? Stfu and compete.
> Sometimes that’s just how it is. The devops saying “Cattle, not pets” is apt here: code (and by proxy, the products built with that code) is cattle. It does a job for you, and when that job is no longer useful, the code is ready to be retired. If you treat the code like a pet for sentimental reasons, you’re working in direct opposition to the interests of the business.
A lot of code is fun to write. A lot of problems are fun to solve. But a business, especially a startup, needs to stay razor focused. My entire career is effectively to sit in meetings and tell young, passionate engineers not to build things. It’s a bit depressing, but it’s also vital.
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.
This was the single most impactful thing I learned in my early career. I was building out monitoring systems for an in-house service we hosted on site. My boss wanted to buy some small utility to keep tabs on some minor aspect of our environment. I was a bit offended -- I could have written that myself and here he was paying someone else to do it!
He asked: "How long would it take you to write and test this?" Me: "Probably a week. Maybe a bit less, maybe a bit more if I run into something tricky." Him: "Okay. This tool will cost us $500 to buy. What's your hourly pay rate for 40 hours?"
With this I achieved enlightenment. I've never again built something at work that I could buy cheaper.
This argument makes sense, but I worry that it’s a bit short-sighted. There are a lot of metrics that are hard to quantify where it might end up better: for one thing, I’ve found that integration costs and maintenance of integration of third-party systems are routinely underestimated: I’ve implemented “buy” for various systems where the work to integrate was essentially the work to build. The cost of learning a proprietary toolset rather than developing experience with open tools. The cost to the industry as a whole when something like AWS or React becomes the unreflective default choice.
I like your story of enlightenment though! I guess if you could genuinely build and maintain something cheaper, then why not.
> (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".
The only contact we had with "actual users" was over WeChat because they were on the other side of the planet.
> 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".
Uber was pathologically bad in this sense. There was no time to get details pinned down. We had a product to ship in two weeks for non-technical stakeholders. If we didn't, the stated consequence was millions of dollars in losses to the business. Throwing up your hands until you get product clarity when you know you can solve the problem as-is is a great way to find yourself with a PIP.
I had a long conversation to convince someone not to go down that path in 2006, and I am sure someone’s going to do it in 2026.
Pausing to think: I wonder how someone else solved this exact problem is such a huge part of how you grow as a developer I wish schools would focus more on it.
And you can't really conclude they made a poor implementation choice on a report of completing it successfully (albeit too successfully even, too much of Excel implemented, and then fixed by removing that (how do you do that to your XLS download link?)) on time within a short deadline.
The takeaway is supposed to be 'don't get too attached to your code', which in some circumstances (not this one) might mean 'don't succumb to NIH syndrome, use an XLS download link', but that's not the whole.
"Cattle, not pets" may be a good way to run a business, but not your life.
My idea was to take this code and spruce it up for Uber’s use case."
"My first reaction was to publish the code on Github."
I’m very surprised by this, isn’t the code property of Box, or Uber? The author does not mention their authorisation before releasing it under MIT license.
If Uber wants a few thousand lines of JavaScript from over half a decade ago that didn't originate with them and that they used for less than a month, they can send me a letter.
You can't really do this. Depends on your employment contract but code you write for an employer is usually copyright to them
... My first reaction was to publish the code on Github ...
You can't really do that either.
This reminds me of some Hindu parable about people who let go of possessions and head out to become ascetics. So there is this wealthy man and wife and the wife is all upset because her brother keeps insinuating that he’s gonna go ascetic and cut loose. The husband tells her to stop her crying and don’t worry about it, he ain’t going to do it. The wife asks him: ‘but how can you be so sure?’ Because, the husband says, this is how you do it, and then and there he rips open his shirt, tells her “you’re my mother” and heads out to the woods.
Why would you wontonly open yourself to legal liability? You say “they’re free to come after you” but you really _really_ don’t want that. Ive seen that happen to friends and the stress almost killed them.
Example: "All Intellectual Property Rights with regard to Developed Materials will be exclusively vested in and owned by the Company." (with additional data protection and confidentiality clause protecting company property)
Why am I reminded of this meme?
https://amp.knowyourmeme.com/memes/what-are-you-gonna-do-sta...
Sure, they probably won't. But they might. And if they do, you'll lose immediately. Seems like a pretty high risk no reward scenario.
---
Edit:
Since I enjoyed OP's story, I thought I should clarify a bit.
I'm speaking broadly of how I remember (from the outside) Uber's fast-and-loose IP attitudes in the 2010s.
I don't think OP did anything of a similar sort. From comments here it sounds like they used some code they built in their free time that a previous employer didn't want.
At Uber it sounds like they asked and were permitted to post their no-longer-needed code to GitHub. It's got its own GH org and everything.
This whole chain is legally risky (I wouldn't do it and would strongly advise others not to do it).
I feel OPs actions are not Ethically Wrong, though. I wouldn't enjoy living in a world where OP gets sued for this, since it sounds like nobody at work wanted the work and it's not giving competitors an advantage. I won't claim the world isn't like that, though.
I really wish I could share OP's attitude and sense of ownership. I built something really cool (entirely in my free time) for a previous employer's hackathon. That code lives on some server they own now, possibly deleted. I deleted my copy after submitting it to the hackathon because I didn't want to risk anything. Company lawyers make just building things for fun feel so risky! It takes the soul out of our work.
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.
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.
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!
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.
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.
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.
*Seven year ago at Uber
How does this help you in the browser?
They eventually built a homegrown "Excel" clone as the UI for their model because "city teams only know how to use Excel".
I would have done it the other way around - connected Excel to the data output by the model so the "city teams" could continue to use real excel. I think most finance teams do something like this.
Yeah except:
“When you click in the cells of the spreadsheet you can see the formulas. You shouldn’t be able to do that.”
“You said to make it just like Excel.”
“People working for Didi apply for intern jobs at Uber China and then exfiltrate our data. We can’t let them see the formulas or they’ll just copy what we do!”
> Unless you're familiar with iterative calculations, you probably won't want to keep any circular references intact. If you do, you can enable iterative calculations, but you need to determine how many times the formula should recalculate. When you turn on iterative calculations without changing the values for maximum iterations or maximum change, Excel stops calculating after 100 iterations, or after all values in the circular reference change by less than 0.001 between iterations, whichever comes first. However, you can control the maximum number of iterations and the amount of acceptable change.
I created a whole programming language as an intern for <defense megacorp>. It was lazily evaluated and garbage collected. Unquoted MAC addresses were valid syntax, among other application-specific oddities. No bytecode or JIT shenanigans - the interpreter just pushed and popped stuff from a stack as it traversed the parse tree, and that was fast enough for what we were doing with it. The interpreter was written in pure ANSI C, and Valgrind was very happy with it. Maybe it has been totally forgotten, or maybe it became critical to their technical infrastructure. That code never left the airgapped lab where I wrote it, so I have no way of knowing. 3 years ago, as a recent college grad, that was by far the coolest piece of "actually useful software" I had ever written. It's still high on the list. Sometimes I wonder whatever happened to it.
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.
A director asking for an exact spreadsheet to be the UI would have been par for the course, especially during the Uber China days. Heck, I personally loaded FX prices into Vertica from a spreadsheet emailed every month to the team. That process remained for more than a year as there just wasn't enough bandwidth to invert the control as automated ingestion.
Thanks for digging up these memories, @bastawhiz. I'd love to see more. :)
I worked on all this at Uber back then, and this comment warmed my heart a bit. Thank you.
I will never do that again. We didn't build a whole spreadsheet engine, but we did build a web UI that simply doesn't do as much as Excel. Excel is powerful. Sometimes it's a fine tool for the job. Our team was laid off before we could roll it out, but I remember the growing sinking feeling of "I would hate using this if I already had a bunch of habits built up in Excel"
It would have been less fun but way, way less risky to wire a headless Excel up to a javascript front-end.
I won't say there wasn't risk, but there was quite a bit of testing and a human always made the final call anyway (I never fully understood why we didn't eliminate humans from the processes altogether).
The question is, if you do some work, in your own time, on your own equipment, does your employer own it just because the employment contract says they do?
In California: if the work in any way relates to the employer's business, then yes, they own it. One way to guarantee that it relates to the employer's business is to bring it into the office and use it as part of your job. If your employer is Apple or Google or AWS or Microsoft, then probably anything you write would in some way relate to their business. Write spreadsheets by day, but games by night? All of those companies make games, or are in the games business.
I would love to hear a lawyer say, "Well, it doesn't matter what the employer does, it only matters what your job duties are, so writing games at night is fine if they don't pay you to work on games related things during they day." But I've never been told that by a lawyer, whether I paid them or otherwise.
Everywhere else in the USA: they probably own it. You could write software for washing machines, and write a video game, and if your contract says they own everything you write then they do. You signed it. There's no "but surely not!" defense.
I would expect this to be a library somewhere.
> import it to employers machines
How would you prove that you write the code long before getting hired by them?
Why anyone would run the legal risk of stealing IP from their old employer, to benefit not themselves, but to benefit their new employer... is beyond me.
> “Why can you see the formulas?”
> “You said to make it just like Excel.”
I can't keep up with the espionage story that followed but I had this conversation more than once in my professional career.
The first time I sat as a junior dev on a multi-month project replacing a excel spreadsheet for financial controlling of data centers that only one person who was going to retire understood with a web-based solution.
They were quite proud that they were going to get a "modern" solution.
Then they wanted me to make it like excel. What followed was evaluating every fricking excel JavaScript library out there at this time, going for one and started duct taping all the missing pieces.
They were pleased but the look was off. It wasn't excel. I slapped some styles on it coming quite close.
I was not prepared for what happened during the next presentation: They hated it because they wanted a modern web based solution (their words, not mine) and what they got was a poor excel knockoff running in their Internet Explorers. Tables are so 90s.
I remember the pain so vividly that I regard "just make it like excel" as some kind of forming meme for my career till today.
Not surprised he implemented a partial implementation of excel so quickly.
I'm disappointed in myself that I somehow got through most of the article without realizing who the author was (thanks Firefox reader mode); especially since the naming of Wesley and Crusher is too good. Of course it was Basta! Of course it was!
If I were hiring for an early stage startup, I know exactly which of you two I would want to hire.
> "Nothing came of it, but I took the code and shoved it into my back pocket for a rainy day."
...
> "Apparently that was a thing. I remember being only half-surprised at the time. I hadn’t considered that our threat model might include employees leaking the computations used to produce the numbers in question."
...
> "My first reaction was to publish the code on Github."
Perhaps the author feels "only half-surprised" due to their own disregard for corporate legal ownership of code. The hypocrisy is strong here.
Spoiler alert: It turns out they were fulfilling a Babylonian prophecy the whole time. The whole development cycle was a complicated sacrifice to Marduk.
The problem with porting the code to JS is that a.) nothing is named, b.) there's no real way to organize the code you've written because you're going from a spatial way of organizing code to imperative script, and c.) the actual design of the spreadsheet wasn't known to any engineers (it was designed by a data scientist, or perhaps an analyst). The work of translating would have meant really understanding what the thing is so that it can be turned into functions and modules. It also would have still required getting Excel function equivalents, since there's not a 1:1 equivalence between Excel and what's available in the JS standard lib.
The circular reference thing would have definitely thrown me for a loop though.
The solution was not to recreate Excel in the browser, but ran the Excel file with its formulas and its data plus the input parameters from end users at the backend server. Apache POI was a nice Java library that could do everything on an Excel file. Once it finished the formula calculation, I just read the cells from the Excel file to extract the result data and generated the web pages to present the data and graphs.
One nice benefit was the analysts could update their work in the Excel file, uploaded it to the server, and got the new calculation reflected on the web pages right the way.
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?
http://web.archive.org/web/20130606222859/http://thomasstree...
Inspired by that, an even smaller one: https://jsfiddle.net/ondras/hYfN3/
The latter catches circular references rather than trying to calculate the fixpoint
You can't drive Excel from Python/Rust/etc (Microsoft just announced to great fanfare that Excel can call Python--which is the wrong way around). All the editable table widgets for the web seem to suck. Nobody seems to have a TUI which you can drive from an external program.
A poorly written spreadsheet with a driveable API seems like a component that has been built multiple times by lots of people yet seems to be unavailable.
Is there some solution that I'm missing?
How do you cause users to even discover that Python app, or feed an input to it? Of course the spreadsheet software is an obvious candidate for the primary UI.
This haphazard way of running compute jobs really stuck out to me. I can't imagine doing things this way (rather than having a central compute cluster running SLURM or similar) at a company bigger than, say, a dozen people - much less the scale of Uber. What's the rationale? Even if it's just a cluster of 3 or 4 machines in a rack shoved in the corner, isn't that better than ... laptops?
The lesson of what you build for a company as something that may be thrown away is a good one.
However, I believe the only way to actually have a sacred masterpiece is to own the company and make the company's mission to build that sacred masterpiece. For example, there are definitely business opportunity for converting excel sheets to online apps that are collaborative.
The core problem is alignment between the tech investment and the company's goal.
When I was 24, I was pretty much exactly this person. "Building a spreadsheet engine that runs in a browser. Sounds like so much fun!" And then I'd slog away at it for a month and get something working.
Now though, with age, I know I can't chug away coffee working late into the night. My back hurts when I have to sit too long. My wrists aren't being too kind to me these days either.
Now if someone asked me to build Excel I'd first laugh in their face. And if I don't see them smiling, I'd ask if they can afford any of these A,B,C...Z COTS products that are doing this that we can just buy. And if none of those work out, I'd look for how I can take something like ethercalc and repurpose it for our use case.
Looks like the older I get, rather than writing code, I seem to be getting more adept at how not to write it.
Instead of doing some Excel Goal Seek or Solver or VBA macro, it's nice to let the excel "reactivity" handle it for you.
After enabling iterative calculation and manual calculation, every press of refresh runs a loop. Fun stuff.
Box had a collaborative note-taking product called Box Notes (based on Hackpad).
Slight correction: Box Notes was forked off etherpad-lite. Hackpad was a parallel fork of Etherpad.
[context: I was lead engineer on Box Notes till around 2014/2015. I left before the events @bastawhiz described]
nice read. made me nostalgic for the wild days of Uber-China hacking.
2) You stole Box code, used it at Uber, and then stole Uber code and posted it on github. I understand no one's using the code or missing that code, but you really did steal that code. It belongs to the company, not to you. I would be careful not to do that in the future, because technically that's a trade secret and people have gone to jail over that, like that programmer at Goldman Sachs (wrongfully) and ironically Levandowski who took Google code and tried to use it at Uber.
This is the story of literally every single large project I've done under a tight deadline in my career:
- Some non-technical department (usually sales) promises a customer something very big very soon, with no regard to how much time might actually be needed to build it. Fulfilling this promise "on time" is now your problem, Engineer.
- Months are spent frantically building said Thing, working overtime, burning out engineers, and bastardizing the previously clean codebase in the rush.
- The deadline is met, and no customer uses Thing for at least several months. Or the deadline is not met and customer waits for Thing as long as it takes, because they're not going to blow up a big contract or integrate with your competitor instead of waiting another month. They have too much invested and the deadline wasn't that important anyway. The third possibility, as it was in OP's case, is that Thing gets thrown away in its entirety due to some fateful turning of the organizational wheels.
I swear, almost as if by some karmic law of the cosmos, literally every frantic deadline turns out to be irrelevant in the end, and you should have saved your sanity and gone home at 5 every day for the last 6 months.
If this is life or death, then the first reflex should be to find ways to make things simpler to ship. I understand that the requester in this case was a head of finance, but sh*t, if you want something, try to compromise once in a while.
This is a great story, but at some point as an engineer in a gig-selling company, I would have asked myself if my job was really to re-build excel.
Ha! I massively identify with this. 'The market-wide median is off by £3.07' is a much harder but to crack than the 'worse' report that 'the median is twice the max and the min is null'.
https://learn.microsoft.com/en-us/sharepoint/dev/general-dev...
W
T
F
> Uber Sheets
Hee hee, this name is funny on a number of levels :)
You imagine correctly, to my knowledge. Western companies in China have to be 51% Chinese owned, on paper.
In reality, they own 100% (plus or minus diplomatic relationship issues), they just haven't asserted this right yet.
This is just my opinion: Uber could never have won in China, and Uber's management likely knew this, but the story of China was needed at the time to drive company valuation and allow the "hockey stick" dashed line of future growth to be plausible.
There are simply too many potential problems that could come up in this scenario and be the cause for catastrophic financial results in the end. And most of them wouldn't nessecarily be easily found via unit tests.
which of course leads to what some people are saying, did this have to be built? Sometimes I think our job is to optimize ourselves away.
Makes me wonder how many times this has been done haha.
This should be taught in classrooms.
Excel is the easiest way for business-oriented people to make numerical decisions, run incentive campaigns, segment riders and drivers, produce reports required by cities, counties, states, etc.
The data teams providing market intelligence to the various markets, of course, knew about servers. But they would not have the time or skill to setup something like this, and the business still had daily data needs. So the laptops it was, for a time.
The head of finance may have burned most of the opex budget and devops bandwidth on the Vertica and/or other DB service(s) they were using.
[0]https://www.forbes.com/sites/ywang/2016/09/27/ghost-drivers-...
how many people there were at that point, @bastawhiz?
y’all seriously believe that the only valid reason for an engineer or a programmer to exist is to “create *bUsiNess~ value”? i’m shaking my head.
this blog post is full of ideological blindness.
Learning how the Excel model worked and then reimplementing it would have been a better example of 'getting better at using your skills to create business value'.
However, while the ExtJS table widget had been treated by product management as pretty immutable "this is what ExtJS gives us, we can customise the colours and wording and that's it", the idea that we could customise the table widget started something amongst one of the PMs. And so we would get a constant stream of feature requests for the table widget to add stuff and enhance it and soon we were significantly more featureful than the ExtJS widget. It's still, to this day, the most featureful table widget I've seen in a web app. Everything Excel had in terms of resizing tables, sticky columns, scrolling behaviours, sorting, filtering, searching, etc., all saved in your config so it was synced across all your devices, as well as all the performance goodies like recycled rendering etc. The constant stream of feature requests meant there were dev team years invested in this table widget.
As a more mature engineer looking back, it's clear that at some point this had stopped being about customer value and more about one PM's obsession with getting excel like functionality in a in-browser reporting tool, but at the time we just kept building those features.
Now at this time, our company had acquired a sort of competitor of ours. This competitor had what was effectively the same product, but in a different market. And so the first merger of the functionality was basically to reskin both applications so they would pretend to be tabs in a unified application, and change some terminology, etc. They actually did happen to have a pretty similar tech stack to us, so some newer components were available in both applications.
But it became clear that our users were not happy with two applications pretending to be one. They wanted to know why this other market was not accessible by, say, a dropdown in the configuration, and not an entire application which worked in different parts from subtly differently to entirely differently.
So the discussion became about building a ground up unified interface for both of them. Of course, this ignited the discussion of "which table component do we use?". On the one hand, the acquired team were looking at our table, with it's fifty billion options and single handedly accounting for half the page weight of the minified JS of our application and did not want something so bloated. On the other hand, our team were looking at their table widget which was effectively "for row in data, for column in row, print td" and dreading having to rebuild all these features for product management again.
Ultimately the conflict was resolved by choosing to use an open grid that had less features than ours but more than theirs and telling the PM in question that table features were going to be prioritised much less heavily from then on unless there was a real user need for it.
