HackerTrans
TopNewTrendsCommentsPastAskShowJobs

cletus

no profile record

comments

cletus
·vor 24 Tagen·discuss
I have to disagree with this as someone who worked at Meta (and Google).

WhatsApp was a textbook example of how not to do an acquisition. The story I heard was when it was acquired, a spreadsheet went around and everyone basically decided what level they were in the (then) FB job ladder and all the engineers said they were E7s (Senior Staff SWE). The way PSC worked, WhatsApp at the time was only ever calibrated against themselves (from what I heard). It had become a fiefdom and, as someone who was on a team that tried to get them to do anything, the experience was awful.

IG was handled better but it was also an almost nonexistent team when acquired, which might well explain it. They stuck with their Django/Python codebase and (IMHO) that was a mistake. The amount of duplication that we had to do for IG specifically was embarrasing. The framework and tooling FB had on the product side was light years ahead of what IG had. IG used to have a very good product focus but I think that's long dead now. It was good because IG had a clear vision for their app and ultimately (IMHO) management had a different view to "grow". They briefly tried to launch another app (IGTV) that flopped, hard. There were a bunch of UI/UX changes that clearly showed the focus had become simply following celebrities instead of sharing updates (eg where the post/compose buttons moved to).

I mention Google because I saw the same things happen at Google.

Youtube was (and my guess is, still is) its own entity. Culturally, Youtubers don't see themselves as Googlers. They didn't (AFAIK) use Google3 or any of the other stuff most of the rest of Google did. But Youtube itself was perceived very positively, technically, particularly in relation just general encoding/decoding infrastructure as well as Bandaid (where racks are shipped to ISPs to cache videos).

Android was another acquisition that prided itself in not being Google. This was very much fostered by Andy Rubin while he was still there. Obviously Google needed to write Android apps but I got the sense that it was always Google engineers who solved all the problems whereas Android just didn't care. They cared only about shipping Android. Fuchsia was an Android offshoot.

Docs and Maps were both acquisitions but they went fully Google3 and were different orgs but weren't seen as separate. The engineering director of Docs (Fuzzy) had, from what I can recall, a very positive reputation beyond Docs (now Drive).

Doubleclick was also an acqusition but went fully Google and you'll find a lot of people who don't even know it was an acquisition.

I don't know what org you worked in but they all vary. My own experience was that Infra orgs in comparison to Google were primitive and barely above just running random Docker-like (Tupperware) instances with a godawful variant of C++, probably started by someone who had done C++ at Google and had decided they really wanted mutable function parameters and exceptions for no particular reason.

The thing I really respected about FB product orgs generally was that really did ship things quickly. I used to joke that the smallest unit of time at Google was a quarter. God help you if you eneded another team (under a different VP) to do something. You'd have to spend a quarter arguing with them to get them to add it to their OKRs for the following quarter.

At FB the timeline for launching a new thing to a limited audience was measured in weeks. The biggest barrier usually was the weekly build cycle for the blue app. The release cycle for Web was S-tier and (IMHO) the people who worked on the infra for Web were generally god tier. This was another reason why IG doggedly sticking with Python just created problems.

There are many thigns you can criticize Meta for (eg the stupid crypto, the billions wasted on VR) but the Web Foundation and Ent teams were god tier and I'll die on that hill.

Anyway, even back then the ML teams and infra, not to put too fine a point on it, sucked (IMHO). Newsfeed was OK but the recommendations for a lot of things like videos just sucked. All of this was mainly because it all relied on daily offline jobs. And then Tiktok came along and showed everybody (including Youtube) just what a bad job they were doing at recommendations. And don't get me started on the IG Reels dumpster fire.

Oh ok, I thought of another one: Messenger. I knew some smart people on Messenger but overall the product and the infra were, again, a dumpster fire.
cletus
·letzten Monat·discuss
If I were the CTO of any of these companies I would be working my butt off to be making an internal version of Claude. Let me explain my reasoning using Google as an example (disclaimer: Xoogler).

Google has a lot of systems to make a very large monorepo manageable so builds and code search don't take forever. The build system is Blaze (on which Bazel is based), which has a Pythonic syntax and was once Python but that hasn't been the case (AFAIK) for over a decade. This means you build a massive digraph of build artifacts. By "large" I mean somewhere between 100M and 1B vertices (guessing). Loading that became a significant problem for a build so there's heavy caching around that. There's also heavy caching around build artifacts (ie Forge).

So, part of the issue with every developer using Claude is that you have a ton of inefficiency becasue everybody has a significant context. And what is context really? It's not too dissimilar to the build graph and/or code search you already have.

So the infra I would be working on would be some kind of "global context" or "context cache". Now a lot of context changes when you do a local change but a lot doesn't. As an ordinary engineer, you aren't generally modifying /base. You're modifying leaf nodes or branches for very few leaf nodes.

The reasons I see to do this are:

1. Cost-savings by deduplication;

2. Speed if context is partially-cached;

3. You avoid issues of sending out your codes to third-parties. In the case of Google or Amazon, if they use Claude at all, they would probably only be using their own clouds so they avoid this. But Uber doesn't have that luxury;

4. You avoid any issues of people using your prompts for responses for training and leaking any potential sensitie information that way;

5. You can use off-peak resources for a lot of this work;

6. You can control resources within your own pervasive resource management (in the case of Google); and

7. You can more easily integrate into internal tooling.

I also think that expanding compute power is the biggest risk to Anthropic (and OpenAI). There's a vast difference between a model you need a cluster of NVidia's finest to run vs one you can run on a Macbook Pro. We aren't there yet on a Macbook Pro but it'll only be a few years we are.
cletus
·vor 2 Monaten·discuss
There's more history than this. Disclaimer: Xoogler (2010-2017).

When I first started the environment you used depended entirely on language. In the C++ and Python space, there was the vim and emacs divide. With Java it was more complicated. Some still used vim/emacs but a lot of people used Eclipse.

Now Eclipse was a real problem at Google because of the source control system. Java IDEs are primarily built to import binaries, specifically jars. In the outside world, these dependencies are managed via Ant (very early days), Maven/Gradle or the like.

At Google there's a mono-repo (Perforce/Piper) and you check out parts of it locally and rely on the rest via a network connection (to SrcFS IIRC, it's been awhile). This was neat because you could edit a file locally and the dependencies would just recompile (via Blaze).

So for Eclipse a whole lot of initialization had to be done and the IDE would fall over. A lot. It had a team of ~10 working on it at one point. Then somebody did a 20% project called magicjar. Magicjar took a Perforce client and built all the dependencies as jars that could be imported directly without parsing the entire source tree (which was usually huge). This made it possible, even preferred, to use IntelliJ, which is what I did. Magicjar was great.

Other people actually made CLion work reasonably well with C++ too. That was nice. This was a much bigger undertaking with many more corner cases just given how C++ works (ie headers and templates).

So checking out a client was relatively heavyweight, even with a minimal local tree. And, if you worked on Google3, you had to do this a lot. You might need to do a config file change. This was the real starting point for Cider because it was way nicer to do config file changes with it.

Obviously I don't know where all this went from there. VS Studio as a Cider frontend? Ok, that was news to me. Engineers being unhappy when things change and when the slightest thing works differently is the least surprising thing I've ever heard.

Oh it's worth adding that in my time many people didn't use Perforce (P4) directly. They used somebody else's project, which was a Git frontend for it, called Git5. I believe it was already being deprecated while I was still there. But Git5 modelled a P4 change as a branch so you could play around with your Git commits locally and then squash them into a single P4 change. I actually liked this a lot.
cletus
·vor 3 Monaten·discuss
I worked at Google a long time ago now during the whole Google+ fiasco. One thing that was super controversial internally was the so-called Real Names policy. For those who don't know or remember, it was Vic Gundotra's idea that people should use their real identities. He kept using this weird example that he didn't want it filled with people named "Dog Turd". I don't know why.

So there was this mysterious black box that decided if your name was "real" or not. At first this didn't support pseudonyms or any kind of anonymity and that's actually really important for any social network. Think of someone seeking help coming to terms with their sexual orientation, gender identity, addiction, eating disorder or whatever. Or simply going against their family's religious wishes. I later worked at Facebook and one thing I'll give them credit for is Groups. FB Groups had an identity that actually couldn't be tied by anyone else to your profile or identity in any other group. That was a good product decision.

Anyway, if your name somehow failed the magic real names filter, your account got banned. Your entire Google account was banned and basically there was no recourse other than knowing someone who worked at the company or making a big enough fuss on Twitter.

Many people, myself included, criticized and protested this decision. You should at least segment Google products. There's absolutely no reason to ban your Gmail account because an automated system decided your Google+ account name wasn't "real". But that feedback was ignored and this was well before the public launch. And the public backlash proved this position correct (IMHO).

But the net effect was that I decided I can't use any other Google product. Let's say a system is launched to find offensive photos and there's a false positive on one of my images in Google Photos. Maybe it's just a hash collision with a known image. And then what? I lose my entire Gmail? Are you kidding me?

It's wild to me that this is still an issue ~15 years later. I think my stance actually isn't strict enough anymore. You probably shouldn't use Gmail at all. I should really find a paid email provider hosted entirely in Europe, preferably Switzerland or some other country with strong pro-user regulation.

So I have no idea if this Gemini story is true or not. I say that because 95% of the things on Reddit are completely made up. But it is plausible. I wouldn't be surprised if it's true. It means I wouldn't use Gemini at all if I used Gmail.
cletus
·vor 4 Monaten·discuss
Story time. I used to work for Facebook (and Google) and lots of games were played around bugs.

At some point the leadership introduced an SLA for high then medium priority bugs. Why? because bugs would sit in queues for years. The result? Bugs would often get downgraded in priority at or close to the SLA. People even wrote automated rules to see if their bugs filed got downgraded to alert them.

Another trick was to throw it back to the user, usually after months, ostensibly to request information, to ask "is this still a problem?" or just adding "could not reproduce". Often you'd get no response. sometimes the person was no longer on the team or with the company. Or they just lost interest or didn't notice. Great, it's off your plate.

If you waited long enough, you could say it was "no longer relevant" because that version of the app or API had been deprecated. It's also a good reason to bounce it back with "is still this relevant?"

Probably the most Machiavellian trick I saw was to merge your bug with another one vaguely similar that you didn't own. Why? Because this was hard to unwind and not always obvious.

Anyone who runs a call center or customer line knows this: you want to throw it back at the customer because a certain percentage will give up. It's a bit like health insurance companies automatically sending a denial for a prior authorization: to make people give up.

I once submitted some clear bugs to a supermarket's app and I got a response asking me to call some 800 number and make a report. My bug report was a complete way to reproduce the issue. I knew what was going on. Somebody simply wanted to mark the issue as "resolved". I'm never going to do that.

I don't think you can trust engineering teams (or, worse, individuals) to "own" bugs. They're not going to want to do them. They need to be owned by a QA team or a program team that will collate similar bugs and verify something is actually fixed.

Google had their own versions of things. IIRC bugs had both a priority and s everity for some reason (they were the same 99% of the time) between 0 and 4. So a standard bug was p2/s2. p0/s0 was the most severe and meant a serious user-facing outage. People would often change a p2/s2 to p3/s3, which basically meant "I'm never going to do this and I will never look at it again".

I've basically given up on filing bug reports because I'm aware of all these games and getting someone to actually pay attention is incredibly difficult. So much of this comes down to stupid organizational-level metrics about bug resolution SLAs and policies.
cletus
·vor 6 Monaten·discuss
So there's some survivor bias here but it's generally not bad advice. You should be focusing on outcomes like improving SLAs, top line metrics and so on. You should be solving user and business problems. That's all good advice. But still this article presumes a lot.

In my experience, managers will naturally partition their reports into three buckets: their stars, their problems and their worker bees. The worker bees tend to be ignored. They're doing fine. They're getting on with whatever they've been told to do or possibly what they've found to do. They're not going to create any problems. The problems are the underperformers. These are people who create problems and/or are at risk of getting a subpar performance rating.

Now there are lots of reasons that someone can be a problem. I tend to believe that any problem just hasn't found the right fit yet and, until proven otherwise, problems are a failure in management. That tends to be a minority view in practice. It's more common to simply throw people in the deep end and sink or swim because that takes much less overhead. You will see this as teams who have a lot of churn but only in part of the team. In particularly toxic environments, savvy managers will game the system by having a sacrificial anode position. They hire someone to take the bad rating they have to give to protect the rest of the team.

And then there are the stars. These are the people you expect to grow and be promoted. More often than not however they are chosen rather than demonstrating their potential. I've seen someone shine when their director is actively trying to sabotage them but that's rare.

Your stars will get the better projects. Your problems will get the worse ones. If a given project is a success or not will largely come down to perception not reality.

The point I'm getting to is that despite all the process put around this at large companies like performance ratings, feedback, calibration, promo committees, etc the majority of all this is vibes based.

So back to the "take my job" advice. If someone is viewed as a star, that's great advice. For anyone else, you might get negative feedback about not doing your actual job, not being a team player and so on. I've seen it happen a million times.

And here's the dirty little secret of it all: this is where the racism, sexism and ableism sneaks in. It's usually not that direct but Stanford grads (as just one example) will tend to vibe with other Stanford grads. They have common experience, probably common professors and so on. Same for MIT. Or CMU. Or UW. Or Waterloo. And so on.

So all of the biases that go into the selection process for those institutions will bleed into the tech space.

And this kind of environment is much worse for anyone on the spectrum because allistic people will be inclined to dislike from the start for no reason and that's going to hurt how they're viewed (ie as a star, a worker bee or a problem) and their performance ratings.

Because all of this is ultimately just a popularity contest with very few exceptions. I've seen multiple people finagle their way to Senior STaff SWE on just vibes.

And all of this gets worse since the tech sector has joined Corporate America in being in permanet layoff mode. The Welchian "up or out" philosophy has taken hold in Big Tech where there are quotas of 5-10% of the workforce have to get subpar ratings every year and that tends to kill their careers at that company. This turns the entire workplace even more into an exercise in social engineering.
cletus
·vor 6 Monaten·discuss
I'm going to pick out 3 points:

> 2. Being right is cheap. Getting to right together is the real work

> 6. Your code doesn’t advocate for you. People do

> 14. If you win every debate, you’re probably accumulating silent resistance

The common thread here is that in large organizations, your impact is largely measured by how much you're liked. It's completely vibes-based. Stack ranking (which Google used to have; not sure if it still does) just codifies popularity.

What's the issue with that? People who are autistic tend to do really badly through no fault of their own. These systems are basically a selection filter for allistic people.

This comes up in PSC ("perf" at Meta, "calibration" elsewhere) where the exact same set of facts can be constructed as a win or a loss and the only difference is vibes. I've seen this time and time again.

In one case I saw a team of 6 go away and do nothing for 6 months then come back and shut down. If they're liked, "we learned a lot". If they're not, "they had no impact".

Years ago Google studied the elements of a successful team and a key element was psychological safety. This [1] seems related but more recent. This was originally done 10-15 years ago. I agree with that. The problem? Permanent layoffs culture, designed entirely to suppress wages, kills pyschological safety and turns survival into a game of being liked and manufacturing impact.

> 18. Most performance wins come from removing work, not adding cleverness

One thing I really appreciated about Google was that it has a very strict style guide and the subset of C++ in particular that you can use is (was?) very limited. At the time, this included "no exceptions", no mutable function arguments and adding templtes had an extremely high bar to be allowed.

Why? To avoid arguments about style issues. That's huge. But also because C++ in particular seemed to attract people who were in love with thier own cleverness. I've seem some horrific uses of templates (not at Google) that made code incredibly difficult to test for very little gain.

> 9. Most “slow” teams are actually misaligned teams

I think this is the most important point but I would generalize it and restate it as: most problems are organizational problems.

At Meta, for example, product teams were incentivized to ship and their impact was measured in metric bumps. But there was no incentive to support what you've already shipped beyond it not blowing up. So in many teams there was a fire and forget approach to filing a bug and forgetting about it, to the point where it became a company priority to have SLAs on old bugs, which caused the inevitable: people just downgrading bug priorities to avoid SLAs.

That's an organizational problem where the participants have figured out that shiping is the only thing they get rewarded for. Things like documentation, code quality and bug fixes were paid lip service to only.

Disclaimer: Xoogler, ex-Facebooker.

[1]: https://www.aristotleperformance.com/post/project-aristotle-...
cletus
·vor 6 Monaten·discuss
The mistake was not having nullability be expressed in the type system.

At Facebook I used their PHP fork Hack a lot and Hack has a really expressive type system where PHP does not. You can express nullability of a type and it defaults to a type being non-nullable, which is the correct default. The type checker was aware of changes too, so:

    function foo(?A $a): void {
      $a->bar(); // compile error, $a could be null
      if ($a is null) {
        return;
      }
      $a->bar(); // not a compiler error because $a is now A not ?A
      if ($a is ChildOfA) {
        $a->childBar(); // not an error, in this scope $a is ChildOfA
      }
    }
Now Hack like Java used type erasure so you could force a null into something non-nullable if you really wanted to but, in practice, this almost never happened. A far bigger problem was dealing with legacy code that was converted with a tool and returned or used the type "mixed", which could be literally anything.

The real problem with Java in particular is you'd end up chaining calls then get the dreaded NullPointerException and have no idea from the error or the logs what was broken from:

   a.b.c.d();
I'm fine with things like Option/Maybe types but to me they solve different problems. They're a way of expressing that you don't want to specify a value or that a value is missing and that's different to something being null (IMHO).
cletus
·vor 6 Monaten·discuss
As an early user of SO [1], I feel reasonably qualified to discuss this issue. Note that I barely posted after 2011 or so so I can't really speak to the current state.

But what I can say is that even back in 2010 it was obvious to me that moderation was a problem, specifically a cultural problem. I'm really talking about the rise of the administrative/bureaucratic class that, if left unchecked, can become absolute poison.

I'm constantly reminded of the Leonard Nimoy voiced line from Civ4: "the bureaucracy is expanding to meet the needs of the expanding bureaucracy". That sums it up exactly. There is a certain type of person who doesn't become a creator of content but rather a moderator of content. These are people who end up as Reddit mods, for example.

Rules and standards are good up to a point but some people forget that those rules and standards serve a purpose and should never become a goal unto themselves. So if the moderators run wild, they'll start creating work for themselves and having debates about what's a repeated question, how questions and answers should be structured, etc.

This manifested as the war of "closed, non-constructive" on SO. Some really good questions were killed this way because the moderators decided on their own that a question had to have a provable answer to avoid flame wars. And this goes back to the rules and standards being a tool not a goal. My stance was (and is) that shouldn't we solve flame wars when they happen rather than going around and "solving" imaginary problems?

I lost that battle. You can argue taht questions like "should I use Javascript or Typescript?" don't belong on SO (as the moderators did). My position was that even though there's no definite answer, somebody can give you a list of strengths and weaknesses and things to consider.

Even something that does have a definite answer like "how do I efficiently code a factorial function?" has multiple but different defensible answers. Even in one language you can have multiple implementations that might, say, be compile-time or runtime.

Another commenter here talked about finding the nearest point on an ellipse and came up with a method they're proud of where there are other methods that would also do the job.

Anyway, I'd occasionally login and see a constant churn on my answers from moderators doing pointless busywork as this month they'd decided something needed to be capitalized or not capitalized.

A perfect example of this kind of thing is Bryan Henderson's war on "comprised of" on Wikipedia [2].

Anyway, I think the core issue of SO was that there was a lot of low-hanging fruit and I got a lot of accepted answers on questions that could never be asked today. You'll also read many anecdotes about people having a negative experience asking questions on SO in later years where their question was immediately closed as, say, a duplicate when the question wasn't a duplicate. The moderator just didn't understand the difference. That sort of thing.

But any mature site ultimately ends with an impossible barrier to entry as newcomers don't know all the cultural rules that have been put in place and they tend to have a negative experience as they get yelled at for not knowing that Rule 11.6.2.7 forbids the kind of question they asked.

[1]: https://stackoverflow.com/users/18393/cletus

[2]: https://www.npr.org/2015/03/12/392568604/dont-you-dare-use-c...
cletus
·vor 6 Monaten·discuss
Imagine you're testing a service to creates, queries and deletes users. A fake version of that service might just be a wrapper on a HashMap keyed by ID. It might have several fields like some personal info, a hashed password, an email address, whether you're verified and so on.

Imagine one of your tests is if the user deletes their account. What pattern of calls should it make? You don't really care other than the record being deleted (or marked as deleted, depending on retention policy) after you're done.

In the mock world you might mock out calls like deleteUserByID and make suer it's called.

In the fake world, you simply check that the user record is deleted (or marked as such) after the test. You don't really care about what sequence of calls made that happen.

That may sound trivial but it gets less trivial the more complex your example is. Imagine instead you want to clear out all users who are marked for deletion. If you think about the SQL for that you might do a DELETE ... WHERE call so your API call might look like that. But if the logic is more complicated? Where if there's a change where EU and NA users have different retention periods or logging requirements so they're suddenly handled differently?

In a mokcing world you would have to change all your expected mocks. In fact, implementing this change might require fixing a ton of tests you don't care about at all and aren't really being broken by the change regardless.

In a fake world, you're testing what the data looks like after you're done, not the specific steps it took to get there.

Now those are pretty simple examples because there's not much to do the arguments used and no return values to speak of. Your code might branch differently based on those values, which then changes what calls to expects and with what values.

You're testing implementation details in a really time-consuming yet brittle way.
cletus
·vor 6 Monaten·discuss
My second project at Google basically killed mocking for me and I've basically never done it since. Two things happened.

The first was that I worked on a rewrite of something (using GWT no less; it was more than a decade ago) and they decided to have a lot of test coverage and test requirements. That's fine but they way it was mandated and implemented, everybody just testing their service and DIed a bunch of mocks in.

The results were entirely predictable. The entire system was incredibly brittle and a service that existed for only 8 weeks behaved like legacy code. You could spend half a day fixing mocks in tests for a 30 minute change just because you switched backend services, changed the order of calls or just ended up calling a given service more times than expected. It was horrible and a complete waste of time.

Even the DI aspect of this was horrible because everything used Guice andd there wer emodules that installed modules that installed modules and modifying those to return mocks in a test environment was a massive effort that typically resulted in having a different environment (and injector) for test code vs production code so what are you actually testing?

The second was that about this time the Java engineers at the company went on a massive boondoggle to decide on whether to use (and mandate) EasyMock vs Mockito. This was additionally a waste of time. Regardless of the relative merits of either, there's really not that much difference. At no point is it worth completely changing your mocking framework in existing code. Who knows how many engineering man-yars were wasted on this.

Mocking encourages bad habits and a false sense of security. The solution is to have dummy versions of services and interfaces that have minimal correct behavior. So you might have a dummy Identity service that does simple lookups on an ID for permissions or metadata. If that's not what you're testing and you just need it to run a test, doing that with a mock is just wrong on so many levels.

I've basically never used mocks since, so much so that I find anyone who is strongly in favor of mocks or has strong opinions on mocking frameworks to be a huge red flag.
cletus
·vor 7 Monaten·discuss
Story time. This has basically nothing to do with this post other than it involves a limit of 10,000 but hey, it's Christmas and I want to tell a story.

I used to work for Facebook and many years ago people noticed you couldn't block certain people but the one that was most public was Mark Zuckerberg. It would just say it failed or something like that. And people would assign malice or just intent to it. But the truth was much funnier.

Most data on Facebook is stored in a custom graph database that basically only has 2 tables that are sharded across thousands of MySQL instances but most almost always accessed via an in-memory write-through cache, also custom. It's not quite a cache because it has functionality built on top of the database that accessing directly wouldn't have.

So a person is an object and following them is an edge. Importantly, many such edges were one-way so it was easy to query if person A followed B but much more difficult to query all the followers of B. This was by design to avoid hot shards.

So I lied when I said there were 2 tables. There was a third that was an optimization that counted certain edges. So if you see "10.7M people follow X" or "136K people like this", it's reading a count, not doing a query.

Now there was another optimization here: only the last 10,000 of (object ID,edge type) were in memory. You generally wanted to avoid dealing with anything older than that because you'd start hitting the database and that was generally a huge problem on a large, live query or update. As an example, it was easy to query the last 10,000 people or pages you've followed.

You should be able to see where this is going. All that had happened was 10,000 people had blocked Mark Zuckerberg. Blocks were another kind of edge that was bidirectional (IIRC). The system just wasn't designed for a situation where more than 10,000 people wanted to block someone.

This got fixed many years ago because somebody came along and build a separate system to handle blocking that didn't have the 10,000 limit. I don't know the implementation details but I can guess. There was a separate piece of reverse-indexing infrastructure for doing queries on one-way edges. I suspect that was used.

Anyway, I love this story because it's funny how a series of technical decisions can lead to behavior and a perception nobody intended.
cletus
·vor 3 Jahren·discuss
Youtube is an outlier but Google generally doesn't mess with success (IME) of substantial acquisitions. Youtube has their own culture (so much so that they call themselves "Youtubers" not "Googlers" and have (had?) their own campus). Android too were deliberately kept separate. Not that it was an acquisition but Chrome too had its own culture and codebase.

Buying things and killing them only seems to happen with smaller talent acquisitions (eg Sparrow, Urchin).
cletus
·vor 3 Jahren·discuss
My belief is that ultimately monopolies are unstable.

Google's engine, which it has been specatacularly successful at, is obviously search. More specifically, it's search advertising. Google is a dominant player in display advertising (eg Google Ad Exchange, AdSense) but, at least when I worked there, these amounted to <10% of AdWords' revenue. They were a sideshow.

Chrome, Android, Maps and Youtube are all key parts of this engine. The latter three were acquisitions and that gets to the key point.

At some point a company becomes too large to innovate because no new business can compete, or will be allowed to compete, with the company's core business.

Google missed the social media boat for this very reason. Google+ came way too late. Google spent billions on this failed effort. The real mistake was not buying Twitter. I mean Google ultimately offered a rumored $6 billion for GroupOn at one point. They dodged a bullet on that one when GroupOn rejected the advance. Rumor also had it Google tried to buy Twitter in ~2010 when Twitter was seeking a $3 billion valuation.

Imagine if Google had slapped down $6 billion to buy Twitter. How much better off would they be?

There is a ton of process to do anything at Google. This matches my experience. And that's an issue but it's not the main issue.
cletus
·vor 4 Jahren·discuss
The paid upgrade model creates some perverse incentives and support headacches. It encourages a company to declare something a major (and thus paid) upgrade0 Years ago, Adobe used to do this with supporting new RAW formats that came out. it would only add them to the newest Photoshop version when there was absolutely no reason they couldn't add it to the RAW plugin for all versions.

This fragments the user base and creates support headaches. If a user has a problem, is it a KP with that version? They won't pay for an upgrade. Are you going to backporta a fix? It might be a little used version. This leads you to having policies that EOL software. Nobody really understands that. The customer gets mad because they paid for the software in 1987 and it should still work.

Subscriptions solve these problems. It can create problems too eg:

1. The Adobe dark pattern model of having to subscribe for a year and hiding the auto-renewal and how to cancel;

2. Once again, the Adobe model of setting the subscription price of basically the sticker price you once paid divided by 12; and

3. Requiring you to be online to monitor your subscription status meaning software that should work offline doesn't.

The gold standard for a good subscription model is Jetbrains.
cletus
·vor 5 Jahren·discuss
So let's talk about NYC as it's a place I know a fair bit about, having lived there for >10 years.

NYC is clearly an expensive place... kind of. Manhattan obviously is really expensive but there are 4 other boroughs plus the Hudson Valley, eastern New Jersey and Long Island that are all within commuting distance.

Even with NYC prices, I content that lower-income workers are significantly better off in NYC than the Bay Area. Let me give you a concrete example. I just went onto Streeteasy and found a 2 bedroom apartment in Astoria for $295k [1]. It's a 30 minute commute to Midtown [2]

Even better, it's by public transit so no need for added expensive of buying, parking, maintaining and putting gas into a car.

You simply won't find anything equivalent in the Bay Area.

> Then again, those markets were booming even before tech workers moved to there.

I don't think that matches the data. Depending on what segment you look at prices in the Bay Area have almost doubled since 2012 [3].

[1]: https://streeteasy.com/building/21_27-33-street-astoria/sale...

[2]: https://goo.gl/maps/dvrUrWX88F1jM6gn9

[3]: https://www.bayareamarketreports.com/trend/3-recessions-2-bu...
cletus
·vor 5 Jahren·discuss
So you see this kind of argument in the current "labour shortage". Some people will say certain businesses can't afford to pay more and they'll fold otherwise.

I personally don't see the business owner earning an income (sometimes a substantial income) as justification for the workers to earn less than a living wage.

It's the same here: there's no good justification for someone commuting plus working 18 hours a day and getting paid for 10 of those hours.
cletus
·vor 5 Jahren·discuss
The dirty little secret of SFBA tech workers is (IMHO) that they're not really liberal. They like to pretend to be and pay lip service to various social causes. They'll vote for the legalization of gay marriage (Prop 8) and recreational cannabis use (Prop 64) and will write checks to the ACLU and pet shelters.

But they'll also vote to protect their investments, being the significant amounts they have tied up in Bay Area housing. And if the campus workers, nurses and teachers have to drive 4 hours a day to get to work, so be it.
cletus
·vor 5 Jahren·discuss
Here's another point to consider: the Trump tax "cuts" in 2017 were in fact a giant middle finger to college-educated workers in coastal blue states, in three major ways:

1. The $200-500k Federal tax bracket actually went up;

2. Loss of the SALT deduction. There are 9 states without state income tax. Most of them are red (Washington is a notable exception). This disproportionately hits blue states; and

3. Reducing the cap for the mortgage deduction, which again only affects expensive states.

We have a hung Senate, essentially. A better description is to say that it is controlled by Charles Koch, who owns Joe Machin and the Republican Party.

So these tax hikes on blue states haven't been rolled back under Biden because of Charles Koch, basically. In the proposed bill, the SALT deduction isn't getting reinstituted, the mortgage cap is the same and the corporate tax cuts (you know, the ones that will trickle down) are only getting partially rolled back.

And even that might not pass.

But what this means is that there is now a huge financial incentive for workers in California and New York in particular to move south. Hell, it was a significant factor in me moving from NYC to Florida, as an example.

But I wonder if the unintended consequence of McConnell's and Trump's giant middle finger to the blue states could be the migration of left-leaning voters to Texas, Florida and even Tennessee and Georgia (GA has a state income tax but Atlanta is cheap compared to CA/NY).

Perhaps Tesla's move is part of that trend.

It would be entertaining, to say the least, if this hastened the political extinction of the party of Trump. The trends were such that Texas is likely to be a battleground state in ~10 years as it is.

I can but hope.
cletus
·vor 5 Jahren·discuss
So, it's obviously hard to define what the Bay Area actually is. The SF to SJ corridor is one definition but that excludes East Bay, which is significant. Probably the best proxy is the SF-SJ-Oakland metro area, which seems to have a population of ~10 million people.

How many of those are tech workers? It's hard to say. Here's one estimate that suggests there were ~400k in each of SF and SJ a few years ago [1].

Some of those will be single or married to other tech workers. Others will have partners outside of tech. Some will have children. I'd say for every person in tech there's probably 1-1.5 other people as a back-of-the-envelope type calculation.

That puts the tech population at around 15-20%, which passes the sniff test (at least for me) and is significant. Obviously not all of those can vote (eg immigrants are represented highly in tech) but many can. So we're talking about a group that could wield a lot of political power.

But they just don't it seems. My personal view is that Norcal tech workers as a whole are just as self-serving as the NIMBYists they like to point the finger at. I suspect that a large number of them are the NIMBYists at this point.

[1]: https://www.bizjournals.com/sanjose/news/2020/09/16/san-jose...