TideAd

I have a couple quasi-mentors like this. I'm stuck between feeling grateful for what they taught me (a whole lot) and feeling absolutely sure that I will never be that neglectful to a junior dev in my own career as they were with me.

I recently heard that a stale index was the thing that really killed AltaVista.

https://twitter.com/danluu/status/1117859464793583616

Do you have any insight into why that happened?

CockroachDB is nice to use but every database has complexity you have to deal with.

Here's one I ran into recently: if a range has only 1 of 3 replicas online then it will stop accepting traffic for that range until it has 3 replicas again.

(for the folks at home, "range" is a technical term for 512 bit slice of the data - CRDB replicates at the range level)

So, in some code I wrote, I had account for not only 1) the whole DB being unavailable but also 2) just one replica being unavailable (they're different failure modes that say different things about the health of the system).

It's a good behavior! Good for durability. But I had to do some work to deal with it, spend an hour coming up with a solution, etc. There are databases that work at Twitter scale but no there are no silver bullets among those that do. You need full time engineers to manage the complexity and keep it online, or else it could cost the company shitloads of money - I've seen websites of similar scale where a two-hour outage cost them $20 million.

Is that not what we're doing with distributed systems? A lot of the theory & practice of our field is how to elegantly cope with servers dying, data being corrupted, load limits of single machines, etc. We have a lot of constraints.

And there's no possible way not to have some leaky abstractions with this in front of us.

it was "I fucked up"

https://www.forbes.com/sites/stevenehrlich/2022/12/13/exclus...

I believe you can be notified when a collection is imminent. I saw a service use that to remove instances from the load balancer before that happened - super useful for higher-percentile latencies.

> The cost to our world from this behaviour is immense and it is quite frankly indefensible at this point.

This is just neurotic. On what margin is throwing away a microwave destroying the planet? It's not going into the ocean. We're not running out of steel. You have to prioritize things that matter here.

Recycling options for appliances are pretty poor everywhere you go. I live in a major city, and there's exactly 1 store for recycling electronics. It's 25-minute drive. I don't know why we don't have the infrastructure, but we don't, and that's what you'll have to solve.

Most 20-somethings these days would gladly recycle things if there was an easy way. Telling people to use their annoying/cheap/half-broken appliances forever for vague environmental guilt reasons is just not going to work, I'm sorry.

You say 40+ interviews. Is this something you've done? I did 10 last time I was on the market that was about my limit. 40 sounds like it would take inhuman stamina.

Come on, they know that money won't be theirs. I have never heard of a corporation saying "we'll fire this person and distribute their next vest to the rest of the team"! No, it goes into some generic pool. First priority for RSUs is usually new hires.

I can definitely see wanting someone gone. Been there. But everyone probably hopes they get a soft landing and find a job that suits them better (unless the person's a huge asshole, then maybe not)

I mean the answer is that you just feel it out. 1 month is soon enough to wait, 2 months is gray area, 3 months is probably fine. And if it's a huge vest, then you give more leeway.

You're not appealing to some objective rule here. You're thinking about what would look like shitty behavior to the rest of your employees.

Firing people gracefully is a really, really important part your relationship to your employees. It's about whether people feel like they're being respected as professionals or abused like they work in a sweatshop.

at Amazon it means surprising them with a PIP

In many cases, the point of writing the book is getting the book tour.

Ever thought "wow this book really should have just been a blog post"? Well, there is no such thing as a blog post tour.

Always a 50/50 shot whether typing three tick marks ``` will do what I want, or do nothing.

When I was at Microsoft circa 2018, our team had a senior engineer whose primary job was doing manual validation of releases. That and keeping a single custom legacy build server running.

For a tech company in Seattle, $80k is not exactly great pay.

Do you understand the basic reasons why?

Developers are on the hook for bad code and complexity. Rushed code makes feature work take longer, it makes working more irritating, and creates operational work. Everyone is burned by a team that does these things poorly at some point in their career and it drains the life out of you.

They need to trust that you'll schedule time to go back and do things correctly. Clean up technical debt, nail down all the requirements, etc.; you don't want to be jumping from MVP to MVP. Maybe you do this well, I don't know. But you need to understand the motivations and incentives of the devs you work with better or you're going to be fighting them constantly.

There might be 1% of the population with the expertise to build it from source, and even most of them would prefer to just pay $15.

PIP culture at Amazon comes from the very top. Bezos was a huge fan of it and so is the new CEO. There's no way your friend is going to be able to fight institutional power like that.

Money is a tool for many things in life. Here are some things you get at $250k that you don't at $50k in a cheap place:

- Have enough financial security to know that you can weather most emergencies, medical bills, etc.

- Tip well and support your friends' businesses

- Retire before you're too old to enjoy it. Or take a sabbatical.

- Do good. Let's say you want to give $10k to charity. Very doable on $250k, but asking a lot on $50k.

- Buy more ethical products (whatever this means to you)

- Avoid a lot of the soul-crushing bullshit of everyday life. Car doesn't run? Landlord is trying to screw you? You can solve those problems with money.

There are a lot of rich assholes out there, but they would have been assholes even if they were poor. You won't turn into one if you have a different outlook.

I mean, would you rather my company have the money? As a software engineer you have the ability to take a lot of money from a lot of soulless bureaucracies and do whatever you want with it. You could do a bunch of good with it if you want. We're on the labor side of this equation, we should be asking for as much as we can get.

The .NET Framework HttpClient was considered really slow by the .NET team themselves. In .NET Core they scrapped the old code entirely so they could build a good one.

Even if there's just a 10% chance of this, the OP should get ready for a genuine fight from these people (i.e. he needs a lawyer). They could be trying to protect themselves from jail time.

Do you still have to go through a full interview loop?

FAANG interviews are best approached as iterative steps. That is: expect that you'll fail the majority of them (this is true for most capable people) and keep doing them as regularly as you can until you get an offer.

I bet most engineers at these companies did not get an offer on their first 3 tries. This is not a big deal at all because they'll let you interview over and over after cool-off periods.

I think he threw this background check thing out there as a red herring. You're telling me that a standard background check for a candidate succeeded for Google and two other big tech companies but not Stripe?

No, what probably happened is that the job opening was for a particular team, but the team got re-orged and some exec took the headcount away from them.

Writing High Performance .NET Code (https://www.writinghighperf.net/) has a chapter on this. In C#, time spent collecting depends on the number of still-living objects. That means you want objects you allocate to be short-lived (dead by the time GC happens) or to live forever (they go to the gen 2 heap and stay there). The book suggests object pooling when the lifetime of objects is between those two extremes, or when objects are big enough for the Large Object Heap.

But at the end of the section, the book says:

  I do not usually run to pooling as a default solution. As a general-purpose mechanism, it is clunky and error-prone. However, you may find that your application will benefit from pooling of just a few types.

What kind of things do you pool in Unity?

My team has issues deploying builds to test machines. It's like 15 steps and takes an hour. The tooling is atrocious and recently got even worse.

We eventually found the team responsible for this (the org structure is hard to penetrate because no one answers emails). They said they had no idea anyone was dissatisfied. Then they said that it was a low priority so they didn't care and nothing would be done.

In my experience, you can usually convince an engineer that their stuff has a problem and they need to fix it. But it's often impossible to convince management if they aren't on the hook for user satisfaction.

Probably the claim of 0.2% IFR. I don't know what the latest IFR estimates are, but it can't be that low: for example, more than 0.2% of Americans have died from Covid, and many Americans have never been infected.

I bet the managers who are running IPv4-only places know what's coming, they just hope to get lucky and see it delayed long enough that they get another job someone else is holding the bag.

I've worked on some legacy code in my time but debugging this thing has gotta be completely nuts.