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.

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.

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

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.

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

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.

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

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.

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

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.

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

An unintended consequence might be that yes companies do correctly follow the law and adding carbon to concrete is successful, but also adding carbon to concrete in high enough volumes makes the lifetime of the concrete lesser when exposed to rainwater for long enough, or something like that, resulting in the need to replace the concrete more frequently.

Its the difference between people acting in good faith vs neutral/bad faith with respect to the intent of the law/regulation/etc..

This is basically my interviewing POV. If you've done the work, you can talk about the work intelligently if I ask some questions about it. If I ask you how you would think about solving problem XYZ, you can probably verbally think through how you would solve the problem, what a solution might take.

> How will emailing someone directly help if he doesn’t have a unique set of skills that helps him stand out?

Because they will indicate their very direct interest in the company in a way that people who are spray-and-praying 100s of resumes a day won't. Because they get to briefly demonstrate their soft skills to a potential teammate in a way that might not be conveyed in just a resume.

I'd hire a generic skillset developer who is a great communicator and teammate over a technical genius asshole who shreds teams apart 99.9% of the time. I've made this choice personally many, many times across my career as an engineering leader.