371–380 of 611 posts
Hello Uber Engineer here! Obviously everything I say is personal experience and opinion. I think the layoffs were long overdue and should've happened sooner. There was a general understanding between my coworkers and I that Uber definitely over hired in 2016. Thanks to that a lot of engineers ran out of things to do which led to political infighting over roadmap, ridiculous redundant resourcing - every single team ha…
Earlier quoted context omitted.
Google only lets candidates interview three times: https://www.quora.com/How-many-times-can-you-interview-with-... (edit: sorry, see below too)
I was told by a Google HR that on average a candidate tries 4 times before passing the interview. That's believable because when any of the 5 interviewers saying "probably not" translates to a no hire, stars really need to align even for stellar candidates.
Earlier quoted context omitted.
It's especially a dick move when everybody already knows they're hurting for cash, and the official position could be "we just can't afford all these people" without the company losing any face. They aren't fooling anybody by pretending it's not about the cost.
If you're going to lay off people in a cross cutting manner, who would you choose?
Earlier quoted context omitted.
That's not true. It costs quite a bit to open source a product if you're a commercial entity.. It needs to be reviewed (by legal, security, engineering, etc) and approved.. You're not just flipping the public/private flag on the repo.
Why would you give your open source code a tighter security and engineering review than your in-house code? Are you hoping for security through obscurity? And quality through obscurity?
Earlier quoted context omitted.
Open Source chat tools are sadly almost universally disappointing. I believe I tried just about every one of them before giving up and just using Slack. I detailed the reasons here: https://news.ycombinator.com/item?id=17623005 I have the impression that Slack has gotten worse. We're again having problems of notifications not showing up.
If you were willing to use Slack after all, then I guess you were willing to consider non-FOSS alternatives? In which case, one service you don't seem to have considered: Discord. Yes, really, for business. Look past the theming. Discord has a much more solid tech base (and engineering team) behind it than Slack, IMHO. A better API, too; and—unlike Slack—real support for third-party clients! I built my own niche team…
Earlier quoted context omitted.
If you were willing to use Slack after all, then I guess you were willing to consider non-FOSS alternatives? In which case, one service you don't seem to have considered: Discord. Yes, really, for business. Look past the theming. Discord has a much more solid tech base (and engineering team) behind it than Slack, IMHO. A better API, too; and—unlike Slack—real support for third-party clients! I built my own niche team…
Right, let's just do all our business on an app that doesn't have SSO and instead anyone with the link who can sneak in has access. I'm sure that's not sketchy at all and your IT department will be thrilled.
You don't have to make those links (and you can turn off, per server, the ability to create those links.) You can invite specific users. The user already has to have a Discord account, though.
And that's the thing; Discord has a different accounts model. Which is part of what I was referring to when I said they had a more solid tech base: when you're signed into a dozen Slack workspaces, the Slack client has to keep a dozen websockets open, because the open connection is for a given Slack account's view of the world, and Slack accounts are a sub-resource of Slack teams. This isn't a scalable model, and when the Slack app is using 1.2GB of memory and two full CPU cores, this is much of the reason why. When you're signed into a Discord account, on the other hand, you just have one connection to the server—and one state-sync session that includes all your open channels in all those servers—because your profile on a given Discord server is a sub-resource of your global Discord account.
It's the difference between how an email client connects to N accounts through IMAP, and how the Gmail mobile app is connected to N GSuite accounts.
And, as such, it wouldn't really make sense to have Discord SSO at the account level, because a Discord account is associated with the individual, not with a particular employee record of a particular Enterprise. It's not like an email address; it's more like a Keybase identity or a Facebook profile. (You could certainly have particular profiles under the Discord account that did SSO to a particular server, but this wouldn't be traditional SSO-as-we-know-it; it'd be more of a "connector" flow, like when an app wants to use your Github profile.)
Github is a good comparison, actually. Most corporations just use Github, not Github EE. You don't Enterprise-SSO to Github.com. Github.com is an SSO provider, in fact, that other sites (e.g. Asana) can take auth from!
Probably some reality shaking out. Uber's engineering team puts out some impressive stuff, often as OSS. Their engineering blogs are regularly on HN. I've been genuinely surprised that they churn out some of these things and release them for free given their relatively extreme financial situation. In contrast to companies like Google, Apple, Microsoft, Amazon etc. that have mountains of their own money to burn (rathe…
It doesn't really cost anything to open source something though. These are all projects which are developed for a reason: the commercial version might be prohibitively expensive at Uber scale, or not technically capable of operating at Uber scale, or just plain doesn't exist yet. At that point you can engage with the tech community and offer it as OSS (not to mention make your engineers happy), or you can keep it to…
If the presumption is that the software would be useful ("developed for a reason") economics suggests there is some price people would be willing to pay for it, and you forfeit that when you make it OSS. That absolutely costs something.
Sure you may not want to be in the business of commercial software (support, maintenance, ultimately just responsibility) which is a completely sane thing to avoid. However when you are bleeding money at the rate of a small country's GDP per year, avoiding opportunities to generate profit based on intangibles like community engagement can come off as ill-advised. In fact, if your company is declared bloated, it stands to reason that you should have the capacity to take on the additional overhead of selling the software. It is not that contributing to OSS is wrong, or that your points are wrong, just that there is a time and situation for this kind of strategy.
Contrast with Amazon, whose entire development of AWS was for the reasons you point out. Instead of open-sourcing it, to the extent that would be possible, they made it into a product and almost in a single move turned consistent overall loss into a massively profitable company.
So this is not at all to argue against the merits of having healthy OSS contribution at a company, but more to say that a company can't contribute to OSS if they are bankrupt - so avoiding the latter should be prioritized over the former.
Related, but Uber is said to be hiring 2,00 for it's new Chicago office next year [1]. A mix of engineering and operations. My understanding this would be under their freight team, which according to this Techcrunch article, was unaffected by this layoff. [1]: https://www.chicagotribune.com/business/ct-biz-uber-hiring-o...
Maybe they are shifting headcount away from the Bay Area?
Earlier quoted context omitted.
Lyft is no better, spending $8M per month on AWS to process 1M transactions per day.
AWS is the opposite of homebrew. Lyft has no business maintaining its own data centers and operational overhead. There is a huge opportunity cost involved with running your own infrastructure. AWS and the like free your own teams from worrying about how to provision new systems, upgrading DB server versions, etc. Running your own data center is hard. Running your own DC is the same as building your own chat app. It i…
What I was trying to point out is someone engineered a system that costs 8M/mo to run yet only handles 1M rides per day.