41–50 of 565 posts
[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.
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 tre…
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.
"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.
I believe this kind of story is the kind that gives most legal counsel nightmares.
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.
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. :)
Earlier quoted context omitted.
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.
... Nothing came of it, but I took the code and shoved it into my back pocket for a rainy day ... 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.
> 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 mod…
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!”
Earlier quoted context omitted.
Quite the opposite. 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.
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 someth…
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.
Earlier quoted context omitted.
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.
... Nothing came of it, but I took the code and shoved it into my back pocket for a rainy day ... 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.
I would have a hard time sleeping... like this would be like being in IT and knowing the backups were bullshit.