earhart

I thought this was super interesting; it's great to see a solid writeup.

The consumer-side mutex works pretty well, until you take an interrupt while holding it; then, you need to make sure you're using an unfair mutex, or you'll get a lock convoy.

The non-blocking version isn't hard to write, though. IIRC, for the Windows threadpool, I used https://www.cs.rochester.edu/~scott/papers/1996_PODC_queues.... for the implementation.

I'm really impressed by the concurrency analysis tool; again for the threadpool, we used model-based-testing to write tests for every permutation of API calls, but we never got down to the level of testing thread execution permutations; that's amazingly good to see, and really builds confidence in their implementation.

Software has security bugs, and enough people are evil that you will get burned with that approach. I’m a professional in this space, and I really can’t tell whether some random app is going to be evil or not; how is a non-techie supposed to figure it out?

The real problem is that Google’s been unable to either secure Android or prevent malicious apps from showing up even given their locked-down store.

I don’t know how to trust an app. Like, how would I make that decision?

When I used Android, I just didn’t install things unless I really, really wanted them, and they were popular enough that I figured security researchers would likely be looking at them closely. (Which, of course, was a great incentive to keep using Google’s ecosystem for everything.)

I tried iOS a few years ago, and one of the big differences is that I’m a lot more confident about trying random apps; I know there’ll still be shady apps, but Apple’s vetting and the iOS security model give me a lot more confidence. I’ve installed (and paid for) a lot more apps as a result; my phone’s much more usable to me.

Causation isn’t correlation; zip code is easy to measure, but I’d bet it’s not what actually matters.

The startup was vertex.ai; I worked there for a little over two years.

It was very educational (in a good way), despite the uncertainty around paychecks (just from the higher odds of going under at some point down the road). For people who’re in a financial position to handle some paycheck risk, I’d definitely recommend trying a startup.

I did ten years at Microsoft; loved it, but wanted a change, and Google desperately wanted people with VM experience to build GCE.

I was at Google for six years; I had a lot of fun building various parts of cloud, but then at some point realized I didn’t really care a lot about the component I was working on, and looking around, I didn’t see a lot of other projects going on that I really felt passionately about.

I had some savings, and wasn’t really worried about finding •some• other software engineering job in Seattle if that ran low, so I decided to take off to think about what I really wanted to be doing in life. And then a friend reached out to me - he was founding a startup, and was I interested in joining?

So I did an ML startup for a couple of years. It was tremendous fun; lots of work, but I felt very connected to what I was building, why I was building it, &c; it felt good to be really thinking about the product from an end-to-end, “How is this going to delight the customer?” point of view. I think I’d have had to be a director at Google to have the same level of involvement with the entirety of what I was building...

And then, we were bought by Intel. It’s not too different, though - it’s a much bigger company, of course, but I feel pretty connected to the stuff I’m working on; I see and understand the business case, and my role in it. I don’t know that I’ll work at Intel forever, but certainly for the foreseeable future; I’m having fun, and feel pretty fortunate to be working here.