noodle

As someone who had some outages due to AI traffic and is now using CloudFlare's tools:

Most of my site is cached in multiple different layers. But some things that I surface to unauthenticated public can't be cached while still being functional. Hammering those endpoints has taken my app down.

Additionally, even though there are multiple layers, things that are expensive to generate can still slip through the cracks. My site has millions of public-facing pages, and a batch of misses that happen at the same time on heavier pages to regenerate can back up requests, which leads to errors, and errors don't result in caches successfully being filled. So the AI traffic keeps hitting those endpoints, they keep not getting cached and keep throwing errors. And it spirals from there.

Yes, no question, assuming Rails matches what the startup is trying to do well enough. I've worked in other frameworks, stacks, etc and nothing beats the raw productivity of Rails for web applications.

A lot of people say things like "the difficulty with Rails is in the long term". To them I'd say two things:

- In starting a new company, I'd assume failure as the starting point and do everything I can to wrestle success from the jaws of failure. I don't want to waste time worrying about what will happen in the long term, because statistically we won't get to the long term. I'll take every advantage I can get to get over that statistical hump. Rails gives me that advantage on the engineering front.

- I'm currently working in a Rails codebase along with a few hundred other developers and its fine. It isn't great, largely because it was an inherited codebase I was acquired into and the OGs made some (imo) sub-optimal decisions, but it isn't really any different than working on a java project with a few hundred devs. Its fine at scale.

That's true, I'm mostly commenting on software because the article is about software, and this might be anecdata, but it certainly seems to me like patent trolls are more prevalent in software.

Don't think I've ever worked for a startup that had any patents whatsoever. I think I consulted with one IIRC, and they folded largely due to their hyperfocus on tech to the detriment of building something people actually wanted to pay for. Filing a patent was probably a symptom of that problem.

Its more like smaller public companies trying to keep bigger public companies in check.

Fully agreed. IMO its a critical thing to provide engineers an IC career path that enables advancement without requiring moving into a manager type of job. Otherwise, you get people who are shitty managers because they feel they have to do the job to continue to grow, and that turns into a team/org-wide morale issue.

When promoting engineers into management positions, I'll always give them a trial run first in some form to make sure they actually enjoy the job, make sure their new team doesn't see any red flags, and to give them a graceful path to go back to IC without some fanfare company-wide promo announcement locking them into the role socially.

> My example was to refute the parent poster who implied, in a seemingly general sense, that stock issuance doesn't impact earnings, which is false.

I was talking specifically about their comp, not stock in general. Which is why I specifically said "their comp" and not more general language.

Their comp is largely stock, not cash. Eliminating them won't move the needle much on net loss.

Agree with this. There are also still lots of companies hiring CS grads. They just aren't paying FAANG level comps. Kind of strange to hear people say they're going to pivot into being a garbage man if they can't get the $200k+ TC straight out of school.

Depends 100% on the company you're referring into. The larger the company, the less personal it tends to be. Conversely, if the "current employee" is a leader with hiring authority and the referral will be hired onto their team, the more personal it tends to be.

Depends so much on so many things. Like, what kind of app/company are you building? How big is the company/app/team(s)? Who is on your team? What are your other practices? Etc..

For example, if my team was very junior, I'd be less inclined to merge first, but if it was very senior, I'd be more inclined. But even then, it depends on other factors.

> modern software development is trivial to learn

LMAO c'mon. This basically undercuts anything else you say here. Go teach your grandma react and see how trivial it actually is.

You can see this with a "new" ANY dev, because there are only 4 years of college and far more years are required to learn the increasingly complex technology environment.

I graduated with a Computer Engineering degree, did assembly, C, microprocessor design, computer vision, and know a good bit about lower level stuff, how memory works, how networking works, etc. All the stuff people in this thread seem to be lamenting the lack of. But I was also a shitty employee fresh out of school because I didn't know anything at all about modern software development because there was absolutely no time to learn that stuff as well.

I still had to spend a lot of time getting good before I was worth anything, just as these "new frontend devs" will, as well.

> This is pretty trivial to build once you have given it some thought, it sits nicely next to the work you do building health-checks into the various tiers of your infrastructure, yet there are enough people out there willing to pay for it.

I think the reason you don't have a bootstrapped startup is because you don't see the difference between trivial and valuable.

Would it be easy for you to build out a feature flag app? Yes, most devs probably can without a huge problem. But it will take them time to do it, and it will require maintenance over time. If it takes a senior dev two weeks of dev time in sum total over 4 years, it would be "cheaper" to pay $100/mo for this service. This type of product product has value as it allows us to spend our limited dev time more on forward feature development that drives future revenue and less on infrastructure.

This is the math that companies buying SaaS products will make. I don't want my eng team to spend hours on trivial stuff, I want them to work on the things that move the needle for the company. I'll gladly pay $$$ for certain features and functionalities that are not part of our core competencies so that the team can focus on the things that are. And once we're a Big Company paying Enterprise tier prices to a feature flag company or whatever, we can have the chat about in-housing it or building Feature #137,221

This depends a lot on the product. Some products, companies, markets, etc simply NEED capital to get off the ground. Hardware for example is fairly pricey on average. Tech's evolution has made starting software companies and products really cheap where it used to be fairly expensive. Perhaps the pendulum is swinging back in the other direction a bit. Perhaps its SO easy that in some spaces, you need the money to differentiate your offering from the hundreds of others trying to do the exact same thing in order to find that success.

But speaking as someone even lately who has produced new products in the last few years, the products don't need to be perfect. The PG (I think?) anecdote about PMF where your product should feel like selling water to someone who is lost in the desert and dying of thirst. You can DEFINITELY achieve that with a sub-optimal, still a little unpolished/buggy product. I have, myself, just in the last few months. You just need the right product and the right market.

The potential to game things exists everywhere. Tax CO2 and people will want to find ways to technically reduce CO2.

For example, what if it becomes cheap enough to just convert all the CO2 to CO and we dump masses of carbon monoxide into the atmosphere instead? Or if its cheaper to convert CO2 to CO3 which imminently degrades back to CO2 in the atmosphere - would we be confident that the tax law would correctly handle this scenario where the emissions are technically a different substance? Etc..