codemac

Nah, you're pretty far off in terms of population numbers at FAANG. Amazon's levels are largely L-1 most places in terms of comp (aka aws L7 gets paid G L6), and 7+ at Meta is ~1% of the company's employees, and even less of it's SWE.

Amazon and Microsoft also have less "alignment" at various levels compared to silicon valley due to literal geographic and historical reasons. Principal SWE at AWS is probably ~L6 at G in my experience. Obviously there are always outliers in all directions.

Markdown has lots of syntax from irc/email that folks have been using for decades. The popularity is also due this, it was partially a refinement rather than invented.

This is also why the parsing ambiguity/backtracking ends up occurring - humans can read plaintext and do pattern matching with context/attention whereas parsing algorithms have a hard time.

Yeah I didn't have good data sources, and took shortcuts on the math.

I guess it just doesn't look bad to me in terms of their real estate, thanks for pointing me to these better data sources.

At 2.7% that's 2.7% and .7% growth faster than wages.

Let's look at the bay's wage growth[0]: 11% (or ~1%/yr) from 2010-2020, but they removed CPI-U inflation[1], so it's something higher (annual was ~1-3% in that time period). Which puts the bay area housing at 5%+ higher growth, 2x to 7x worse than Spain.

So, once again - Spain is doing well when it comes to housing prices. Tourism frustrates locals because they think it's increased their housing costs wildly - but in fact it's because their economy is switching to a tourist economy unless they find an industry to grow.

[0]: https://bayareaequityatlas.org/indicators/income-growth?year... [1]: https://data.bls.gov/timeseries/CUUR0000SA0&output_view=pct_...

You can price this relatively quickly, and see that it's probably not worth it.

~1 week outage once every ~5 years, let's say you lose 100% of revenue that week, that's 0.38% of revenue. Now most likely they're not losing 100% of revenue, demand for cars is not very elastic... it starts to get pointless all around.

Which is frustrating for consumers, but the profit for perfection isn't usually there.

For comparison, 2012-2019 in SF was 88% growth over 7 years, or >9% year over year growth.

This sounds silly.

70% is ~5.4% yearly, 40% is 3.4% growth yearly. Seems, fine?

These are incredibly reasonable growth rates. Am I missing something?

Any great alternative options?

I have used this obsessively for many years, and removing the web version (and requiring device->device transitions) makes my phone a spof for this data I truly like to keep.

No, the endmyopia stuff specifically rejects the bates methods (which include staring at the sun?? "palming"??).

Mostly it focuses on learning to focus at the edge of what you currently can at a distance, and then as you improve getting lighter and lighter prescriptions. I got as far as -1.5 better, but now sit at around -1 better. Also ensuring lots of super bright outdoor environments, and focusing at a distance regularly.

Whether it's a cure or studied well, I dunno. I just encourage folks to try it out if it helps them. I have an astigmatism as well, and I haven't seen any improvement there. So definitely not a panacea.

Take myopia into your own hands, is my best suggestion. Communities/movements like endmyopia (and many other forums) help understand what you can do.

Unfortunately I haven't found an easy way to keep up with the exercises that really improve things. If anyone has a way to make them easier to accidentally do, would love to know.

This is specifically covered in cases like Midler v. Ford, and legally it matters what the use is for. If it's for parody/etc it's completely different from attempting to impersonate and convince customers it is someone else.

martin's beach :(

Drives have warranties, after which the manufacturer doesn't make any claims about it's durability. This could put your fleet at wild and significant risk if things start hitting a wall and failing en masse. You may not be able to repair away if as you're repairing the data you're copying to yet another dying drive.

So you have usually a lifetime of drive tput and start/stop values you want to stay under, and depending on how accurate your data is for each drive you may push beyond the drive warranties. But you will generally stop before the drive actually fails.

There's probably a financial argument here related to the same money invested, but we all know folks aren't investing in the difference - they're buying more and other junk.

I wonder how many "minimalists" will go to a church of stuff.

This is something I regularly confuse myself on. As I start to appreciate high quality things too much, a materialistic spiral begins. AT some point you're watching a 35 minute video on someone's top 10 favorite EDC items.

Is there a good way to appreciate stuff without making my life about stuff?

If my actual doctor responded to my messages within some SLA (2 days?) then I'm more than happy to pay much more.

Now a days what happens is I send a message with photos or many details, and some poor nurse who is assigned message triage is going through many and responds with generic pointless text for my issue.

Then I get charged $15.

As someone who moved from google3 -> fbcode in the last few years, I think there are weird upsides AND downsides to having async code littered through your C++ (aka co_yield, co_return, co_await, etc).

The advantage, compared to the internal stuff google3 was using, was that as you read code, the async nature of various parts was obvious. Some programmers at G would spend entire quarters+ not knowing what the threading model was, and cause serious bugs in retrospect.

The disadvantage is actually much dumber - a lot of code "could" be async, and over time becomes entirely async because that's the mode the programmer is in when writing the program.

The choice to use a spinlock vs. a mutex w/yields should be one based on the size of the critical section and the threading going on at the time. Unfortunately to make code more readable/uniform/etc you end up with entire projects doing one or the other.

I'd love to learn more about language implementations of threading that do not default either way, but instead could take a profile of the previous run, and make the next run more optimal, without having to change the code or causing bugs.

The Mochary Method I found is much better for folks managing other managers. If you manage individual contributors with a lot of these ideas (e.g. meetings start on time), you'll definitely have a hard time.

His writing vs talking stuff though is truly great, and I changed how I run many meetings through it.

It's great for historical research though. It's one of the few pieces of documentation that will live with the code forever. github and other forms of centralization are not open data formats that folks trivially backup/convert/carry forward. They usually leave the data behind if they move the project somewhere else.

So no, I don't think it helps the current community much either. But it helps the debugger years later.

Same happened at Meta for the 2023 "layoff moments".

The labor market is tough, the attrition you speak of did not happen at Meta. And that's for SWEs who have a lot of potential employers.

> You don't actually need to automatically stop 12 year Olds from using your music in the background of their minecraft video to turn a profit.

To clarify, whether or not you can as an organization turn a profit, is whether or not you get to own a piece of IP? How much profit is an owner of IP allowed to have? How much should an artist get paid? I don't think I could ever limit/define that.

I don't think that's reasonable.

If you're a tiny rights holder, you may have produced a single song and are trying to make sure others pay you for use - but you may not be able to afford or understand what legal review you need.

If you're a major rights holder, you may have so much content to protect that is so wildly popular it is impossible to review manually. But automated review with 100% accuracy is not possible.

DMCA in many cases is not fair, but I don't think we as a global society have much of a shared view of how to handle digital creative content. Ease of digital replication doesn't match how much we generally value creative content.

Is fastmail in your mind a megacorp?

Most things you said do not seem to relate to a small company with ~400 people according to linkedin.

> [top down control] drives away the most capable, creative problem solvers [..]

Eh, I think it's the lack of execution that drives them away, in fact if you're not executing many times it's because they're not even there.

This is moving the previous flyspray issue tracker to gitlab. It's not like they were on github before.

There is some crazy stuff in these volunteer positions: https://www.volunteer.gov/s/volunteer-opportunity/a093d00000...

    Volunteers are expected to contribute a minimum of three 8-hour shifts per week (8:45AM-5:15PM) with a half hour lunch for a period of three to four months.
    
    Weekend availability is required.
    
    Consecutive days off are offered, except in unusual circumstances.

Days off are offered? lol

> As a small nonprofit organization, we cannot afford to purchase all of the physical computers that are necessary to support everyone who relies on Signal while also placing them in independent data centers around the world.

This is really the crux of the problem. ~$3M of servers per year is more than enough to start purchasing hardware, I wish there were easier ways for people like me to participate and help Signal on the cheap.

As someone who participated in the builds they complain about being expensive (and ignoring their , I don't think it's a function of centralization or "troubling" as much as it is practical. Meta, Google, etc all have many billions they could be saving if they could figure out how to make it cheaper too.

It's a classic "dev tooling" play that struggles in downturns.

- Company wants to save money, tells team they're cancelling service that costs them $20k/month to observe their production env.

- Dev team starts building small parts they need anyways, chews up significant engineering resources.

- Company now pays more for highly custom solution no one can compete with.

If the company ends up being successful, they'll probably point to all their custom stuff as why. If they end up failing they'll talk about all the boondoggles they went on. This replays so much.

It always cracks me up how Google is simultaneously the most web-based company in the world, but their internal political landscape was (Infra, Search, Ads) > everything else. This leads to infra swe writing stupid CLIs all day, rather than having any literal buttons. Things were changing a lot by the time I left though.

I do think Google should be more open about their internal outages. This one in particular was very famous internally.

Somehow real estate gets away with it, and they have even more fungible contents!