Best quote: "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!”
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.
Everyone should've seen what happened to Cisco and thought better, but short sighted execs focused only on next quarter gladly opened the gates and accepted the horse.
>it's overt and largely accepted as the way it is in our industry. A brave new world.
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.
> some of these companies after success in China are working to sell and be competitive in the US and Europe.
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?
If we're being generous, the author may have had permission to do so. It's not inconceivable; the code was abandoned. If one of my reports had asked, I would have approved.
Actually that was the first thing I looked for in the comments, even before finishing the article and seeing he even published the finished code on his own repo (and not box or uber one), under his only name.
Indeed. Having warned against "If you treat the code like a pet for sentimental reasons, you’re working in direct opposition to the interests of the business." He does exactly that.
Yup, the Chinese government doesn't really care about infringement unless the IP is Chinese itself and being infringed upon by non-Chinese companies.
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.
Well, not just corporate espionage, right? State espionage is going to be at every large US company too. To speak to the article, I can only imagine how excited an agency would be to get real-time updates on the Uber movements of a target.
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.
Two things. First, this isn't the same thing; you're talking about embedding a resource in a company to read out real time telemetry from internal systems (information with a short shelf life), not stealing industrial trade secrets (information with a very long shelf life). Second, I can assure you that, even with our imperfect systems, there is actually a set of checks and balances in place to prevent rampant (note I said rampant) abuse of this kind.
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.
Given Uber's efforts on Greyballing, booking fake Lyft rides, hiring Anthony Levandowski etc etc ... it's very on-brand for them to (1) fall into an espionage war with Didi (wonder where all their Vertica data came from?) and (2) have an engineer write about using code he lifted from a prior gig and then also self-published.
Its not only that, but when they can't beat them...they make them join: startups with valuable market intelligence get bought all the time by Chinese companies.
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.
They don't understand it, because what you're quoting as a behavior is pretty standard anywhere in the world. That's why companies protect their secrets from low rank employees.
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.
If a low ranking employee in Cincinnati divulged corporate trade secrets, they'd be tried and convicted. If a low ranking employee in Shanghai did the same, what can the US company do? Not much. So it's a low risk activity, that is also actively encouraged and in many cases financed by the Chinese government. This is in no way intended to be disparaging of folks who are of Chinese descent, but rather a reflection of the reality of contemporary Chinese government politics and policies.
And I was called a racist 25 years ago when I said, “like, our engineering school is, like, crawling with Chinese nationals.” We said like a lot on the 90s.
We're headed for a very protectionist and isolated world because some players couldn't play nice. To me, the only thing holding the floodgates in the west back is the media which is very "rainbows and butterflies" about everything.
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.
That’s because you were being a racist. Most people reserve the word “crawling” for insects and other small pests. Only racists apply it to an entire set of people.
Similar reports were widespread 20+ years ago, when I worked in aerospace. Bad faith partnerships, industrial espionage, and companies barred from competing after all useful information was extracted. It has gone on for decades and nobody will do anything about it. Executives and shareholders get dollar signs in their eyes over the thought of tapping into the Chinese market, and let themselves get burned over and over again.
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.
> People in the US just don't understand the level of economic and industrial espionage that happens in China on a daily basis.
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.
You're missing a huge part of this: The "competition" you think you're referring to had, you know, actual rules. Sending people to get jobs at a rival, and steal all of their internal documents and trade secrets, is illegal in most countries.
What it would do is punish companies that do real R&D, and reward companies that have no actual talent in that area. So ultimately the field would stagnate because no one would invest in R&D.
I'm a bit confused what that would look like. Sending Americans to China to steal their secrets wouldn't work because the Chinese wouldn't hire them for exactly this reason.
I read this article looking forward to the complex bespoke code to be ripped out and deleted - but the author clearly grew as an engineer in a way I didn’t expect:
> 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.
> 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.
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 tool will cost us $500 to buy. What's your hourly pay rate for 40 hours
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.
> (from the article) - Having Excel in the browser was a useful solution, but the problem wasn’t showing spreadsheets in the browser: the problem was getting a specific UI delivered to the right users quickly.
> (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".
> "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.
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.
Exactly, in 2016 there was several off the shelf options for doing the exact same thing. It’s a perfect example of a young engineer feeling a huge accomplishment from reinventing the wheel, and then realizing the clever solution wasn’t actually worth anything like the effort required to create it.
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.
I would say what you talk about is experience. To have an experience, you must go this path to realize what to not do. It feels like a catch 22 kind of thing.
I'm not really sure what you're saying, or what the criticism is, if it is one - but shortly before the bit you quoted OP links the code on GitHub: https://github.com/WebSheets;
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.
Any time I identify a fun and novel problem I get suspicious. Generally, programming should be mundane and you should be solving problems that have been solved thousands of times before. If something looks new it's more likely you haven't correctly identified the problem you're solving.
Short term yes, but long term, life's too short. Pursue FI, especially if you're a craftsman, so you can work on what brings you joy, without an expiration date.
"Cattle, not pets" may be a good way to run a business, but not your life.
A great engineer should be both good and great. I do a lot of ‘great’ stuff at work, but that won’t help me to get into my next gig unless I also code a lot and don’t lose my skill.
"Nothing came of it, but I took the code and shoved it into my back pocket for a rainy day.
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.
Author here. The code was originally written outside of work hours. I offered the code to Box and they didn't want it.
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.
So come on man, let’s be honest here. I got serious sacred masterpiece vibes from this story.
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.
That’s really not how it works. Ostensibly by showing it to box, it was written for box, and they would be well within a standard of legal standing to make your life a living hell for taking it elsewhere. You should really be more careful with what you say.
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.
Depends on the contract but the most I seen stipulate not working hour but context of the work. If it was made by instructions of the company for the company and you got remunerated for that then it is not yours to do whatever you please with it. Better check your contract in details.
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)
Sergey Aleynikov (born 1970) is a former Goldman Sachs computer programmer. Between 2009 and 2016, he was prosecuted by NY Federal and State jurisdictions for the same conduct of allegedly copying proprietary computer source code from his employer, Goldman Sachs, before joining a competing firm.
Oh, you’re missing a few qualifiers. They’re not concerned with laws applied to them, and other people’s property. But in all other cases they’re big believers in law and using it to protect their property.
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.
> 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.
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.
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.
> Over the summer of 2016, we came up against a new twist on the project. We had a model that ran overnight to generate data for anticipated ridership in China. That data wasn’t useful on its own, but if you fed it into a tab on a special Excel spreadsheet, you’d get a little interactive Excel tool for choosing driver incentives. Our job was to take that spreadsheet and make it available as the interface for this model’s data.
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.
Because the city teams were in China, we didn't have this luxury. Everything had to be behind Uber's beyondcorp equivalent, and there was no real way to auth folks from the Chinese mainland. Our only surface was the browser.
> 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.
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!”
I’m building a solution that works like this - we directly connect spreadsheet models to company databases (even converting pivots/formulas to SQL). Would love to chat with anyone that might find this valuable: https://arcwise.app
> 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 wonder if the author would view this situation differently had Uber/Box decided to claim the code as their own. It has to bring some catharsis to know that, even if the code never actually met its potential, at least the whole world can see and appreciate it.
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.
The part the author is missing is that Box and Uber have already claimed the code as their own. It will be in the employment contract. The author appears to be under the impression that asking a mid-level manager (or even a senior manager) "Hey, do you want this?" and that manager answering "No", is in any way legally binding on the company.
I've only ever agreed to those terms kicking and screaming. I wish there was a larger part of the community willing to advocate for a "love of the art" clause that would explicitly state that code I wrote on my own time is mine.
> It’s easy to treat a particularly clever or elegant piece of code as a masterpiece. It might very well be a beautiful trinket! But we engineers are not in the business of beautiful trinkets, we’re in the business of outcomes.
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.
Readit News
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?
Dead Comment
Dead Comment
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.
Deleted Comment
Deleted Comment
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.
Dead Comment
Deleted Comment
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.
Deleted Comment
Deleted Comment
Dead Comment
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.
Dead Comment
> 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.
Deleted Comment
"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...
https://en.m.wikipedia.org/wiki/Sergey_Aleynikov
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.
Deleted Comment
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!
https://poi.apache.org/components/spreadsheet/formula.html
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.