7,059 karma · joined April 10, 2013
This is untrue for Amazon, at least in the US. Your total compensation is guaranteed for the first 4 years. If your total compensation in your offer was 500k, you'll get ~500k per year.
The first two years you're paid in cash so it'll match the offer exactly, the final two years you're paid in RSUs (stock based) with the stock price calculated at the time of the offer. Your salary may vary due to stock price. Historically it's gone up, not down, and this is how people have made 600k+, for example, as a senior engineer there.
Starting from year 2-3, you'll receive new stock grants that will vest in the years after 4 if you stay that long.
Source: I've received offer letters.
Who handles liability if you get into an accident? When does it take control of the vehicle away? The most likely scenario is the car pulls over safely and asks you to get out or wait.
There are _many_ people who cannot or will not driver. They won't just take over control of a vehicle they're unfamiliar with. Teenagers, the elderly, people without a driver's license, people injured, ...
The requirements of supporting the more demanding customers typically are amortized across all customers. Requirements re: security, SLA (uptime, data durability, etc.), data governance for example. It is difficult to both implement and market products that break these dimensions into tiers. You can sometimes do it for the very niche, tail of your customers (air gap regions, for example), but in a lot of products, everyone is sharing in these costs even if they only care about a subset of the capabilities.
The cost savings of scale are offset by the costs of say, needing to support Fortune 100s that need 99.99% availability even if Bob's Wordpress Page doesn't care too much about 99% vs 99.99%. You can apply that analogy to every dimension.
A homegrown solution targets specifically what your company actually cares about. It makes sense that it may be cheaper.
But again. YOU are intelligent, you are informed, you can look and see that Datadog provides a bunch of capabilities you don't need and you're paying for things you don't get benefit from and make the trade-off of building your own. Just stop telling me about it.
Making an argument that there's something abnormal about market competition and that's why prices stay high is different -- I'd read that.
This is the difference in most cases.
Just taking availability as an example. Datadog has a 99.8% availability SLA. I suspect most companies would be fine paying for a 99% availability SLA, for example, at 1/4th the cost, but in most cases there's no way to scale down SLAs like that and launch a cheaper version.
There is a giant leap in cost (complexity, staffing, etc.) between 99% and 99.9% that most of these home grown solutions don't account for.
These nuances are lost in posts like these, and it is tiring.
Look at these outrageous AWS prices. Look at these outrageous Datadog prices. Look at these outrageous Snowflake prices...
And then of course, they lead to _Look how much cheaper my homegrown solution is_
It's a little tiring. You make trade-offs all the time. If the price isn't worth it, don't pay for it.
The account settings page is empty. I logged in via Google's OAuth provider. There's no option to change anything.
I also can't make a company profile, but to save or upload a floor plan, your front-end code is expecting that to exist.
Edit:
> const {companyName: Z, logo: Q, measurements: K} = b.sessionDataSchema.userData.companyProfiles[0]
In your minified code. There is no `companyProfiles` for my logged in user.
Here's a project from AWS using the CDK to setup a CI/CD pipeline with Github actions:
Yes, let's just keep taking that day in and day out in a professional setting.
Why do you think they need to? These cars go to a centralize location every night, I would assume, and cleaning at scale can happen. How often do you think an Uber driver cleans their car in comparison?
Google launched in 1998. Naver didn't launch search until 2000. Copying American tech companies but targeting your own market is a common theme (see China, Latin America, Southeast Asia, etc.). Let's not pretend it's not the case here or Korea is somehow special.
> In fact, for years, react didn't even tell in the doc you could use it without a transpiler so people had to learn a whole build chain before even getting to the hello world.
React's original documentation site from June of 2013 (when React was first introduced):
https://web.archive.org/web/20130607085014/http://facebook.g...
> JSX is a JavaScript XML syntax transform recommended (but not required) for use with React.
It goes on to explain exactly what JSX is and how it converts to JS functions. Feel free to click around that original documentation site.
Here's the README.md from the commit at the same time:
https://github.com/facebook/react/tree/a41aa76ef36471ba07b29...
> You'll notice that we used an XML-like syntax; we call it JSX. JSX is not required to use React, but it makes code more readable, and writing it feels like writing HTML. A simple transform is included with React that allows converting JSX into native JavaScript for browsers to digest.
At this point I would kindly ask you to go away.
It's not either or. The above can be true and also the reason pg wanted him to run YC.
performance was the least attractive reason for adopting React. React introduced composition as the default way of thinking about UIs to the web. You created components and used them to build more complex components. Data was immutable and flowed in one direction (parent component -> child component).
Comparing the above to ng with its dependency injection, MVC style approach to UIs, that used HTML based annotations and tags to sprinkle in functionality (`ng-if` baby) -- it was a much more simple way to build web applications.
React's style of building UIs has largely won. Vue, etc. all follow this component with composition view of the world.
> React sucked for years, with a terrible doc, a crippling webpack experience and breaking compact all the time.
Webpack has nothing to do with React. React has always had good documentation. The reason the documentation was good in the beginning was because the API surface area was tiny compared to Backbone, Ember, ng, etc..
I'm not going to go point by point here. You sound like you have a very superficial understanding of the space.
I'm going to hard pass on clicking a marketing link to your blog.
> Ballerina is an advanced professional tool for advanced professionals.
> Ballerina integrates the state of the art in functional programming and even category theory.
> ... And if you are a master of functional programming, together you will write code that can be, well, transcendental.
Then I click through the code and see commented out blocks, using `alert` to debug, random wait times (???), unsure if there's any test coverage.
Example:
https://github.com/giuseppemag/ballerina/blob/main/frontend/...
I may not be an advanced enough professional for this library made for advanced professionals who want to write transcendental code.
(Not private thank you very much)
How is that senseless? Their efforts, in whatever way, contributed to the massive increase in the sale of the GPUs, right? And they were awarded for it.
If it wasn't Nvidia, but a start-up that was grinding for 10 years before they did well (eg Figma) would you feel the same way? Dig into that.
When I, as a perspective customer, read things like this, it makes me question if I can trust you with my data or your platform long term.
What is your technical expertise and what other similar systems have you built? I can’t seem to find it on the site.
1 - https://en.wikipedia.org/wiki/Stop-and-frisk_in_New_York_Cit...
Even at that rate it is not negligible. Does that clear it up for you or are you still beating your wife?
Ignoring what lifestyle choices means and taking this claim at face value:
Can I have 5% of your lifetime earnings? Can I increase your taxes by 5% for no benefits?
It's not a negligible difference even with your handwaving. It's someone else's money and not your problem is the tl;dr here.
> It enables developers to write declarative step functions...
> With thousands of customers running thousands of step functions containing parallel steps....
> If you're familiar with step functions, you probably already see what's happening here...
Jumping in and telling folks to be a great communicator or tech lead instead is not the way to become a great programmer. That's the way to become a great staff engineer. They're not the same things.