It would be great if it worked both ways. Let’s say an employee who is forced to work unpaid overtime (two jobs amount) could use power imbalance to threaten the company into paying one year of their revenue.
If his work quality is really that bad, why not fire him already? What if he was simply super lazy but with one job, why not make an example of him for other slackers?
To be fair there is a difference between female and male circumcision.
The female one is clearly to assert dominance over women, ideally in a painful and traumatical way. Also preventing them from getting pleasure from intercourse, because this is a men's thing.
For boys it is a barbaric ritual attached to some religions. The difference is that it is usually done on babies and is not particularly impacting later on.
Both are in my opionions felonies, done in the name of retarded ideas. The consequences are however very different.
I have never tried AWS managed elasticsearch, but Azure Search doesn't have many knobs. Most of the time it's just instance size, replica and partition count.
The downside is that the service is probably called "Azure Cognitive DeepMind Quantum DevOps Search" by now.
I think that the problem is when you have a materialized view which takes hours to refresh. We are lucky that 99% of our traffic is during 7-19 on weekdays, so we can just refresh at night, but that won't work for others.
I don't know much about how postgresql works internally, so I just probably don't understand the constraints. Anyway as I understand, there are two ways to refresh. You either refresh a view concurrently or not.
If not, then postgres rebuilds the view from its definition on the side and at the end some internal structures are switched from the old to the new query result. Seems reasonable, but for some reason, which I don't understand due to my limited knowledge, an exclusive access lock is held for the entire duration of the refresh and all read queries are blocked, what doesn't work for us.
If you refresh concurrently, postgres rebuilds the view from its definition and compares the old and the new query result with a full outer join to compute a diff. The diff is then applied to the old data (like regular table INSERT/UPDATE/DELETE I assume), so I think you get away with just an exclusive lock and read access still works. There are two downsides to this, first that it requires a UNIQUE constraint for the join, second that the full outer join is a lot of additional work.
I never had the time to test Materialize, but it seems to do what I want with its continuous refresh.
I also thought about splitting the materialized view into two, one for rarely changing data and another one for smaller part of the data which changes daily. Then I would only have to refresh the smaller view and UNION ALL both materialized views in a regular view. Not sure how well will that work with postgres query planner.
Not sure about how that would work with the PG query planner either, but a batch for rarely changing data and rapid changing data is basically the Lambda data architecture, so probably a good call!
Yeah, using revolut for that is ironic, fighting scummy companies with another scummy company. It is the only way to get disposable cards or sane conversion rates in many markets unfortunately.
> We need to be able to see each other in the eye.
No, we don't, why would you think that?
We never have camera on and work is going smoothly. Nobody ever suggested using it. I don't even know how the new hires look like, but it doesn't matter, because I can treat them like humans without attaching a mental representation of their physical form. I got this skill from an experience called 'phone call'.
I wonder if it is a culture difference. I'm from eastern Europe and no one I have asked uses camera, outside those forced due to working directly with the US. People who can't stand not being able to judge their coworkers faces, where are you from?
Anyway, put your camera on if you want to, I can get used to ignoring it. Please don't force your preferences on others.
We couldn't technically make it stop exactly at $150.00, but only at $167.89 or whatever, so we are letting it run to $15k.
For catastrophic cases it doesn't matter. If it saves a person from an unexpected $15k bill then it works. Even for many businesses it would be ok to drop everything - I know some which can withstand being offline for a day, but not a $250k bill.
Maybe they are not upset about not winning, but that a fun to play game is now no fun at all? If there is an imbalance/glitch which renders most of the game depth obsolete I'm not leaving because I'm salty, I'm going to have actual fun elsewhere instead.
Since you mentioned in a comment that your non-compete expired, maybe you are also no longer under any NDA. Can explain to a person outside of the startup world how this buy-and-kill works? If not killing a competitor, why? What do they expect a founder to do after killing their baby?
It wasn’t ever intended to be a buy-and-kill, it’s just unfortunately what ended up happening. When Slack acquired Screenhero, it was with the full intent to bring voice/video/screen sharing to Slack. The problem was that, post-acquisition, leadership lost interest in what could’ve been a promising feature set and growth vector for Slack (see: Zoom in 2020). Partially because integrating disparate pieces of software is a hard problem and partially because management's appetite for investment in the team waned after the first year, building Slack Calls was slow and it was unclear how valuable the feature was to Slack's success. Add in the cost of maintaining what is a very complicated and far-reaching implementation for interactive screen sharing, (not just for engineering, but also for policy/legal and customer support), it made sense for Slack to kill it.
While I was still at Slack, there were retrospective conversations around how Screenhero maybe should have been built on the Slack platform, instead of as a first-party app. However, the acquisition happened so early in the life of Slack that the platform didn't really exist yet, so it's unclear how we'd do better if we had to do it all over.
With Pop, we're doing things the right way. Pop is a standalone app, with a solid Slack integration. It makes it really fast to jump between the two (in fact, it's faster to jump into a Pop meeting via Slack, than it is to join a Slack Call!).
Slack's poor calling is baffling to us, and the fact that they are uninterested in making it better is obvious. The quality is so bad, we use google meet for almost everything at the company, even though we would prefer to use the native slack calling.
Its actually easier to use other apps than Slack's own apps.
For example, you can't schedule a recurring slack call that calls all the participants. I would LOVE this feature, if there is a way to add it into slack.
The way you explain it, looks like if Slack acquired Screenhero in a whim, "just in case we need it", and afterwards they realized that integrating and maintaining foreign code is a hard to do. Like, I could have told them that piece of wisdom for free.
I know, things are always more complex and your comment is no doubt a summarized version of what happened. It just read funny to me.
Yes, that was ~3 years of learning (and pain) condensed into a short paragraph :D
I think one key piece worth emphasizing was: Screenhero's core strength was in its interactive screen sharing. Slack's main desire was in voice, then video, then screen sharing, then interactive screen sharing — and this "impedance mismatch" is somewhat responsible for where things ended up. By the time we got to the end of that roadmap, the appetite for the final feature was low, while the cost was very high.
I had the same in Italy (Tuscany) with Google Maps. One way it recommended a longer normal road, on the way back it was a shorter dirt road through fields and forests. Had to stop once to let a fox cross the road (it didn't seem to care much about me). In the end it took as much time if not more.
Those rental Pandas can take you everywhere though.
It would be great if it worked both ways. Let’s say an employee who is forced to work unpaid overtime (two jobs amount) could use power imbalance to threaten the company into paying one year of their revenue.
If his work quality is really that bad, why not fire him already? What if he was simply super lazy but with one job, why not make an example of him for other slackers?