kevan

  $ sudo softwareupdate --reset-ignored

That will clear all ignored updates. From the CLI docs it doesn't look like there's a way to do it individually but there's probably a plist somewhere you could modify.

I can only speak to my own experience but I usually work 40hrs/week and I got promoted last quarter. The office is usually completely empty by 6pm in Minneapolis. SDE at Amazon, opinions are my own, yada yada yada

It's not really relevant to the overall point and I know it's fuzzy estimates anyways but there's a mixup in stocks and flows. linked Quora source says:

>L6 is staff engineer. Only about 15% of Google engineers are at this level or higher

And the post:

>People who make it to Staff engineer at Google per year: 1,875

I'm not sure about google but at Amazon there's definitely not that many people making it to principal/staff every year.

Loss aversion[1] describes the phenomenon pretty well:

> Humans may be hardwired to be loss averse due to asymmetric evolutionary pressure on losses and gains: for an organism operating close to the edge of survival, the loss of a day's food could cause death, whereas the gain of an extra day's food would not cause an extra day of life (unless the food could be easily and effectively stored).

For lots of companies an accidental over-use of tens or hundreds of thousands of dollars is an annoyance, but for a single person that could bankrupt them. I generally avoid programmatically interacting with cloud providers on my own time for exactly this reason. One mistake in a loop can get expensive fast.

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

>I will say that ideas are generally far less valuable than a first customer. My readers told me time and time again that they wanted to be connected to someone who would pay for the idea.

DemandRush[1] had this model. You'd post ideas along with how much you were willing to pay for it. It looks like the website[2] was shut down sometime in 2019.

[1] https://www.producthunt.com/posts/demandrush [1] https://www.demandrush.com/

For anyone else who, like me, is prone to the excitement of new company ideas and has a tendency to gloss over questions like "is it even possible to monetize this?" I'd recommend reading Disciplined Entrepreneurship. It's not the One True Way but the steps they recommend cover a lot of questions that you should think about during the process.

I guess it depends on what your definition of success is. I still average around 40 hours/week in the office as an SDE 3 at Amazon. I could probably advance a bit faster by putting in more hours but I'm happy with the pace so far.

I think there's a lot of hustle porn culture in tech, especially around the entry level where people brag about how many hours per week they spend leetcoding. This creates an unrealistic perception that everyone is always working themselves to the bone. They're not, my last company even did half day Fridays during the summer.

Start with the basics. Read a business writing book, articles, or take a course on it. Even a one-hour course will teach you something new. Beyond that, some things that help me address my weak spots:

1. Make sure your first paragraph or executive summary answers the questions: Why does this doc exist? Who is the expected audience? What actions or decisions does the author expect from the audience after reading the doc?

2. Run things through an analyzer like Hemingway[1]. It'll point out obvious things to fix.

3. Do a reverse-thesaurus editing pass. Remove adjectives and flowery language where possible. Challenge yourself to lower the reading level. Even if your audience has PhDs they'll read and comprehend simple language faster.

4. Do an editing pass for missing numbers. Vague language, unsupported assertions, and missing quantities make arguments easy to refute. Look for words like "many", "most", "a lot", "major" "severe" "large" and replace them with hard numbers where possible.

5. Do an editing pass for "So, what?" and remove anything that isn't necessary to support your core argument or purpose. Assume your audience is smart but has very little time. Too much detail will make them start to skim and miss things. Appendixes are your friend here. Leave links to appendixes for readers that have questions or want more detail.

6. Nothing beats a human reviewer. Professional writers have editors too.

[1] http://www.hemingwayapp.com/

Amazon has a very strong written culture (search for 1 pagers and 6 pagers). To be effective at higher levels in any role you need to be good at it.

I'm really glad this is public now, really good experience-driven (often straight from major post-mortems) recommendations here.

As an individual you don't care as long as you aren't in that 1%, but as a customer-obsessed service owner I absolutely care if a bad experience is happening 100k times per day. If you're operating at internet scale you need to look at both percentiles and absolute numbers to assess customer impact.

Also keep in mind how percentiles compound when you have more than one service involved in serving a customer request. For example, let's say it takes 5 internal requests to serve an external customer request and each of those services measures latency SLAs at the 99th percentile. The customer request may only finish inside the SLA 95% of the time (99%^5)

The timeouts this post is talking about are related to credential expiration and when to refresh, not request/connection timeouts like you'd see in microservices. In this case, not expiring credentials isn't a great option because you'd lose a useful security property: Reducing the time window when stolen credentials can be used.

For service behavior (e.g. request/connections), timeouts provide value for services and clients. For services, if you never time out then under failure conditions you either end up saturating your max concurrent request limits or growing your concurrent connections indefinitely until you hit a limit (connections, threads, RAM, CPU). Unless all of your clients are offline batch processes with no latency SLA there's a good chance that the work clogging up your service was abandoned by your clients long before it completes.

Timeouts also help clients decide if/when they should retry. Even if the service never times out, clients can't really tell if their request is just taking a long time or if something is wrong and the request will never succeed (e.g. network partitions, hardware failure). There's at least implicit latency SLAs on most things we do (1 second? how about an hour or week?). Given that there is a limit somewhere, it makes sense to use that limit to get benefits like resiliency in services.

>>>Your timeout is not my timeout.

Absolutely. Client deadlines are a great way to reduce wasted work across distributed systems. e.g. service has 60s timeout, but client has a 5s timeout for an online UI interaction. The client can tell the service to give up if it's not completed within the client's SLA.

I'm not quite following the ensuring secure execution of split operations section. There's an incomplete sentence:

>The split process is coupled with network isolation, which can lead to very complicated.

Maybe the second idea should be first, demonstrate the complexity of splits and then presenting the solution?

>>>> ...vs. trying to expand your impact without taking on formal leadership responsibility on an IC track.

This might come down to cultural differences between companies. At Amazon leadership responsibility is formally baked into the upper SDE roles (Sr and above), literally in the role descriptions. There's definitely still value in being a technical manager, but that's not the only way to get formal leadership responsibility.

>An engineer is dealing with a significantly unique problem space that has only been addressed by theory, if that.

This is a very high standard for defining engineer and I'd guess most practicing engineers don't meet it. Sure, there's people bridging the gap between theory and practice, but most engineering effort goes into applying the same well-understood theory and practice to slightly different situations. I'd posit that your definition of software engineer is closer to what most people would call a research scientist.

Plenty of teams within Amazon

I'm also on a 2015 model, but it was manufactured in early 2017 so it's not that old. I and several people I know are holding out on the 2015s for as long as they can because of ports, no touch bar, and a better keyboard compared to the newer models.

I can't quantify compared to other languages but anecdotally there's definitely parts of the company that use it heavily. There's currently 146 job postings specifically mentioning ruby on rails[1] and 3154 mentioning ruby.

[1] https://www.amazon.jobs/en-gb/search?base_query=ruby+on+Rail...

Precision Agriculture[1] is the term for anyone looking to learn more. Even small farms now track all inputs/outputs on every acre they farm.

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

We do a variant of this for most of our data, except we use the version attribute (also used for optimistic concurrency) instead of a timestamp to identify changes in the history table. Our change velocity on most data is really low so the audit trail is basically free.

Another pattern to achieve the same goal is v0/vN records, where you store all versions in the main table but keep the most recent info in v0 for quick querying. This[1] SO answer has a lot of context on the tradeoffs between the approaches.

[1] https://stackoverflow.com/a/54600512/2811887

Serendipity is a lot harder when you're distributed. The close proximity of being in the same room and overhearing conversations helps you stay a lot more connected.

One of the benefits mentioned is "a transparent "build"-free environment for the developer", so they don't have a build pipeline at all. Plus, with heavy caching thanks to Apache this would probably only get hit on server startup. Given the (self-imposed) design constraints it seems like a reasonable solution. Definitely some room for improvement on the minifier implementation.

I understand that it's a one-time bonus and TC drops off after that. I'm still curious what the circumstances were for that specific candidate and whether they had unusual circumstances that gave them more leverage than the usual bachelor degree new grad.

Any more context on the $275,000 offer? Did the returning intern have a PhD in a specialized field, did their name rhyme with Midas?

If you don't want to think about things like redundancy then use higher-abstraction services. Lambda for example takes care of multi-AZ redundancy so you don't have to think about it. The lower level building blocks like EC2 don't. They expose the fault boundaries so that you can build HA applications on top of them, but it's still your responsibility to do so.

I was using a physical RGB LED so there wasn't much extra bandwidth for conveying information. I live in a cold climate so green really meant "Leave now and you'll only have to wait in the cold at the stop for 2-3 minutes". Here's the code if anyone's interested[1]. Looks like my memory wasn't quite right, I did blue/green/red with blue=wait, green=leave, red=missed.

[1] https://gist.github.com/kevana/32bfa486d9fb0aa20a19694d1b69d...

Pretty cool. When I took the train to work I made a simple stop-light with transit data. Trains ran every 10 minutes and it took me a few minutes to walk to the station. Green meant I could definitely catch the next train. Yellow meant I'd make it if I walked fast, and red meant I'd miss this train and need to wait for the next one.

If you're doing a monorepo I think it's strongly implied that you'll also use a build system (Blaze/Brazil/BuildXL etc) that has granular compilation units and output caching so build time doesn't scale linearly with the company's total codebase.

It's definitely important to consider before jumping in. Going from 5m to 50m compile times would be a major issue for me.

You could reasonably argue that the highest impact investments a manager can make in a team are hiring better people and firing worse ones.

They're not killing themselves with production numbers to make analysts happy, it's literally in the mission statement...

Mission statement: Tesla's mission is to accelerate the world's transition to sustainable energy. [1]

Strategy (paraphrasing): Start with low-volume, high margins. Over time introduce high-volume, low-margin. [2]

[1] https://www.tesla.com/about [2] https://www.tesla.com/blog/master-plan-part-deux