kevan

>adjusted the estimated useful life of our servers from three years to four years and the estimated useful life of certain network equipment from three years to five years

Another sign of the slowing advancement in CPU power/performance?

Anyone have insight on whether this level of performance incentive compensation was more or less common 20 years ago than now and how to credibly negotiate for them as an employee instead of leaving and contracting on value pricing? I'm afraid the answer is "if you have to ask..." Is it mostly just executives or are high level ICs ever successful here? In the public arena I only really hear about it happening for strategic acquihires and execs.

As much as everyone loves to complain about red tape, building codes have a lot of useful info. Even if you're not going to pull permits (at your own risk) it's useful to be aware of what code requires and why. Specific examples from the post:

* Plywood thickness required for floor decking

* Min roof slope for asphalt shingles

* Drip edge, where it's required and how to install it

* Roof drainage - probably doesn't matter because California but as a general rule you never want to channel water towards your foundation.

In the grand scheme these are relatively minor. They'll probably need to demolish the thing when they sell the house long before the roof slope causes water issues.

I'd guess those exterior walls are 6-12" thick poured concrete, similar to this[1]. You can see in the 6th picture almost all of the missing wall is still there and intact, it's just lying flat on the ground. In the 12th picture you can see how thick they are compared to car wheels nearby.

[1] https://www.mppengineers.com/index_files/Page369.htm

An interesting contrast: for as long as I can remember (I've been at Amazon for 5 years) we've had burner AWS accounts available for testing/prototyping stuff that get auto-closed after a week. Many devs, myself included, also have a personal long-lived AWS account for infra stacks of the services we're working on. These accounts get billed directly to the team's fleet budget. As long as you're using them for work-related things (i.e. not mining crypto or hosting a minecraft server) and not racking up massive bills without a good reason then it's fine.

My guess is something related to service mesh/discovery. If that goes down, deployment infra also depends on it, and you don't have a solid black start protocol then you're in for a very bad week.

No one will argue that opaque identifiers is a sufficient security control but it's (slightly) better than nothing, at least it would've stopped a naive enumeration approach to scrape everything. Don't get distracted by that part, the main reason is many companies wouldn't want to publicly post a dashboard of how many users/entities/widgets they have for all to see but exposing sequential identifiers basically does that.

I'd implement a good cost attribution strategy before trying a gatekeeping approach. Companies generally have at least semi-functional mechanisms for managing department budgets. Once there's a clear picture how much each service/webapp/product costs to run then they can feed that into the existing budget infra and let things shake out.

Until you know both halves of the ROI calculation it's difficult to focus effort on trimming the right things. e.g. It seems silly for a team to spend $2k/mo on naive/managed solutions for simple things but maybe it's worth it if it helps them avoid hiring another $10k+/mo engineer.

Some of the moments I enjoy the most are where I sit in a room with product and design for an hour and we riff on a design. The feedback loops between disciplines are where the magic happens and talking through things in person usually results in a lot of improvement fast.

I don't think you could anonymize chat messages with any level of confidence. Not an expert in this but my team generally has to treat free-text fields at the highest level of data classification because they could contain anything. The best you could do is try to mask obvious PII like phone number patterns but that's definitely not sufficient.

For anyone looking to research that, this[1] video aggregated some source studies. tl;dw: estimates are between 2-17 metric tons of CO2 emissions to produce a new car (SUVs are more). And during operation an average car emits 5.2 metric tons of CO2 per yer.

For a concrete example, a 2021 Toyota Camry Hybrid at 52mpg emits 170g/mile of CO2[2]. A 2000 Camry 4cl at 24mpg emits 340g/mile[3]. Assuming you drive an average 13,500 miles/year[4] the break-even point for CO2 is about 4.5 years.

If you have the 2000 V6 Camry at 20mpg then the break-even is closer to 2.5 years.

[1] https://www.youtube.com/watch?v=6RhtiPefVzM [2] https://www.fueleconomy.gov/feg/Find.do?action=sbs&id=43307 [3] https://www.fueleconomy.gov/feg/Find.do?action=sbs&id=15965 [4] https://www.caranddriver.com/research/a32880477/average-mile...

Fair, it wasn't a great example.

>We don't explicitly tag all our premises

True but we should aim to tag more of them in business writing. It's helpful to clearly state them so 1. You as the writer are crystal clear on the assumptions you're making, and 2. if there's any disagreement on premises you can resolve it before you spend any time discussing which course of action to take.

>>this area is most likely to value efficiency

Agreed. The general style values simple sentences which helps reading speed and comprehension, especially for audiences that don't share your native language. And it reduces fluff. Adverbs, for example, generally don't help make a point in business writing - data does.

See the example in that last sentence? I snuck a premise instead of stating it as a hypothesis or providing data to support it. At best that causes confusion for the reader and at worst it can mislead people that aren't carefully watching out for pitfalls like that.

Make a dark web[1] site? Basically make it impossible to link what you're doing to who your infra providers/internet connections are.

[1] https://en.wikipedia.org/wiki/Dark_web

If I remember right from The Everything Store Amazon hasn't had a COO title since a rough experience with Galli in 99-00.

Smart grid is a buzzword but this is exactly what it's good for. Spreading peak usage out. For example, today I get a discount on my electric because my power company has the option to turn my AC off for X time during hot days to lower the grid's peak load. The tech is already here and a lot of EV charging will fit well into that model, especially commuters that don't need their whole range every day. Plenty of people would opt in to "at least one full charge every 3 days" type of plans.

> If you can describe an acceptable algorithm with enough detail in words, you can code it.

I wouldn't take that for granted. It's easy to gloss over details and edge cases when talking through an algorithm and it's not apparent until you actually write the code. Similar things happen when discussing things in meetings vs writing a formal document. I've interviewed plenty of people that were able to quickly come up with algorithms to solve a problem but really struggled to translate them into code.

The difference might not be as large as you think: https://www.nytimes.com/interactive/2019/06/14/opinion/bluet...

>[Musk] hailed Tesla’s structural battery as a “revolution” in engineering—but for some battery researchers, Musk’s future looked a lot like the past.

>“He’s essentially doing something that we did 10 years ago,” says Emile Greenhalgh, a materials scientist at Imperial College London

Doing something under research conditions and doing it in a mass-produced commercial product are separate accomplishments. Both are important and impressive and should be celebrated.

Enter "windowed user-uptime"[1], which helps differentiate between these conditions.

[1] https://www.usenix.org/conference/nsdi20/presentation/hauer

An example of this from my experience: I was working on a side project and ended up doing 2 major version upgrades on a core JS library (maybe routing?) before I even completed the MVP. Definitely not what I wanted to spend my time on at that point.

>> If you don't know what you're doing you will shoot yourself in the foot.

Can confirm. My team of mostly fullstack devs that prefer backend ran into lots of issues with too much freedom in Mithril.

Disclaimer: I work at Amazon, views are my own.

Delivery trucks: 100,000 trucks at $70k each = $7 billion investment over 5 years. [1]

Datacenters: 80% renewable energy by 2024, 100% by 2030 [2]

For boxes, I'd agree that there's a lot of room for improvement in reduction in cardboard use and packaging reuse.

Everyone should come to their own conclusions about whether companies are doing enough in each area. For delivery trucks in particular I'd call the investments happening there much more than "spare change".

[1] https://www.theverge.com/2019/9/19/20873947/amazon-electric-... [2] https://blog.aboutamazon.com/sustainability/reducing-carbon-...

Yes, I use one daily and haven't had any issues.

Seems like you're looking at this through the lens of a single system that could submit a query to a single database and get all the data it needs. From that perspective GraphQL is definitely an extra layer that probably doesn't make sense. But even then there's still some value in letting the client specify the shape of the the data it needs and having client SDKs (there's definitely non-GraphQL ways to achieve these too).

My impression is GraphQL starts to shine when you have multiple backend systems, probably separated based on your org chart, and the frontend team needs to stitch them together for cohesive UX. The benchmark isn't absolute performance here, it's whether it performs better than the poor mobile app making a dozen separate API calls to different backends to stitch together a view.

Heads up, ACLU donations are only tax deductible if you donate to the foundation side[1].

[1] https://action.aclu.org/give/make-tax-deductible-gift-aclu-f...

A bit of a translation barrier so I'm not positive but the company advocating this appears to be an agency that builds things for multiple clients. For that case it makes more sense to split out capabilities like that so they can easily pull them in like Lego blocks to other projects. For everyone else I'd advocate starting with a monolith until you need to split things.

In a world where a critical mass of companies that want top talent support full WFH I don't think this will be a huge issue. Google and Amazon already have offices around the country and Amazon's premium for SF/NYC vs all other markets only appears to be ~10%.

Silent reading time in my experience. 5-10m of a 30m meeting, and up to 30m for longer design reviews or program docs. I personally love the format but I know some people get tired of writing so much.

Think about where you need fault boundaries (e.g. cellular, zonal, regional, global) and match your account structure to that if possible. In practice that usually means one account per cell/zone/region per environment (test/prod).