Still seems like a messier workflow and it might leave behind a dozen comments not related to the progress of the ticket.

Can't deny that it takes a long time... Pretty sure that's right.

Yep. I've done both now. Pay and perks are better at FAANG but the work itself is way more boring/annoying

Not even if you test hundreds of pairs to find a match?

> Not even if you test hundreds of pairs to find a match?

Assuming you do find _a_ match, you still need everything else to be in sync across the different temperature(s) that each component will be operating at

Do you make FAANG-tier money though?

No, I don't, assuming you're looking at total comp including stock.

I also don't have crazy hours, stack ranking, mandatory RTO, 6 different levels of OKRs, and all the other bullshit that comes along with a FAANG job.

It’s not hard to make equivalent (or higher) base, but you just lose out on the stock

> just

Or you can just learn a handful of puzzle patterns in exchange for more job opportunities that would have the potential for higher overall pay. Seems like a fair trade to me.

This is a good way to frame it. I have no issue with people who choose to do this, but I choose not to.

It just feels obstinate to me. Most people will jump through all sort of bureaucratic/performative hoops when they're in a job to keep it or angle for promotions/minor raises, but this one that has a much higher average RoI turns them off. If you put your foot down on that sort of thing too then fair enough I suppose.

I have been told that I’m obstinate before :)

To be fair though, I don’t really want a Big Tech job. Several of the FAANGs, especially Facebook, are morally objectionable to me and I would switch careers before working for them. Most others have shitty working conditions with in-office policies, open office layouts, etc, that are detrimental to me getting work done.

So it’s not just about the financial RoI for me.

And I think I’m at least consistent: I’ve never been one to jump through hoops for raises or promotions either.

Why's that? I'm not really sure how DEFLATE works but I can imagine a crappy compression that's like "5 0" means "00000". So if you try to compress "0" you get "1 0" which is longer than the input. In fact, I bet this is true for any well-compressed format. Like zipping a JpegXL image will probably yield something larger. Much larger.. I don't know how you do that.

I'm sure there's a way for them to give enough weight if they really cared enough. I don't think they should or would, but they could stuff the training data with thousands of slight variations if they wanted to or manually give them more importance. This might adversely affect everything else, but that's another story.

I did this, but I used rsync, and you can tell rsync to use the previous ver as the basis so it wouldn't even need to upload everything all over again. Super duper quick to deploy.

I put that in a little bash script so.. I don't know if you call anything that isn't CI "manual" but I don't think it'd be hard to work into some pipeline either.

I kind of miss it honestly.

How does one person talk to another person who named a thing? Well, you can either meet in person and use your mouths, or you can pick up a phone....

(I'm genuinely confused by the "How?" question)

> If a server gets inputs it doesn't recognize

If you just slap in Zod, the server will drop the extra inputs. If you hate Zod, it's not hard to design a similar thing.

> or if client and server disagree that a field is optional or not

Doesn't GQL have the concept of required vs optional fields too? IIUC it's the same problem. You just have to be very diligent about this, not really a way around it. Protobufs went as far as to remove 'required' out of the spec because this was such a common problem. Just don't make things required, ever :-)

> Doesn't GQL have the concept of required vs optional fields too?

Yea, graphql is what I'm referring to.