51–60 of 565 posts
Earlier quoted context omitted.
I believe this kind of story is the kind that gives most legal counsel nightmares.
Especially the brazenness with which the author basically says "if they want to sue me for this verified and admitted IP theft, they can." 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.
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.
Earlier quoted context omitted.
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?
> how many times do you really need to write a spring OAuth server that integrates with LDAP? 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?
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…
Earlier quoted context omitted.
Especially the brazenness with which the author basically says "if they want to sue me for this verified and admitted IP theft, they can." 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.
And if you lose immediately, you likely owe damages. Those damages, even if trebled, appear to be $0 here.
Earlier quoted context omitted.
... 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 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.
> 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…
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…
Give the time and labour you're paid for, don't give emotional energy.
"Cattle, not pets" may be a good way to run a business, but not your life.