ctvo

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:

https://github.com/cdklabs/cdk-pipelines-github

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.

1. https://aws.amazon.com/startups/credits?lang=en-US

(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.

Nah. There are those types of folks, but there are other folks who are clearly above the rest in terms of technical ability. See John Carmack, Sanfilippo (of Redis fame), 100s of others. Or heck even folks who deeply understand the entire stack like Casey Muratori.

To act like there aren't folks who are "rockstars" or simply better software engineers, and at some point it boils down to soft skills, impact and leverage is corporate bullshit. There ARE people who are simply more technically gifted.

The OP didn’t ask about how to become a staff engineer, they asked how to become a great programmer. Those are not the same thing.

Employees don’t have visibility into their peers actual performance. They see a silver of it and infer. This makes layoffs look random. Then, we rely on publicly reported “I was given a great review and still let go!” posts — which are all self-interested. No one wants to hire or refer someone who was doing poorly so there’s an incentive to fib or have selective amnesia.

The whole cohort of folks let go are incentivized to keep up the fiction that it was random.

All things being equal, there is no reason to layoff someone high performing over their less capable peer. I’ve never seen it done randomly, and I’ve sat in these meetings.

This is not to say whole divisions or companies haven’t been let go, but that’s not the same situation here. We’re talking about selective cuts across the entire company where core, or advertising lost some folks, while others remained. That is not random.