krschultz

In my experience as a VT homeowner we have relatively frequent short outages. It's pretty rural and the weather is brutal. I think the grid doesn't have as much redundancy as denser areas. We had one 3 day outage 2 years ago in the middle of winter which got quite dangerous, but otherwise I haven't had anything more than a few hours.

Also we have propane heat - but I need electricity for the blower and control board. So the electric consumption is pretty minimal, but it is critical.

I tried to signup for this program but the building code gets in the way. You need 3' from both edges of the battery to a window or door. I don't have a wall with 8-9' between windows. The alternative is to build a fire proof room in your house which takes up a lot of space. Ultimately it was not worth it even with all the financial incentives. The rules might seem innocuous but they're a dealbreaker. It's far easier to get a propane or diesel generator installed.

The Highlanders are testing vehicles: https://zoox.com/journal/autonomous-zoox-testing-vehicle

You don't make breaking changes. You provide the new API and the old API at the same time, and absorb the additional complexity as the library owner. Best case scenario everyone migrates to the new API and eventually remove the old one. This sounds onerous, but keep in mind at a certain scale there is no one commit in production at any given time. You could never roll out an atomic breaking change anyway, so going through this process is a reflection of the actual complexity involved.

Because they make more money using their servers for their own products than they would renting them to other people. Meta has an operating margin of 41% AFTER they burn a ton on Reality Labs, while AWS has a 21% margin with more disciplined spending. Social media is a more profitable business than infrastructure.

That's not universally true. The sewer system in my town was overbuilt in anticipation of a development that fell through. That's why sewer / water bonds are typically up for vote separately from property taxes because there's such an interplay with development.

Huh? You have to pay property taxes now and those could end up being too high for subsequent generations to afford. That happens all the time and is a common reason why property gets subdivided. This is simply a question of whether the value of structures on that land should be included.

If anything a pure land value tax should be more predictable than a property tax, I got hit with a major property tax increase and looked into it, the town had calculated the new property tax based on an incorrect square footage and number of bedrooms for my house. After filing an appeal and going to court I got it fixed, but that was a more capricious process than if it was simply based on the value of the land under the house.

Threads is already GDPR compliant, that's not the only regulation the EU has made that covers these kinds of apps.

I would heavily consider this type of system once build times become a major pain point. That often happens somewhere around 20-50 people working in one codebase. So I think this is a problem space for medium sized companies. Truly small companies probably don't need this and should use the standard ecosystem tools, BUT if your team knows how to use it there's little downside in started from a Buck / Bazel. Especially since you get most of the benefit if you have a nice clean DAG of your modules, and that's easy to build at the beginning and hard to refactor into later.

IMO one of the nice things about Buck or Bazel is that once you learn it, switching languages doesn't require you to learn a completely new tool. Obviously the cost of learning it the first time is high and if you are used to one ecosystem may not be worth it. But I'm now on my 3rd different ecosystem that uses Buck/Bazel (Android, iOS, C++) and it's nice to not worry at all about the underlying tools.

It's honestly hard to measure at the scale of Meta. Just making everything compatible with Bazel would be a non-trivial undertaking.

Also that seems an interesting thing an independent person could write about, but whatever claims Meta made on a topic like that would be heavily scrutinized. Benchmarking is notoriously hard to get right and always involves compromises. It's probably not worth making a claim vis a vis a "competitor" and triggering backlash. If it's significantly faster than Bazel that will get figured out eventually. If not the tool really is aimed at Buck1 users upgrading to Buck2 so that is the relevant comparison.

At the time that FB started writing Buck, Bazel was not open source. I believe it did exist as Blaze internally at Google before FB started writing Buck. Facebook open sourced Buck before Google open sourced Blaze as Bazel.

Over time Facebook has been working to align Buck with Bazel, e.g. the conversion to Starlark syntax so tools such as Buildozer work on both systems. I believe Buck2 also now uses the same remote execution APIs as Bazel, but don't quote me on that.

There are fewer forced sellers now that remote work is more common.

I don't think they balked, they failed.

At Meta many engineers tried management and then went back to being an individual contributor. I'm not sure of the exact numbers but it was a very common career path. It did build up empathy for management on the senior IC side and meant that teams didn't get stuck with managers that didn't actually want to be a manager. If the company is not growing headcount this move makes perfect sense.

A question to answer: is the enjoyment coming from actually being the machinist, or is it coming from assembling something you designed? The answer could be either. But if you just want to bring something you designed to physical fruition and you are limited on space then I would recommend finding machine shops that will make what you design for you. This is what Protolabs, Shapeways, Xometry, etc do. You don't need to actually have a 3D printer or laser cutter or CNC mill to get things built. You can probably find a local fabricator too. I found a guy that made handrails and would do random welding jobs, I used to go to his shop for all sorts of different things. Even if you get the money and space to build out a shop, there's a lot of skill to these crafts and people dedicate their whole career to becoming experts in them.

The grinding discs shatter. Wear a full face shield.

I do not think the outcome is only Uber / Lyft but with AI, but if that is the outcome I still think it would be a win. Today supply of Uber / Lyft in my area at off hours is spotty, and that makes it unreliable. I have gotten stuck walking home 2+ miles multiple times in the last year because I couldn't get a ride at any price. That's not a problem in Manhattan, but not everywhere is Manhattan. Driverless cars would be on 24/7/365 so wouldn't have that problem. The more reliable these taxi services are, the more viable it is for people to get rid of their cars.

I also expect long term self driving cars will be safer than humans, and as a person that primarily walks around instead of driving that's a benefit to me even if I'm not in the car.

How many software engineering projects are CRUD apps or yet another ETL pipeline?

For many years my "big question" has been "why do software engineering projects fail at a disproportionally higher rate than other engineering fields?"

Though I have to say the other engineering fields are not doing so hot lately either, so I might have the wrong question.

I'm not at all interested in finance / stock picking but found this to be one of the best walkthroughs of an ML system end-to-end that I've ever read. I'm not in the field of ML but I'm interested in learning more and this was fantastic, thank you.

As an owner of a vacation home and a large donor to homeless charities: this is completely divorced from the reality on the ground. It's a false dichotomy proposed as a way to block solving the problem of limited housing where it's acutely needed.

My ski house in Vermont does absolutely nothing for the homeless people in my neighborhood in New York. If you put someone in that ski house what would it do? Sure it would put a roof over their head, but there are no jobs, no soup kitchens, no homeless resources. They would need a car whereas in New York they can walk and use mass transit. The town in VT is already strapped supporting many in their community (I do charity there as well, and let me tell you it's more dire than much of the New York area).

The solution is to house them here in the New York area where they are (and in fact New York does a better than average job of this).

As for it being a misallocation, I own a $1M apartment in NYC and a $300K house in Vermont. If I just owned a $1.3M apartment in NYC my bills would be exactly the same, there would be 1 fewer "vacant house", and the homeless would still be unhoused. The real misallocation is how much I get paid as a software engineer relative to other professions of similar difficulty. I happen to spend my fun money on a ski house instead of a boat or a bunch of vacations, but there's no moral difference between a vacation home and other leisure spending. So really you are arguing that some people shouldn't have such a surplus when there are homeless people. Maybe that's true, but it's one of the most unpopular positions in American politics and if you are an ally of the homeless it's not a fruitful argument to make.

FB is pretty much on V1 of its GraphQL API with tens of thousands of engineers editing it for over a decade. Every single query is its own version, that's the point. If you want to change the semantics of a field, make a new field and leave the old one for the existing clients. What else would you have to version?

It shifts the complexity to the server side. The additional logic you are describing currently lives on the client, where it's harder to update and likely duplicative across platforms.

Every company I've worked for in the last 10 years had multiple apps across several platforms, each with many versions, all running in production at once. Even if you only care about the next version you are shipping and a handful in production that's a dozen variations.

In a REST paradigm you over fetch because not all of these variations need the same data, or you send less but then the clients thicker because they merge API calls and have divergent presentation logic, or you have a bajillion API versions.

There's often a lot of back and forth between the various teams for each rev of the API.

GraphQL lets the clients drive the definition of the data fetching. That's it.

95% of the criticism of GraphQL is people complaining that GraphQL doesn't solve the problem of preparing the API response for these different requests. While that's true, that's not what it's supposed to provide. Whether you have a REST API with 26 versions or a GraphQL API with 26 variations of query you're going to have to write a backend-for-frontend style service that resolves the results.

GraphQL just standardizes this process.

- It shifts the complexity where it belongs - out of native apps deployed to user's phones and onto the backend that you control. It doesn't eliminate any complexity.

- There's really no need for API versioning in GraphQL. Just keep iterating on the fields.

Are you counting the equity at a large public company to be lottery tickets? Because it's absolutely not. Every quarter a bunch of real money appears in an account with my name on it, that's not a lottery ticket.

Spoken like someone that's never been a manager.

We use the same principle on some of the frameworks I have worked on, it pushes you to make the API more explicit and keep the context localized. That makes codemods easier. This can sometimes lead to a more verbose / less magical API, but IMO at scale the tradeoff is worth it.

FWIW this was ~2015ish, I'm not sure what the state of OpenAPI was at the time.

> Was it simply aggregating results of multiple requests?

Pretty much. The company I was at was an early proponent of microservices so we had to have a service that operated as our entry point to all of it. Thats easy enough, but layering on versioning of the APIs for native apps on different platforms added complexity that definitely didn't seem worth dealing with in our at the time REST paradigm. We did have frameworks that generated clients for different platforms against that API so I'm not even talking about the boilerplate of sending and parsing JSON.