kemitche

Did Amazon return to back-weighted comp? The offer I received two years ago had comp that shifted from "cash focused" to RSUs over 4 years, and had equivalent cash value over the 4 years. Obviously, by year 3/4 when comp was mostly/all RSUs, the stock could have gone up or down significantly.

Given that the year 1 cash could be used to buy stock if I really wanted, it didn't seem an unreasonable approach to comp to me.

You can do this, at least with Windows or Linux, by grouping windows into separate desktops.

I don't view Docker as an "extra" dependency: I view it as the _only_ dependency.

For example, at my last job, before we switched to Docker, a client dev that wanted to run a local backend had to install postures, apply initial schema, and then download and run the app. Not only was this a bunch of steps the client devs weren't familiar with, it led to backend devs being reticent about using the most appropriate tool for new features (e.g. shoving service discovery awkwardly into SQL instead of into something like etcd - and before anyone says "well that's fine" or "just do xyz instead," realize that's just an example of several). It was annoying to client devs to have to add new tools all the time, and annoying to backend devs to have to constantly troubleshoot misinstallation / misconfiguration.

When we switched to Docker, the client devs could run the backend without having to manage anything. Install docker (once), then run a very basic script that basically just ran "docker-compose pull; docker-compose up".

I don't generally want to be able to deploy to arbitrary environments. I want something that is easy to build, builds consistently, and lets all my fellow devs run whatever host they need to be maximally effective.

On Windows, it's true, if you need Virtual Box specifically then you can't use "Docker for Windows". You could either move the VB stuff into Hyper-V, or run Docker directly on a VB VM (a little less turnkey, but not particularly difficult).

To me, starting with Docker makes a lot of sense. I can isolate my development machine from the code execution environment. It makes it a lot easier for everyone on my team to run their preferred OS (Mac, Ubuntu, Arch, even Windows) and still be easy to run the built code.

Containerization isn't really that hard. At its most basic level, a Dockerfile is just a list of commands needed to build/run your program. I'd personally much rather have that as a sort of self-documenting build process than dig into "how does Visual Studio build things? Why is my local dev build process (F5 in Visual Studio) so different from our release build process (msbuild commands or whatever)?" Or worse, "why does our release process involve Joe hitting F5 on his machine?"

Deploying a container isn't that hard - I agree that k8s and such is likely overkill for most startups. A basic "docker run" bash script or something in that vein is not terribly difficult to write, maintain, and hook up to CI/CD. Even so, with growing cloud support from GCP/AWS/Azure etc, the leap from "We built an isolated container for local dev" to "Now we run that container in prod via k8s" is shrinking.

As you pointed out, there are other ways to do this, but at least right now Docker is fairly widely used and it's not limited to certain toolchains/languages. Using something just because it's popular seems like a bad idea on the surface, but if two tools are both reasonably sufficient, I'm definitely leaning towards the more widely used one - it means it's more likely new hire will be familiar with it on some level, there's more blog posts with best practices, etc.

> Imagine being able to unzip a build of your software to a blank windows/linux server and expect that it work flawlessly 100% of the time, regardless of any prior/lack of configuration or other supporting dependencies on that machine

I mean, that's basically _why_ Docker exists.

I did the same, but if I'm doing that skimming and I know the answer to question 12 is (c), I fill in (c) and keep going. I don't read all the questions, then go back and try and remember which of the questions I knew the answers to off-hand. Instead, I'd do the test in 3 passes.

1. Answer all questions that I know the answer instantly or (for math type tests) can solve within a few seconds. Skip anything not quick. 2. Go back and answer questions that I know I can solve. These usually take a minute or two (since the easy ones should already be done). If there happens to be a question I know I can solve but also know will take "too much time," skip it. 3. If there's time left, work through any remaining questions (hopefully there aren't that many), making a best effort to prioritize the ones I'm more confident that I can solve in the time remaining.

I'd argue the opposite - it's harder to get away with impersonation.

In the AIM situation, users go in "knowing" that usernames are unique, so if you see a message from user abc123, you "know" it's that person. Which means user abcl23 ("el" instead of "one") can impersonate the real user.

In Discord situations, (1) the user is more likely to know that usernames can be reused, since they weren't required to make a unique one to start - so they can be more cautious of impersonation attempts, and more importantly (2) the Discord devs know names can be reused/abused, and can build better mitigations if they so choose to (like e.g. putting a disclaimer at the top of any message from a user you've never contacted before, etc.)

Generally, I'd say no, but it probably depends on the types of problems.

Companies have areas of expertise and areas of weakness - their hiring process might be a weakness, but that doesn't necessarily mean that working for the company will be all bad.

That said, the hiring process is a view into the company culture, and if the view of the culture you get is not good, then working for the company is probably not going to be great.

See also "Clean bathrooms!" billboards when road tripping.

Of relevance, Sand Mandalas are intentionally destroyed after completion: https://en.wikipedia.org/wiki/Sand_mandala

Not by necessity, but by design. The world and life are transient - I see no fault in embracing it (for certain things)

The problem is, the answers are useful to more than just the original questioner. Sure, the questioner may be doing things vastly wrong - but the people who land on that question's page via search may have legitimate reasons for doing things a certain way.

The silent majority of viewers will benefit from an answer that does both of (1) explaining why the answer is probably not what is wanted, and (2) answering the initial question _as written_ anyway, for future viewers.

Frontier Airlines charges for both checked and carry-on baggage. Additionally, they charge _more_ for luggage if you don't pay until you're at the airport, and even more if you wait til you're past security and at the gate.

Is it literally the exact same thing? No, but it definitely falls into the same category of sunk-cost/trapped buyers. Once you get to the gate, you're getting on the plane, even if you have to pay more for your luggage than you expected.

It's also very similar to why the soda vending machine at work charges $1 for a soda; the one in the amusement park charges $3, and the one _in the line_ for the popular ride costs $6. They all rely on facets of behavior that the consumer will just pay a little more once they've somehow invested in the process. The only difference is _what_ they invested and how easily recoverable it is.

> Credit Karma is free.

That just makes me wonder what Credit Karma is getting out of the deal.

In a similar vein, Reddit's "self" posts were originally formed by users submitting posts linking to themselves, by guessing the URL for the next submitted post.

There are few differences between "local" and "remote" main in GP's example. "origin/master" is a _local_ copy of the origin's master branch, and updated with every "git fetch". So "git push origin origin/master:master" resolves the "remote master was deleted" without having to stash/checkout/etc.

There is, and will always be, a gap between what is strictly allowed/legal, and what is considered ethical/courteous.

There's a number of things that are strictly speaking legal, but still considered rude. Often, the reputation of a person or business is based at least in part on whether they do the legal bare minimum, or if they hold themselves to some level of higher standard.

I also think there's a difference between attribution because a license requires it (commonly buried several links/pages deep in some obscure "Here's a laundry list of ALL the open source packages we used to build this"), and acknowledging that a _specific_ library powers the core of a new product. I don't know of any license that marks that line.

It's the (usually 1-year) cliff that is more important when considering leaving. Once an engineer hits the RSU/bonus cliff, they're not losing _past_ benefits for leaving, only future benefits - and presumably the other job opportunity has better future benefits.

When I went full time remote (last year, before COVID), I had comfort and strain issues. I attribute them to 2 main causes, that I've since mitigated:

1. I replaced my commute with more screen time. This was a net increase in my daily time spent at a computer. 2. My screen time was more contiguous. I didn't have to walk to my coworkers' desks for a quick chat (whether casual or work related). Meetings kept me at my desk instead of moving. My work day transitioned directly into my personal hobby time (video games).

Would `git log --grep='some pattern'` help? Or perhaps since you're searching, "git log -p" (or other flags) to have the log show the data you need inline rather then needing to separately run "git show".

I don't know if this is the actual reason, but I can see value in a country protecting it's food supply to ensure that long-term, they stay self sufficient. Subsidies that keep production local would be a means to that end.

Exception that proves the rule, there. The insurance company knows you'll die too.

Maybe it's different based on how you signed up, or what kind of subscription you have, but for me at least there's a "cancel subscription" link when I go to manage my subscription online on this page: https://myaccount.nytimes.com/seg/subscription

I remember it didn't exist when I signed up a few years back, and they made a big deal about announcing that I could now cancel/change my subscription online when it launched.

It's not hard to come up with scenarios that get you locked out for longer than expected regardless of your auth set-up.

e.g. "What if I'm traveling, I lose my phone, and the country I'm in blocks internet access to my 2FA service?" "What if I'm traveling, I lose my phone and my wallet?" (In this case, even if you use a syncable 2FA service - how will you pay for a new device to access it without your wallet? You have a different problem here, that likely involves going to an embassy and/or relying on friends & family!)

The question is, (a) how _likely_ are those scenarios? And (b) how much risk/damage/pain do they cause?

If I'm traveling, I'm fine unless I lose my phone. If I lose my phone, then I guess I can't sign in to some/many things until I get back. If I lose my phone AND my wallet and I'm not at home, I'm probably more worried about getting my ID cards and bank cards replaced than accessing certain websites. If my house burns down with my phone, wallet, and backup cards inside, I'm probably just thankful to be alive.

This is how I feel.

Walk the walk and talk the talk in small ways on a daily basis, and learn about and push for policy changes to try and encourage big changes.

Or, to put it differently: on average, the people I know in my life who think about straw-waste reduction (and similar activities) positively are the ones also wanting larger changes. The people I know with disdain for "straw bans" and "plastic bag bans" also don't care about, or aren't aware of, the larger issues. They use the argument that "it's an irrelevant fix" as a shield to avoid thinking about the actual larger problems.

I don't have data, just an anecdote.

I was hired by Sun. Just before my start date, Oracle announced they would be buying Sun. I was worried, but it turns out acquisitions are pretty slow processes. There was months of waiting for government approvals, then months more before the culture really started feeling like "Oracle" instead of "Sun."

In short, there's a decent chance that anyone applying now could be on payroll for months or years before Visa actually meaningfully changes anything about Plaid's workflow.

> let it keep restarting as it crashes?!

Yes, "let it keep restarting while it crashes and while I investigate the issue" is MUCH preferred to "everything's down and my boss is on my ass to fix the memory issue."

The bug exists either way, but in one world my site is still up while I fix the bug and prioritize it against other work and in another world my site is hard-down.

> can leave you struggling for days pouring over docs, code, GitHub issues, stackoverflow

I've had that when running code straight on a VM, when running on Docker, and when running on k8s. I can't think of a way to deploy code right now that lets you completely avoid issues with systems that you require but are possibly unfamiliar with, except maybe "serverless" functions.

\ And of those three, I much preferred the k8s failure states simply because k8s made running _my code_ much easier.

> Years of driving have resulted in mental circuits that automatically detect stop signs and manage lane-keeping with zero conscious attention, just as easy as walking

I thought the same thing when I had an S a few years back. This was just the adaptive cruise control + lane holding days, and I figured it'd be nice for sure but not game changing.

I was entirely wrong. Sure, driving without AP on wasn't hard, but turning AP on made road trips and commuting 1000x more pleasant for me. Driving without AP may be habitual and ingrained, but it still occupies a certain amount of mental capacity to hold the line.

Being freed from that wasn't just about getting more time to look at scenery, either. With fewer brain cycles spent on mechanically maneuvering the car, I could spend those cycles better monitoring other vehicles for potential hazards (crazy drivers, etc.)

> who can compete with Tesla

From my seat, that really remains to be seen. The existing companies don't seem to have found a way to compete with Tesla's EVs yet. They may get there eventually, but Tesla has it now.

Regarding valuation, one point I read elsewhere is that Tesla does a lot more in-house, which adds to the valuation, whereas the existing companies will buy a lot of their parts and/or contract out work. I don't have a source on the specifics, but if true, the logic certainly seems reasonable and would explain things. The value of a company shouldn't be based on their final product, but on the value they added to the parts/components they took in to create that product.

It depends on how the deduplication is configured, and the risk tolerance of the organization running it, I suppose.

ZFS, for example, has a dedup setting option that forces the file system to do a byte-for-byte verification for any deduped data: https://docs.oracle.com/cd/E19120-01/open.solaris/817-2271/g...

I disagree that Git's biggest flaw is its lack of scalability. Cases where git needs to scale tend to be isolated to companies that have the manpower to build a finely-tuned replacement (see: MS, Google).

Git's flaws are primarily in usability/UX. But I think for its purpose, functionality is far more important than a perfect UX. I'm perfectly happy knowing I might have to Google how to do something in Git as long as I can feel confident that Git will have the power to do whatever it is I'm trying to do. A competitor would need to do what git does as well as git does it, with a UX that is not just marginally better but categorically better, to unseat git. (Marginally better isn't strong enough to overcome incumbent use cases)

And for the record: I think git-lfs issues are primarily usability issues, and tech improvements. The tech enhancements will be solved if there's enough desire, and as I mentioned the usability problems are more annoyances than actual problems.