I reflexively swiped left when the inevitable newsletter modal started to appear at the bottom, so didn’t finish reading the article, but would like to know what gave you the dystopian vibe?
Spoiler alert: It turns out they were fulfilling a Babylonian prophecy the whole time. The whole development cycle was a complicated sacrifice to Marduk.
That's because everyone in this comment section is giving wisdom about how to deal with the emotional reality of being abstracted from the fruits of their own labor. "Don't get attached to your work" is dystopian.
Some of us will strategically write generic code on our own time and machines and import it to employers machines when needed and customize it. For instance, how many times do you really need to write a spring OAuth server that integrates with LDAP? Or the guts of a simple CRUD app?
Software written off the clock that does not compete with the employer is not only not the property of the employer, but any contract attempting to gain such ownership is unenforceable.
Many businesses even actively encourage their developers to contribute to open source projects.
> any contract attempting to gain such ownership is unenforceable
I highly doubt that this is true, at least in the US. Can you cite case law?
You can write a contract granting ownership of all the songs a musician performs, or all the books a writer writes during a specified time period. Why shouldn't the same be true of programmers and code?
Many programmers sign this. I directly know that at least two FAANG employers (and probably all of them), have extremely broad copyright assignment clauses in their employment agreements that claim ownership of every software you create, on or off the clock, using company equipment or your own equipment. And many people work for these companies.
Whether these are enforceable or not doesn't matter because a lone developer is not going to go up against an army of corporate lawyers to find out.
It's a work of art. Even this comment is a violation of the agreement, since I don't own the copyright to anything I do apparently, either in or out of the scope of my employment, so therefore I can't give Y Combinator a license to display this comment.
I even talked to the company's legal team about the absurdity of the agreement & they were unwilling to budge.
Completely false. Most people sign job contracts without thinking too hard. And side projects just aren’t important for the majority of programmers, so why would they care?
This is an even stronger case than anything being discussed in this thread. Oracle claimed to own code written by their own employees on their clock and still lost this case. Google won their claim of fair use.
That's exactly and explicitly what an MIT licensed open source project would fall under: fair use by the employer and nobody owns it despite the original author also happening to work for said employer. Authorship is distinct from ownership. As well, there's the notion of role vs identity. You can act under the role of an employee to fork a public repo for your employer's purposes, yet act under the role of the upstream author to have published something more generic in the past without knowledge of your employer's future use case. Your identity is irrelevant. The only thing that really matters is that the public repo does not contain code proprietary to any business. It's on the employer claiming the code is proprietary to prove it. Examples from the article would be those data science functions, the UI they wanted, etc.
Do people not realize why these licenses exist in the first place? What do you all think they were doing over there at MIT to draft up such a license?
This has nothing to do with what we’re talking about. Whether Oracle owns the copyright to that code is independent of whether Google’s use of it qualifies as fair use.
In Oracle v. Google, not even actual ownership impeded fair use. Nobody really owns the code on a public repo, so there's your answer to #1. The employee can use the code they authored and published to the world without any issues.
Now for question 2...
> what we’re talking about
What you're talking about.
You're correct that Oracle v. Google does not give any clear answers on ownership. For that you have to rely on the license applied to the project. It's simple. If you publish a project under a permissive license and your project does not contain anything proprietary, nobody owns it. Employment contracts don't have anything to do with this situation.
But, what does it really mean to "own" code? What is owned? The concept or the literal sequence of chars? It seems to be the latter which Google showed is trivially sidestepped by rewriting the code behind an API. Thus ownership is pointless in software unless it's closed source and proprietary, which is the opposite of a fun little Excel clone, amateur video game, etc.
The only thing enforceable about an employment contract is the clause about terminating an employee for working on side projects on the company time and/or with company property such that it takes away from productivity towards their work. I don't think anyone is talking about that or would even think of doing that though.
Your employment agreement or contract likely has some clause saying you transfer ownership, rights, etc to the organization.
Which likely means your "free time" code you decided to do to make your job easier now belongs to your employer since they asked you to write it (albeit indirectly in this situation).
Will anything come of it for trivial stuff? Probably not, but that doesn't mean it's ok.
Unless you have something in writing saying otherwise, best not to mix stuff like this because one day you might wind up on the wrong side of an army of lawyers.
> Which likely means your "free time" code you decided to do to make your job easier now belongs to your employer since they asked you to write it (albeit indirectly in this situation).
Especially when you have problem A at work, then some time later write "generic code" that solves problem A, then some time later "import" the code to your dayjob to solve problem A. And double so if nobody else ever uses this generic code and you never use it for anything else.
As an industry we talk a lot about flexibility, particularly in scheduling and when we do our work, but you can't have it both ways. You can't be doing laundry and mowing the lawn and going grocery shopping in the middle of the work day because it helps you think or it helps your programming process, but then make the argument that because you wrote this code at 6 PM on a Sunday it's yours and not your employers, when you committed it to your employer's git repo Monday morning. Not with a straight face, at least.
I want to be clear, I'm all about getting shit done during the day. If I need to get a haircut at 2:30 PM, I will. But I'm also not pretending that my employer's code is mine or that I have any right to publish it.
Ethically, I'm not sure how to slice it. I'm operating on what you wrote here rather than this specific story.
Some contracts stipulate that anything you write while employed is owned by your employer. (I'm settled in that this is unethical, but it's reasonable to comply.)
But let's suppose there's no such stipulation.
You get an idea while at work. Everyone gets ideas. You take your brain home with you (I hope) and start developing that idea. You think it's generally useful and doesn't depend on any or reveal anything about a trade secret or other proprietary work, nor reveal anything about them.
Is it your choice to contribute that idea to your employer or to use it in an open source or some other unassociated project? Why or why not?
Is it OK if you never use it for any of your employer's projects?
If not, then is it OK to wait until after your employment to develop that idea on your own or for your next employer or even turn it into your really awesome startup that definitely won't fail? (I think all of you are willing to do the first, and most of you the second.) Why does that change the ethical quandary, or why doesn't it?
Alright, so your employer specifically asked for this solution and you wrote one on the clock but it was minimal, maybe you didn't have enough time to make a more elaborated one, and you write a better one and did one of the above with it. Is that OK?
I don't think this question is all that cut and dried.
There would be a difference between you publishing your code to a public repository, under a permissive license and then allowing your company to fork the codebase and do whatever with it. Under this situation, the author retains copyright, and the company has the option to decline use of the licensed code.
That is different than solving common business problems at home, then when asked to solve them at work just copy/pasting those solutions and assuming you retain rights. Contributing that to your employer under that situation is no different than just working on salary - and you have not given the employer the option of rejecting those contributions.
See, that requires some argument of who it's for. Legally, copyright is established the moment something is created. (Hope you have proof.) I don't think you'd be able to claim _damages_ by sneaking your copyrighted code into the company repository, but other than that, I really have no idea how this would play out in court. It seems very risky but it's not obvious. I'd be interested in reading about cases in this middle area, if there have been any.
But anyway, I focused mostly on ethics. The specific situation you describe is ethically dubious, I agree, but I'm interested in where the line is and it's just not as clear as some are suggesting.
Copyright law is its own can of worms and is not the same as what's ethical. But, it does govern risk and practicality.
It's hard for me to imagine how you could lose rights via copy pasting the code. Making a new release with a new license doesn't invalidate the rights you already had.
Publishing code sounds like a way to prove it already existed, and nothing more.
It's not cut and dried but precisely because of that it is not a situation you should create lightly.
I think there's nothing wrong if you have a brilliant idea that happens to be useful to your employer to make some agreement that you work on it in your own time and grant the employer the use of the code. But you can't just do this unilaterally, and if you do don't expect the employer to take your side.
Just as you should have the right to decide what copyright to sell and what not the employer should have the right to assume they own the copyright to the code they paid for, unless stipulated otherwise.
Well sure, but how on earth are you going to claim it does not compete when you use that very code for the employer?
By all means try stuff out with some hobby project but don't be an idiot and tell your employer you've reused 'their' code (or at least, code in their codebase) for other clients. Either get an agreement up front or keep it secret.
A contract that grants your employer copyright to code you wrote and used in their codebase is easily enforceable. An exception would be code you wrote before the contract, but in that case using the code without some kind of agreement up front is still dangerous.
Even if it didn't touch any company resources the company just needs to be able to claim it was created within the scope of their employment or as part of the work they were hired to make.
Which is, you know, hard to argue against if you wrote the code during your employment and copied it into the code base you were hired to work on.
You write code on your personal computer outside of work hours, it belongs to you (barring truly terrible and likely unenforceable contracts). Let's say you put it up on github.
The next day you download it onto your work laptop and use it to solve problem X. I don't think there's any reasonable interpretation where your company now owns it.
IANAL, but even in California, if it relates to the business of the employer then they own it, even if you do it on your own time, on your own equipment. By definition, if you use that code while performing your job duties, then the company owns it. If you are in Washington State, then your employment contract can (and therefore will) state that anything you write, they own, and this is legal and enforceable. Again, IANAL.
Nope, it's extremely illegal. Unless the first employer gives you explicit written permission to.
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.
"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.
Which would be a great solace to someone who just spent $10k or more like 2-3x that responding to a lawsuit. But that's also why I agree the odds of actually getting sued are near-zero.
Some companies, armed with floors of attorneys and retained outside counsel, do that sort of thing just for the message alone. It costs them next to nothing, relatively, ruins the defendant regardless of outcome, and makes it clear for others to not mess around with IP.
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.
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.
I mean, I asked at the time, and I did it. If either company wants to start a legal fight over a pile of code that neither of them wanted that's old enough to be in elementary school, they know how to reach me.
The problem is that you are claiming ownership of this code and by making it available on GitHub under an MIT license you are claiming that you have the right to do so.
If I take that code and make a billion dollar business out of it, Box or Uber could then claim a share of it. That's the kind of things that companies do with the lawyers on retainer.
I then sue you for falsely claiming that you own it. You are particularly fucked because, thanks to this thread, you can't claim that you didn't know.
Even in California the "I wrote it on my own time" doesn't apply to software that relates to an employer's core business. In other places, like Washington State, you could be employed to write TPS reports and write a video game at home, and your employer would own that too.
IANAL but I have paid for advice on this very topic. I suggest you pay one too.
The author explains how analyzing and presenting data was worth millions of dollars. The author documents how a senior executive instructed him to write excel. It is clearly their core business. Also, and this comes back to the fantasy/denial/wishful-thinking aspect here, neither I nor the law says core business. That's a word that you added. If you did it as part of your job, then it is, by definition, part of their business.
I am also nearly 100% certain we can look back at this comment in 20 years and find nothing happened, but only because nobody will take this code and make a billion dollar business. If they did, I guarantee there would be a law suit.
Literally today I was in a fireside chat where the speaker told us the IP law department at a previous employer brought in a couple billions in revenue by suing for infringement.
Long time ago my employer at the time had this in-house deployment system written by a guy that worked there. It worked well and we used it well after he had moved on. He left suddenly and started a company based on the idea. Employer went to sue him and discovered the ‘all your code belongs to us’ form was missing from his permanent file so they didn’t pursue it. That company is called Chef.
A spreadsheet UI didn’t relate to Box’s core business because Box didn’t sell spreadsheet UIs. Box could have had the author’s hobby project been adopted as a feature but explicitly chose not to. The author clearly owned that bit if they did it on their own resources and own time.
In other words, you can write generally useful components and utilities on your own time, network, and equipment; license them to your employer if everyone agrees; and either way you still own them. You just can’t write something directly related to or competitive with the products or processes that make your employer money.
The spreadsheet formulae and enhancements the author wrote during work hours at Uber, though, no. But even just their direct boss as an agent of their employer saying it’s ok to throw it on GitHub would probably cut them loose, especially since it’d be a derivative work with joint ownership.
All IMO of course, but that’s how I would have seen it in their shoes.
Well, you are not a lawyer. OP specifically wrote the code to help Box with its business. That's cut and dry within the scope of an employment contract, under California law. This doesn't get a safe harbor exception.
> OP specifically wrote the code to help Box with its business.
That was the intent, but not what actually happened.
Is intent to donate code enough to put it within your employment contract, when it's done outside work hours and would otherwise be outside the scope of employment?
You misunderstand. When he wrote the code, which was related to the company's business, the company owned it. Even in California. He couldn't have "intent to donate the code" because he didn't own it in the first place. The fact that he "intended to donate it" demonstrates that it was related to the company's business.
From a practical perspective, even if you think they don't own it, do you have the money to argue that in court if they decide that they do?
IANAL. If you are having issues like this, get legal advice from a lawyer. Not HN.
Relatedness is relative but I'd argue against it here. They didn't have functionality like that, and they didn't want it.
> The fact that he "intended to donate it" demonstrates that it was related to the company's business.
...yes, that's my point. We're using that intent to make the decision that it's covered. That doesn't seem like a good way to decide whether it's covered.
If he just made a web spreadsheet and did nothing else, people would shrug.
> That was the intent, but not what actually happened.
The intent is a fact of what actually happened: which appears to be that it was written by an employee within the scope of employment to solve a business problem. Possibly outside of usual working hours, but if it’s by a salaried employee where doing work at home outside of usual working hours is itself a normal if not consistent part of employment, is probably not particularly significant.
That the employer later chose not to make use of it doesn’t change the circumstances of its creation; businesses often choose to not pursue use of exploratory work done by employees in the course of employment, that doesn’t surrender ownership of the work product.
And the version that was further developed within and in response to Uber business needs and actively used at Uber before the function for which it was used was terminated is an even clearer case (insofar as it is a distinct work from the original) of work-product (that it quite likely is also an unlicensed derivative work by Uber of proprietary Box code doesn’t mitigate that, though it puts Uber in the position of potentially being both a beneficiary and victim of IP violations.)
> which appears to be that it was written by an employee within the scope of employment to solve a business problem.
An imagined business problem.
If the code wasn't relevant to their actual business practices, that's quite relevant. They not only didn't want that code, they didn't want anything like it.
As for the modifications for Uber, that's not what I'm here to contest.
No, it’s not relevant. Seriously, go consult a lawyer in this. I have. They’re very consistent on this point because there are tons of case law regarding it.
There are a massive number of examples of patent and copyright litigation stemming from work done for one employer, who rejected it, then the employee goes off and founds their own company and gets successfully sued.
Fairchild was unique in that they had claim to the IP that their employees wanted to use in new startups, yet they decided not to follow through and allowed the employees to start their own companies. They could’ve prosecuted but didn’t, and as a result we got Silicon Valley and the culture that surrounds it.
But it’s no guarantee that that your employer won’t pursue a copyright claim they are perfectly within their rights to do. Don’t assume your employer is Fairchild.
Kinda the other way around. California has a law that states such contract clauses are unenforceable. I could show you that. Washington State does not.
Is there any other industry where workers are so beholden to their employers that they cannot simply create something of their own without fear of legal action?
How did we get to this point as an industry and how do we change this destopia?
I built a side business that makes five figures of MRR that started while I was at Box and continued through my tenure at Uber. It's still going. If anyone was going to sue anyone about anything, it wouldn't be my shitty spreadsheet library.
I’d recommend you update the article on those two points, because because as it is now, the article makes it sound like you stole code from both Box and Uber.
I don’t think its relevant that the code is old. The code is owned by the entity that’s paid for it. I also found that party of the essay really surprising.
This seems like a reasonable amount of pragmatism. As with most things in contract law, it's not meaningfully illegal unless some claimant is actually going to enforce it. You give enough context in the post to alert at reader that they should be careful of using it.
I was also absolutely gob smacked at this. Will they care? Probably not. Are you putting yourself at the absolute mercy of them deciding not to care? Absolutely.
I would have a hard time sleeping... like this would be like being in IT and knowing the backups were bullshit.
It depends on your employment agreement or contract. Most contracts I have seen say that any IP you develop related to what you're doing at work is the employers.
It only depends on your employment agreement in the other direction. Work done for hire is by default owned by your employer under federal law. For salaried employees it doesn't matter if it is done during working hours.
The employment agreement can give up this right for things not related to the company's core business, and I usually insist on that in my agreements. But that is not the default behavior.
I usually insist that personal and open source work done outside of the product areas I work on are not company owned. Otherwise if I work on financial software at a bank, and then at home I work on defi/blockchain based financial stuff, I could be setting up a liability for me or my users.
Now I understand what you are saying, and no. For a salaried employee it pretty much covers everything you do that is related to your job, with that “related to your job” being interpreted very loosely, or done with company equipment or on company time.
“Work hours” are less clear for salaried workers who may or may not take work home: if it was written to solve a problem for the employer, reviewed with other workers at work, but ultimately not further pursued the status seems murky.
The later derivative that was actively used by and updated for the requirements of another employer during the coarse of work seems to more clearly their property as a derivative (but also murky because it is potentially an illegal derivative of the earlier work, if that was owned by the earlier employer.)
That's not what happened here though. For salaried workers everything you do that is related to your job is owned by your job. That's the default even if your contract doesn't state it. He may not have been directed by his boss to make the code for Box, but he did it with the intent of helping Box's business, as a salaried worker. That makes it Box's property.
But even if you are unconvinced of that, work was clearly done on it on company time at Uber, where it was deployed as part of Uber China's business infrastructure. That work is absolutely owned by Uber (with maybe also some claim by Box). Not owned by OP.
It’s pointless to worry about being sued by a large corporation. If they want to bankrupt you, they always can, regardless of whether you did anything wrong or not.
We are like ants to them, they can squash us at any time, but most of the time we are too small to worry about.
Cool -- if one of the companies wants to issue a takedown request, they're free to make the case for it.
It's funny there's this idea that a company _might_ be potentially injured over code they do not want or know they had being made open source by its actual author, even though many of those companies will gladly use open-source tooling without ever contributing anything back.
Perhaps more soundly, though, in California – where Uber is headquartered – IP/Copyright for code is a huge legal question that the state and federal Supreme Court has no clear answer to. Sure, you obviously can't secretly clone Uber's entire stack, slap a new company logo on it, and start up as a competitor. But if you, as an author, wrote some code for a company under an IP agreement, then no-longer worked at said company, and then later adapted and expanded upon that code (or even started over, with the knowledge of what you learned from others' work): are you, at the originator, not legally allowed to be inspired by your past work? That's not something you, me, or even the company could decide.
There are gray areas but I do not think you are in one.
> and then later adapted and expanded upon that code (or even started over, with the knowledge of what you learned from others' work)
These are extremely different scenarios. Starting with a copyrighted material and modifying it is not at all the same as reading material and starting over. The first is violating copyright, the second is a derivative work.
If I read everything correctly, what you describe doing is taking code owned by the first company and modifying it for the second company. That’s not at all a gray area. It’s a copyright violation. You the engineer sign away your rights to the code when you built it for company 1 while employed by them. Their employment contract for-sure states they own any work produced by you during your employment, and you agreed to this.
If the first project was done off of company time, posted publicly on a private account, you might have a claim to the rights.
I know you’ve dug your trench too deeply to change your mind at this point, but anyone reading your comments should know what you did was technically illegal and can get people in legal hot water.
I wrote the comment above, though I'm not the author of the code that you appear to think I am. But I am in agreement with him.
> Their employment contract for-sure states they own any work produced by you during your employment, and you agreed to this.
There are many open legal questions as to where this line is drawn. Surely the line falls somewhere between "every character I've ever typed on a keyboard" and "the verbatim code". I personally don't think he's crossed it. IP ownership is much more complex than portrayed in HBO's Silicon Valley. That is my opinion.
Furthermore, when I worked at GitHub (now acquired by Microsoft, so I'm sure things have changed drastically) -- there were very lax IP ownership agreements in the employment contracts around code ownership, because the legal department was worried that if found in any way conflicting with California law it would render the entire IP claims null and void (which does have precedent in California).
The point is we don't know, and I think OP would know better than us if it was disallowed or not.
Like many things in this area, the answer is usually "You'll find out if you want to go up against an army of lawyers". The last three companies I worked for all claimed ownership of any IP I create, on or off the job, using company's equipment or using my own equipment. One of them explicitly called it out during the interview: You will have to stop working on open source or publishing side projects when working here. Can they do that? Maybe, probably not. It doesn't matter because I do not plan to bankrupt myself fighting their lawyers.
IANAL: In California they cannot, unless it is related to the employer's business (so if the employer is Apple, Google or AWS, they probably can). In most states they can.
Regardless of the fact that California is much, much more strict in what they allow, to the point where oftentimes a company’s lawyers won’t even try:
Fine. Don’t fight, I agree, that would be an unfair fight and a waste of time/money.
The US court system requires a “good faith” effort to settle the issue before it enters the legal system. A cease and desist for example— whatever it is, you’d have plenty of time to simply decide it’s not worth it and remove the code once they take notice.
Different person, but when I asked if I could publish code as open source (where appropriate), I was told that that’s fine, as long as I don’t associate it with the company in any way (e.g. non-company specific stuff is ok).
I'm not sure how we weigh up the morals here. If you've done something using a companies resources (laptop, desk, chair etc.) and they're paying you and the contract says they own it I don't see how you can have a moral high ground. Maybe there should be some way to allow these ownership concepts to expire so that society benefits overall but right now we don't have that.
When property does not serve its purpose it is no longer morally binding, just legally. And that’s if you convince me proprietary code ownership has any moral standing at all. Sometimes, I follow the law not because it’s particularly the right thing to do but because I don’t want to get in any trouble.
At one point in the article there is a photograph of a chair in the uber hallway and a caption indicating that the couch in the picture (or one similar to it) was where most of the work was done for this project.
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.
It's almost as incomprehensible as a Zen koan. I think the husband is showing the difference between talking and doing by, well, doing it. A radical way to demonstrate it.
What an utterly bizarre story. What’s the point of it? Why is the wife upset about her brother? Why is the husband so sure the brother won’t do it? What’s the significance of his little performance at the end? Why is the wife the husband’s mother, what does that have to do with anything, considering the issue is with the wife’s brother? Why don’t we get to see what the wife’s reaction to the husband’s stunt is - is she convinced by his actions, or is she as baffled as i am?
Did I just fall for a chat gpt generated nonsense fable?
I put one (possibly wrong) interpretation in an earlier comment.
As for the mother part, in many Hindu traditions monks and voluntary celibates are encouraged to see all women the same as their mothers, to remove temptation. Now he's an ascetic ergo his ex-wife is like a mother to him.
The cryptic yet amusing tone is much like a Zen koan, not a Hindu parable.
I think the wife is upset because "going ascetic" means cutting off contact. The husband is sure he won't do it because the brother is talking about it instead of doing it, which he demonstrates.
It feels like there should be more to the lesson learned than, "people who have decided will act, people who haven't only talk," but I am not quite grasping it. Maybe the other part is, "and worrying about things you cannot change harms yourself," or something?
It's a simple twist ending. The twist is that the wife was worried her brother would become an ascetic - but the person she should have worried about, the person who was planning to and did become an ascetic, was her husband. The performance is his declaration of asceticism, and the "you're my mother" line is a stock part of it, essentially meaning I renounce sexual attraction when said to your (former) partner.
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.
You know, you're totally correct that they're well within their right to do... something. But why? What damages could they collect? It would take far less cash to rewrite the library I made from scratch than it would to pay lawyers to write some scary letters. There's no trade secrets. It's not even a novel idea. It would be terribly expensive and embarrassing for either Box or Uber to try to juice this even if they were motivated to. Hell, I'm technically still an active contributor to one of the OSS projects Box uses and maintains—absolutely treacherous ignorance that doesn't make me lose a second of sleep.
It’s not really about trying to figure out why they would do it. Think about pointing a loaded gun at your face. No one else is around and your hands are nowhere near the trigger. Would it be a good idea to do it? Most people would say no, because _why risk it_?
You had no good reason to tell us the origin of this other code, and could just as well have told us you threw it together a while back for shits and giggles. Or said nothing about it at all! But by writing out precisely why (in a very legally damning way) on your website, you’ve completely exposed yourself to litigation. You’re pointing the proverbial loaded gun at your face. And as far as consequences go, facing down a vindictive or irrational former employer in court is pretty close to that metaphor.
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.
That's a tremendous war story. I _love_ it! Doing a thing that's considered unreasonable. Knowing that total value is integral of instantaneous value over time (so short high-impact projects can easily outvalue long-lived projects).
I wouldn’t try moving code written for one employer and using it another employer. Unfortunately for me my employers have been somewhat litigious; thankfully Uber doesn’t have that reputation.
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.
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.
Doing it well comes down to experience, but doing it at all comes down to asking which of your unconscious assumptions are hard requirements. Nobody is actually saying you have skills X, Y, Z, which you must use to solve this problem, which is a huge difference from how schools prepare people for the workforce.
Experience certainly helps, but last time I checked, schools are supposed to teach you how to use reference tools (reference manuals, company listings, search engines...), and how to use them well - a pretty fundamental skill of being an engineer ?
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.
> (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.
Nah, that's why you have product managers. I would have talked to this stakeholder for an hour and realized the solution is not to build another excel.
You don't reject it you understand what the problem is and design the solution and explain it to them.
I'm sure this entire team didn't need to exist in the first place but that's what you get when you only have a business person and the Dev team they hire.
A PM here would have saved the company what, $5m per year?
The second team I was on at Uber fired (with a capital F) six (6) PMs in five months for pushing back on product requirements that came from the CFO. For whatever reason, engineering rolled up to the CTO and product for this team rolled up to finance. The solution for disagreement? Pips!
> 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.
Is it any more shortsighted than using the "open tools" in the first place? There will be integration costs and maintenance of integration with open tools. You may not be able to pay anyone for support issues because those people may not provide the sort of customer support you expect when you pay someone.
The integration costs were part of the 40 hours. The trouble is you haven't avoided them by paying the money.
Open tools also tend to have a longer life, because a community survives even as members come and go, but one boss decides that a product isn't sufficiently profitable or the company gets bought out by a competitor and now it's discontinued and you have to start over.
And the open tools often end up with more transferable skills down the road: e.g. learning to deploy to AWS only helps with AWS; learning to deploy to k8s lets you be productive in a lot more situations.
Sure it’s shortsighted, but we’re all shortsighted, that’s the human condition. We can’t know all ends, which is why experience and judgement matter. The worst thing you could do is handwring over it though. Gather whatever data you can quickly leveraging the extent of your current expertise, make a call, implement and learn.
Its extremely short sighted. The cost is much more than (hourly wage x code hours).
There is ongoing maintenance cost that no one considers. I've never seen a project that gets built and just sails off for eternity with no maintenance or bugs. There will be times when the libraries or frameworks that built the underlying tool need upgrading. The requirements of the job might change even slightly and need a change in the code because custom tools are always built to only solve the narrow problem.
There is also the overhead of the fact that this junior developer will inevitably leave in 6 months and now someone who has never seen this project before has to pick it up to fix it, which means it will take even longer.
Plus that ignores the fact that if a developer tells you it will take 40 hours it will actually take 80-120 hours.
When you buy, the tools you buy are designed to be integrated with. They have support teams that will help you, and ongoing maintenance. Plus the tool is going to be more robust because it was built and used by many different companies with slightly different requirements. Plus someone else's developers will keep it up to date for you so you don't have to.
Internal tools are almost never worth it unless a pre-existing tool literally doesn't exist which happens when you are either solving insanely complex problems or insanely niche problems.
> the tools you buy are designed to be integrated with.
Until they change on a whim and force you to spend hours rebuilding your integration for negligible benefits. And then there’s the good old “change our vendors every five minutes because the last one wasn’t quite right”
> When you buy, the tools you buy are designed to be integrated with[...]
This makes me question if you're speaking theoretical, or actually have any practical experience.
I've been part of about a dozen "buy it" projects now, and so rarely they've been "designed to be integrated with. A lot of the time it's deeply legacy systems that have a half-hearted api slapped on top to check that box, but once you start using it you notice that everything you want to do somehow requires contacting the vendor first.
Which dovetails into an issue that, although vendors will give you the impression that their system is well tested and widely deployed, it all too often ends up being a lie. We've had quite a few instances where vendors have sold us what turned out to be something they were still building.
> I’ve implemented “buy” for various systems where the work to integrate was essentially the work to build
I've felt this way before, but I didn't realize that I haven't factored in the risks of actually building it. I was comparing real world integration effort with an estimate, influenced by my experience of integrating with a working product.
Common sense applies, but in general I'm terrible at giving estimates unless I've done something very similar before.
If your company isn’t making money from the product then whoever owns the copyright is irrelevant.
Good engineering is building the stuff that adds commercial value to the business and buying the stuff that only adds support to the stuff that adds commercial value.
In this instance, monitoring falls into the latter category. It’s not a business differentiator.
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.
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.
ironically, I was backend at Uber 2014 - 2018 and used to ask a simple version of implementing an excel formula engine as my go-to coding interview question. Its got a nice mix of data-structures, algorithms, complexity, and implementation. Good candidates can get a reasonably efficient implementation handling cell references in an hour.
nice read. made me nostalgic for the wild days of Uber-China hacking.
Love the part about circular references. I gotta say though - I'm having a difficult time imagining how complex these fomulas are that reimplementing Excel's formula engine is easier than just porting the formulas into JS.
The good news is that formulajs had a huge number of those functions implemented in JS already. Almost all of the time was spent on the engine, which wasn't a huge amount of code.
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.
I love this article. It begins setting the scene with Uber's grand expectations for the chinese market and then shows just a small piece of the work Uber spent on Uber China. Meanwhile Uber China itself failed spectacularly, with factories of phones claiming the free rides money.[0] I don't think I've ever experienced dramatic irony in a blog before, certainly not a technical blog. The post itself is a masterpiece.
> 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.
> 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!”
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.
If you don't quite believe it, it's almost certainly less per annum then 2 months of a typical mid-level SRE's loaded cost, even in 2016. Bandwidth would have been not great, way under a gigabit, but it wouldn't matter in this case.
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
What a fantastic perspective from the former Uber BI team. I was on the Vertica team during this time period and the amount of effort was spent on incentives mind boggling. Millions a day lost on downtime, product features, or engineering bandwidth was a common theme.
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. :)
So a lot of my time as a more junior engineer was spent on a similar project that I've described as "rebuilding excel". In my case, it was in the form of a table widget. It was an inhouse widget for displaying tabular data. We were working on AngularJS 1, and had moved from a prior iteration of our application in ExtJS. Now ExtJS had a reasonably featureful table widget out of the box, and so when we were porting to AngularJS, it was considered important that we continued to have these UI features, but at the time (the Angular ecosystem was relatively immature at that time) there were not very many advanced table widgets available in open source, so we ended up building our on.
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.
I'm confused about the circular reference thing. Like, was there a reason to do the linear regression that way? Is there a secret story in a story where next week, in a spinoff / sequel episode, the data scientist responsible will explain why they took the weird/surprising choices they did?
It's a common excel trick in finance. For example, let say you have $0. If you borrow $1,000,000 at 5% interest, by end of year you'll be short $50k. That means you actually needed to borrow $1,050,000. But the extra $50K causes more interest ($2,500)... so you needed to borrow $1,052,500, which causes more interest... and so on.
Instead of doing some Excel Goal Seek or Solver or VBA macro, it's nice to let the excel "reactivity" handle it for you.
> 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.
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.
> 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!
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.
> 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.
Another approach would be to use the Excel APIs. Both the classic desktop Excel and the web version has APIs to read/write cells and recompute. Rebuilding is more fun of course :-)
"'Growing as an engineer' means becoming a better engineer, and becoming a better engineer (directly or indirectly) means getting better at using your skills to create business value."
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'.
Side question: Why the hell is it so stupidly difficult to display and edit tabular data from programming code?
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.
> Microsoft just announced to great fanfare that Excel can call Python--which is the wrong way around
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.
> 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.
564 comments
[ 2.6 ms ] story [ 461 ms ] threadSpoiler alert: It turns out they were fulfilling a Babylonian prophecy the whole time. The whole development cycle was a complicated sacrifice to Marduk.
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?
Indeed. That library is often written off-the-clock by person X and imported on-the-clock by person Y.
Sometimes X === Y.
Commit it to a repo somewhere.
I have a 4 years 1 day old repo for code that was used in a job 4 years ago.
But I made sure to have a written agreement saying that the code I was bringing in was, within reasonable limits, still mine.
Clearly this doesn't include code that was produced during the job.
Software written off the clock that does not compete with the employer is not only not the property of the employer, but any contract attempting to gain such ownership is unenforceable.
Many businesses even actively encourage their developers to contribute to open source projects.
I highly doubt that this is true, at least in the US. Can you cite case law?
You can write a contract granting ownership of all the songs a musician performs, or all the books a writer writes during a specified time period. Why shouldn't the same be true of programmers and code?
Whether these are enforceable or not doesn't matter because a lone developer is not going to go up against an army of corporate lawyers to find out.
I would argue those are exceptional cases. Outside of these prestige brands, you get a lot more leeway.
I have. I got an extra $130k out of it.
It's a work of art. Even this comment is a violation of the agreement, since I don't own the copyright to anything I do apparently, either in or out of the scope of my employment, so therefore I can't give Y Combinator a license to display this comment.
I even talked to the company's legal team about the absurdity of the agreement & they were unwilling to budge.
The relevant portion of the agreement, for your reading amusement: https://pastebin.com/ZF9MEkfG
Completely false. Most people sign job contracts without thinking too hard. And side projects just aren’t important for the majority of programmers, so why would they care?
This is an even stronger case than anything being discussed in this thread. Oracle claimed to own code written by their own employees on their clock and still lost this case. Google won their claim of fair use.
That's exactly and explicitly what an MIT licensed open source project would fall under: fair use by the employer and nobody owns it despite the original author also happening to work for said employer. Authorship is distinct from ownership. As well, there's the notion of role vs identity. You can act under the role of an employee to fork a public repo for your employer's purposes, yet act under the role of the upstream author to have published something more generic in the past without knowledge of your employer's future use case. Your identity is irrelevant. The only thing that really matters is that the public repo does not contain code proprietary to any business. It's on the employer claiming the code is proprietary to prove it. Examples from the article would be those data science functions, the UI they wanted, etc.
Do people not realize why these licenses exist in the first place? What do you all think they were doing over there at MIT to draft up such a license?
There are two questions here:
1) Can the employee use the code at work?
2) Who owns the code?
In Oracle v. Google, not even actual ownership impeded fair use. Nobody really owns the code on a public repo, so there's your answer to #1. The employee can use the code they authored and published to the world without any issues.
Now for question 2...
> what we’re talking about
What you're talking about.
You're correct that Oracle v. Google does not give any clear answers on ownership. For that you have to rely on the license applied to the project. It's simple. If you publish a project under a permissive license and your project does not contain anything proprietary, nobody owns it. Employment contracts don't have anything to do with this situation.
But, what does it really mean to "own" code? What is owned? The concept or the literal sequence of chars? It seems to be the latter which Google showed is trivially sidestepped by rewriting the code behind an API. Thus ownership is pointless in software unless it's closed source and proprietary, which is the opposite of a fun little Excel clone, amateur video game, etc.
The only thing enforceable about an employment contract is the clause about terminating an employee for working on side projects on the company time and/or with company property such that it takes away from productivity towards their work. I don't think anyone is talking about that or would even think of doing that though.
Which likely means your "free time" code you decided to do to make your job easier now belongs to your employer since they asked you to write it (albeit indirectly in this situation).
Will anything come of it for trivial stuff? Probably not, but that doesn't mean it's ok.
Unless you have something in writing saying otherwise, best not to mix stuff like this because one day you might wind up on the wrong side of an army of lawyers.
Especially when you have problem A at work, then some time later write "generic code" that solves problem A, then some time later "import" the code to your dayjob to solve problem A. And double so if nobody else ever uses this generic code and you never use it for anything else.
As an industry we talk a lot about flexibility, particularly in scheduling and when we do our work, but you can't have it both ways. You can't be doing laundry and mowing the lawn and going grocery shopping in the middle of the work day because it helps you think or it helps your programming process, but then make the argument that because you wrote this code at 6 PM on a Sunday it's yours and not your employers, when you committed it to your employer's git repo Monday morning. Not with a straight face, at least.
I want to be clear, I'm all about getting shit done during the day. If I need to get a haircut at 2:30 PM, I will. But I'm also not pretending that my employer's code is mine or that I have any right to publish it.
Some contracts stipulate that anything you write while employed is owned by your employer. (I'm settled in that this is unethical, but it's reasonable to comply.)
But let's suppose there's no such stipulation.
You get an idea while at work. Everyone gets ideas. You take your brain home with you (I hope) and start developing that idea. You think it's generally useful and doesn't depend on any or reveal anything about a trade secret or other proprietary work, nor reveal anything about them.
Is it your choice to contribute that idea to your employer or to use it in an open source or some other unassociated project? Why or why not?
Is it OK if you never use it for any of your employer's projects?
If not, then is it OK to wait until after your employment to develop that idea on your own or for your next employer or even turn it into your really awesome startup that definitely won't fail? (I think all of you are willing to do the first, and most of you the second.) Why does that change the ethical quandary, or why doesn't it?
Alright, so your employer specifically asked for this solution and you wrote one on the clock but it was minimal, maybe you didn't have enough time to make a more elaborated one, and you write a better one and did one of the above with it. Is that OK?
I don't think this question is all that cut and dried.
That is different than solving common business problems at home, then when asked to solve them at work just copy/pasting those solutions and assuming you retain rights. Contributing that to your employer under that situation is no different than just working on salary - and you have not given the employer the option of rejecting those contributions.
But anyway, I focused mostly on ethics. The specific situation you describe is ethically dubious, I agree, but I'm interested in where the line is and it's just not as clear as some are suggesting.
Copyright law is its own can of worms and is not the same as what's ethical. But, it does govern risk and practicality.
It's hard for me to imagine how you could lose rights via copy pasting the code. Making a new release with a new license doesn't invalidate the rights you already had.
Publishing code sounds like a way to prove it already existed, and nothing more.
I think there's nothing wrong if you have a brilliant idea that happens to be useful to your employer to make some agreement that you work on it in your own time and grant the employer the use of the code. But you can't just do this unilaterally, and if you do don't expect the employer to take your side.
Just as you should have the right to decide what copyright to sell and what not the employer should have the right to assume they own the copyright to the code they paid for, unless stipulated otherwise.
By all means try stuff out with some hobby project but don't be an idiot and tell your employer you've reused 'their' code (or at least, code in their codebase) for other clients. Either get an agreement up front or keep it secret.
A contract that grants your employer copyright to code you wrote and used in their codebase is easily enforceable. An exception would be code you wrote before the contract, but in that case using the code without some kind of agreement up front is still dangerous.
If that code touched their work laptop (which it did since he showed it), it's now company property.
That code most likely belongs to Uber legally, but they probably don't care that much.
Which is, you know, hard to argue against if you wrote the code during your employment and copied it into the code base you were hired to work on.
The next day you download it onto your work laptop and use it to solve problem X. I don't think there's any reasonable interpretation where your company now owns it.
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.
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.
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.
Thanks anyway.
---
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.
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.
enjoyed the article, the bit about Excel circular ref linear regression was wild
If I take that code and make a billion dollar business out of it, Box or Uber could then claim a share of it. That's the kind of things that companies do with the lawyers on retainer.
I then sue you for falsely claiming that you own it. You are particularly fucked because, thanks to this thread, you can't claim that you didn't know.
Even in California the "I wrote it on my own time" doesn't apply to software that relates to an employer's core business. In other places, like Washington State, you could be employed to write TPS reports and write a video game at home, and your employer would own that too.
IANAL but I have paid for advice on this very topic. I suggest you pay one too.
I’m nearly 100% certain we can look back at this comment in 20 years and find that absolutely nothing happened.
I am also nearly 100% certain we can look back at this comment in 20 years and find nothing happened, but only because nobody will take this code and make a billion dollar business. If they did, I guarantee there would be a law suit.
That’s just factually false. You specifically wrote:
> Even in California the "I wrote it on my own time" doesn't apply to software that relates to an employer's ***core*** business.
You can’t complain about people being “wishful” or in “denial” when they are quoting you.
Maybe California law is silent in the topic, but Aeolus wasn’t the person who introduced that specific phrase.
Getting a judgement against an individual is vanishingly unlikely to result in any profits.
https://unicourt.com/case/pc-db5-better-holdco-inc-et-al-v-d...
In other words, you can write generally useful components and utilities on your own time, network, and equipment; license them to your employer if everyone agrees; and either way you still own them. You just can’t write something directly related to or competitive with the products or processes that make your employer money.
The spreadsheet formulae and enhancements the author wrote during work hours at Uber, though, no. But even just their direct boss as an agent of their employer saying it’s ok to throw it on GitHub would probably cut them loose, especially since it’d be a derivative work with joint ownership.
All IMO of course, but that’s how I would have seen it in their shoes.
That was the intent, but not what actually happened.
Is intent to donate code enough to put it within your employment contract, when it's done outside work hours and would otherwise be outside the scope of employment?
From a practical perspective, even if you think they don't own it, do you have the money to argue that in court if they decide that they do?
IANAL. If you are having issues like this, get legal advice from a lawyer. Not HN.
Relatedness is relative but I'd argue against it here. They didn't have functionality like that, and they didn't want it.
> The fact that he "intended to donate it" demonstrates that it was related to the company's business.
...yes, that's my point. We're using that intent to make the decision that it's covered. That doesn't seem like a good way to decide whether it's covered.
If he just made a web spreadsheet and did nothing else, people would shrug.
The intent is a fact of what actually happened: which appears to be that it was written by an employee within the scope of employment to solve a business problem. Possibly outside of usual working hours, but if it’s by a salaried employee where doing work at home outside of usual working hours is itself a normal if not consistent part of employment, is probably not particularly significant.
That the employer later chose not to make use of it doesn’t change the circumstances of its creation; businesses often choose to not pursue use of exploratory work done by employees in the course of employment, that doesn’t surrender ownership of the work product.
And the version that was further developed within and in response to Uber business needs and actively used at Uber before the function for which it was used was terminated is an even clearer case (insofar as it is a distinct work from the original) of work-product (that it quite likely is also an unlicensed derivative work by Uber of proprietary Box code doesn’t mitigate that, though it puts Uber in the position of potentially being both a beneficiary and victim of IP violations.)
An imagined business problem.
If the code wasn't relevant to their actual business practices, that's quite relevant. They not only didn't want that code, they didn't want anything like it.
As for the modifications for Uber, that's not what I'm here to contest.
There are a massive number of examples of patent and copyright litigation stemming from work done for one employer, who rejected it, then the employee goes off and founds their own company and gets successfully sued.
Fairchild was unique in that they had claim to the IP that their employees wanted to use in new startups, yet they decided not to follow through and allowed the employees to start their own companies. They could’ve prosecuted but didn’t, and as a result we got Silicon Valley and the culture that surrounds it.
But it’s no guarantee that that your employer won’t pursue a copyright claim they are perfectly within their rights to do. Don’t assume your employer is Fairchild.
This is a leap
How did we get to this point as an industry and how do we change this destopia?
Thanks for sharing a cool story.
I would have a hard time sleeping... like this would be like being in IT and knowing the backups were bullshit.
The employment agreement can give up this right for things not related to the company's core business, and I usually insist on that in my agreements. But that is not the default behavior.
Work for hire should always be very clear.
The later derivative that was actively used by and updated for the requirements of another employer during the coarse of work seems to more clearly their property as a derivative (but also murky because it is potentially an illegal derivative of the earlier work, if that was owned by the earlier employer.)
But even if you are unconvinced of that, work was clearly done on it on company time at Uber, where it was deployed as part of Uber China's business infrastructure. That work is absolutely owned by Uber (with maybe also some claim by Box). Not owned by OP.
We are like ants to them, they can squash us at any time, but most of the time we are too small to worry about.
Misses the point, which is: the likelihood of being sued increases when you break contracts or appear to do so
It's funny there's this idea that a company _might_ be potentially injured over code they do not want or know they had being made open source by its actual author, even though many of those companies will gladly use open-source tooling without ever contributing anything back.
Perhaps more soundly, though, in California – where Uber is headquartered – IP/Copyright for code is a huge legal question that the state and federal Supreme Court has no clear answer to. Sure, you obviously can't secretly clone Uber's entire stack, slap a new company logo on it, and start up as a competitor. But if you, as an author, wrote some code for a company under an IP agreement, then no-longer worked at said company, and then later adapted and expanded upon that code (or even started over, with the knowledge of what you learned from others' work): are you, at the originator, not legally allowed to be inspired by your past work? That's not something you, me, or even the company could decide.
> and then later adapted and expanded upon that code (or even started over, with the knowledge of what you learned from others' work)
These are extremely different scenarios. Starting with a copyrighted material and modifying it is not at all the same as reading material and starting over. The first is violating copyright, the second is a derivative work.
If I read everything correctly, what you describe doing is taking code owned by the first company and modifying it for the second company. That’s not at all a gray area. It’s a copyright violation. You the engineer sign away your rights to the code when you built it for company 1 while employed by them. Their employment contract for-sure states they own any work produced by you during your employment, and you agreed to this.
If the first project was done off of company time, posted publicly on a private account, you might have a claim to the rights.
I know you’ve dug your trench too deeply to change your mind at this point, but anyone reading your comments should know what you did was technically illegal and can get people in legal hot water.
> Their employment contract for-sure states they own any work produced by you during your employment, and you agreed to this.
There are many open legal questions as to where this line is drawn. Surely the line falls somewhere between "every character I've ever typed on a keyboard" and "the verbatim code". I personally don't think he's crossed it. IP ownership is much more complex than portrayed in HBO's Silicon Valley. That is my opinion.
Furthermore, when I worked at GitHub (now acquired by Microsoft, so I'm sure things have changed drastically) -- there were very lax IP ownership agreements in the employment contracts around code ownership, because the legal department was worried that if found in any way conflicting with California law it would render the entire IP claims null and void (which does have precedent in California).
The point is we don't know, and I think OP would know better than us if it was disallowed or not.
Fine. Don’t fight, I agree, that would be an unfair fight and a waste of time/money.
The US court system requires a “good faith” effort to settle the issue before it enters the legal system. A cease and desist for example— whatever it is, you’d have plenty of time to simply decide it’s not worth it and remove the code once they take notice.
As it is, this is all no harm, no foul.
1. I copied this to disk, and I've iterated on it. Derivative work. Company owns it.
2. I created a new original work from scratch, based on my experiencing doing it once or twice before. Independent work. Author owns it.
IANAL; ut's not quite that simple, but it's in the right general direction. If you need specific advice, talk to an actual lawyer tho.
That said, I think OP is morally in the right here, and I wish I had the guts to do similar things.
Sharing code is a good thing. Helping one company innovate using code that another company chose to ignore is also a good thing.
You're making a huge assumption that this is what happened.
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.
Did I just fall for a chat gpt generated nonsense fable?
What is going on here!
As for the mother part, in many Hindu traditions monks and voluntary celibates are encouraged to see all women the same as their mothers, to remove temptation. Now he's an ascetic ergo his ex-wife is like a mother to him.
The cryptic yet amusing tone is much like a Zen koan, not a Hindu parable.
It feels like there should be more to the lesson learned than, "people who have decided will act, people who haven't only talk," but I am not quite grasping it. Maybe the other part is, "and worrying about things you cannot change harms yourself," or something?
Why am I reminded of this meme?
https://amp.knowyourmeme.com/memes/what-are-you-gonna-do-sta...
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.
You had no good reason to tell us the origin of this other code, and could just as well have told us you threw it together a while back for shits and giggles. Or said nothing about it at all! But by writing out precisely why (in a very legally damning way) on your website, you’ve completely exposed yourself to litigation. You’re pointing the proverbial loaded gun at your face. And as far as consequences go, facing down a vindictive or irrational former employer in court is pretty close to that metaphor.
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)
https://en.m.wikipedia.org/wiki/Sergey_Aleynikov
how many people there were at that point, @bastawhiz?
> 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.
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.
"Cattle, not pets" may be a good way to run a business, but not your life.
> (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.
Seems like a risky strategy...
A PM here would have saved the company what, $5m per year?
Ha
Ha ha
Hahahahaha
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.
Open tools also tend to have a longer life, because a community survives even as members come and go, but one boss decides that a product isn't sufficiently profitable or the company gets bought out by a competitor and now it's discontinued and you have to start over.
There is ongoing maintenance cost that no one considers. I've never seen a project that gets built and just sails off for eternity with no maintenance or bugs. There will be times when the libraries or frameworks that built the underlying tool need upgrading. The requirements of the job might change even slightly and need a change in the code because custom tools are always built to only solve the narrow problem.
There is also the overhead of the fact that this junior developer will inevitably leave in 6 months and now someone who has never seen this project before has to pick it up to fix it, which means it will take even longer.
Plus that ignores the fact that if a developer tells you it will take 40 hours it will actually take 80-120 hours.
When you buy, the tools you buy are designed to be integrated with. They have support teams that will help you, and ongoing maintenance. Plus the tool is going to be more robust because it was built and used by many different companies with slightly different requirements. Plus someone else's developers will keep it up to date for you so you don't have to.
Internal tools are almost never worth it unless a pre-existing tool literally doesn't exist which happens when you are either solving insanely complex problems or insanely niche problems.
Until they change on a whim and force you to spend hours rebuilding your integration for negligible benefits. And then there’s the good old “change our vendors every five minutes because the last one wasn’t quite right”
This makes me question if you're speaking theoretical, or actually have any practical experience.
I've been part of about a dozen "buy it" projects now, and so rarely they've been "designed to be integrated with. A lot of the time it's deeply legacy systems that have a half-hearted api slapped on top to check that box, but once you start using it you notice that everything you want to do somehow requires contacting the vendor first.
Which dovetails into an issue that, although vendors will give you the impression that their system is well tested and widely deployed, it all too often ends up being a lie. We've had quite a few instances where vendors have sold us what turned out to be something they were still building.
I've felt this way before, but I didn't realize that I haven't factored in the risks of actually building it. I was comparing real world integration effort with an estimate, influenced by my experience of integrating with a working product.
Common sense applies, but in general I'm terrible at giving estimates unless I've done something very similar before.
Good engineering is building the stuff that adds commercial value to the business and buying the stuff that only adds support to the stuff that adds commercial value.
In this instance, monitoring falls into the latter category. It’s not a business differentiator.
I like your story of enlightenment though! I guess if you could genuinely build and maintain something cheaper, then why not.
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.
nice read. made me nostalgic for the wild days of Uber-China hacking.
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.
[0]https://www.forbes.com/sites/ywang/2016/09/27/ghost-drivers-...
https://learn.microsoft.com/en-us/sharepoint/dev/general-dev...
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!”
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. :)
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.
After enabling iterative calculation and manual calculation, every press of refresh runs a loop. Fun stuff.
Instead of doing some Excel Goal Seek or Solver or VBA macro, it's nice to let the excel "reactivity" handle it for you.
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'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.
I think that's a very generous read of what I said the requirements for this product were.
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 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
*Seven year ago at Uber
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.
How does this help you in the browser?
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
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.
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'.
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.
> 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.