> The problem is more likely a lack of prioritization at the leadership level.
Great. If you're in leadership why would you prioritize a feature making it easier for people to leave your platform when you could instead prioritize a new feature that might generate value for the company?
There's no incentive to make Takeout any better than it is today.
> People can absolutely get promoted for improving products, even if those products don't make the company money.
Yeah, but there better be a high-up patron for these products because Google is notoriously stingy with promo.
Source: quit Google right after L3->L4 because another company was willing to offer me an extra $200k/yr and L5. I've since been promoted at THAT job, and am now looking again because they gave me a raise to the bottom of the next band and that's dumb.
Not sure why that was your takeaway. Much more likely that he feels that it's dumb he was promoted and put at the bottom of the band by default, regardless of his performance. How large the raise is shouldn't have any impact on this.
> There’s a limit to how many large raises you can give if you intend to give x% for the rest of time.
The tl;dr for this is that if the company makes getting paid a market rate and promoted internally more difficult than just interviewing, they should expect people to just leave.
I'm really not sure how the economics of this work out. Obviously Google has a much easier time swapping engineers in and out (it's responsible for basically everything that people hate about the company both internally and externally) but there are still specific teams where engineers leaving represents significant knowledge loss.
Hell, companies that DON'T follow the same engineering practices that let Google hotswap engineers still do this and there's no way it doesn't have significant hidden costs for them.
Yeah, I didn’t mean to say it’s actually impossible, but if you are at 200k+ and more likely towards 300k/year given the information, you are already at the top of the market for most positions (that I’m aware of).
If you still expect 200k raises in such a position you are likely in for a bad time (nothing is guaranteed though, you might get lucky).
> are already at the top of the market for most positions (that I’m aware of).
This is not even remotely close to true for high-paying SWE jobs in the Bay, and the part of me that grew up in the middle of nowhere still has a hard time believing it.
Staff engineers make between $500k to $1M a year. My first year at Google I was sat in a row of absurdly high-level engineers, many of whom made even more.
Why are randos allowed to bill you directly if you didn't sign a contract with them? Shouldn't anyone working at the hospital be under contract with that hospital? Why did the hospital share your personal information with those people without your explicit consent?
It still costs them to do this because they have to do the paperwork to handle it, the meetings to decide what to do, the confusion that will come from this, and the opportunity cost of these courses, as well as the bad publicity that will come from this announcement that the group doing this will of course release to social media.
Walk me through this interaction. Do I search your team’s chats for that one time the intern found your build was flaky, or do I take to YAQS to discuss my build failure? Because the interaction is going to go like this:
Me: I’m trying to build //big/important/project, but I’m getting this error on my Mac: “GShoe 1.3 required, but not found.” I depend on it here in my BUILD file: cl/42069. Can someone help me?
A: We deprecated GShoe last year, what are you trying to do? This isn’t something we support. Say, who are you? Don’t you work in a completely different org? We do all our builds on Cloudtop anyways…
Me: I was just trying to get acquainted with the code, this GShoe integration is something that I was interested in playing with.
A: Wait, this isn’t even your job? Hang on, why does your CL add butts.txt?
Me: Uh, I’m doing a thing…for Memegen?
A: …
More seriously though, checking your chats is something I can do myself without imposing myself on you, and it includes basically everything you’ve ever talked about rather than just what you see fit to publish and stand behind. I don’t need to have to wait until I’m stuck enough to ask a question, make sure you understand what I want, nor do I have to argue with you whether what I’m doing is appropriate or not. Or, more likely, I’m not going to get anyone spending time to reply anyways, because your promo committee is not going to search you on MOMA to see how many people you made happy online. So I’d really rather just trawl your chats and send you back documentation or questions based on that rather than you taking a moral stance that deleting your chat history means my life is better or easier.
Unlike SO, it's common to have very situation-specific questions posted on YAQS. In fact, my team preferred random one-off questions to go through YAQS (our contact golink pointed you to a monitored YAQS queue) precisely because they're much more searchable (and scalable) than point-to-point chats.
So yes, searching for your GShoe error, and (assuming you found nothing) asking about it on YAQS is not a bad way to get help from some random faraway team.
I suppose it's partially because most team chats are locked down (invite-only). In a company with a reasonably open slack, you might be able to ask in #gshoe-team or search it for relevant conversations, but not at Google in my experience - and this is setting aside the issue of message retention.
BTW, I agree 24h retention was truly ridiculous. Most of my colleagues hated it - fortunately (probably as a result of this legal case!) they disabled it and now the default is 30d everywhere.
Regarding promo, community contributions are still very much an expectation. Being active on YAQS counts toward that. True, the promo committee isn't going to go looking for it, so your manager needs to agree YAQS is a level-appropriate community contribution and include that in your promo packet.
Disclosure: I left Google like, a couple weeks ago
When someone finds a problem, you raise a bug with reproduction steps, then either fix it or put it in the backlog. Even if it is a document bug. This way anyone - even people not in that chat - can find it.
This is normal operating procedure everywhere: write stuff down. It was how everyone did things before chat was digital, and how they do now too.
If people are relying on searching chat history for how to fix things or get things working, then you are working at a cowboy outfit where quality must suck. I am not saying google the ideal here - I have no insider knowledge there - but fuck dude using chat history to document and maintain your system? Jesus.
Having joined a company that uses Slack for the first time it was crazy how good it was on searching for issues that other people had. I can quite literally copy and paste the error message above and see other people that had the same issue and how it got solved or not on a thread. I can also bump the thread or go to the channel or reach out to who answered.
It’s pretty great and one of the amazing things on having a lot as chat, it also allows you to easily reach out to anyone very quickly and feels more personal than a ticket in some archaic bug system that becomes a black hole after it gets introduced.
Be careful with your assumptions - it’s not like Google has created much of value in the past N years with its current culture, its original culture (book how Google works) seems much more like the cowboy you criticize
You can do an automatic upgrade thing, where you recognise old formats and upgrade them on the fly. Possibly with a window on it where at sufficient age people need to run their elderly code through multiple upgrade cycles.
Or you can declare it an unstable interface and it's on the user to deal with it changing over time.
Or you can just leave it accessible without excessive work, but not document it, and then it's very obviously on the external tool to deal with the impedance matching.
Except then there's no parallelism since you're only building one file. Ideally you'd split it into N files to take advantage of multiple cores, but then you have to decide how to split it...
Right. My rule of thumb would be "one implementation file per system", or what would be called a "module" in other languages. So that a moderately complex code base ends up with a about a couple dozen source files to build.
And each system should only have a single 'public interface header' to keep the number of cross-system include dependencies low.
This just sounds like an inefficiency in Google Docs. Native software can also be inefficient, even if it's written in C or asm, if the data structures or algorithms used can't handle certain types of data well. Just in this case, the native software seems to be able to handle that file better.
