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

Because the intent of such a hypothetical law would be to reduce/capture C02, but the end result of it is that it financially incentivizes generating more C02 through some unexpended/unanticipated means.

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

> It seems fairly straightforward to just ask verbal questions?

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.

Sticker pricing, at least, IIRC

Strongly disagree with this. Its very easy to stand out, in many different ways.

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

Honestly, I don't know. I don't see enough of the "not close, easy rejection" type resumes, I see things after they've been filtered. But I'll see if I can get an answer to that question.

Well, to give you my POV - my company is still hiring because the business fundamentals are still strong. We're making money and using that money to pay people. But I have friends in network who had to lay off because they were hiring against VC cash instead of revenue, with the expectation of raising another round later. But they now don't expect to be able to raise that next round so easily so they have to slow their burn rates.

Money WAS cheap and easy for a while, and with everyone trying to use that money to grow, you could throw cash around easy to hire/poach/etc. and had to compete heavily for talent. Now you can't, money is much more expensive and tougher to get and you have to be more deliberate.

> I've wondered about that. Sometimes I see jobs that sounds super interesting, but I only match maybe 50% of the unique bits of experience they want.

Really depends on what the company needs. We're willing to talk to a pretty wide range of people about some of our roles, while for others we need someone specific. Honestly I think 50% is not that bad. We get a lot of 0% resumes.

As someone on the other side, with open positions we're hiring for:

There are probably fewer job openings than there were, but I don't think my company or anyone in my network have changed HOW they're hiring, but we have definitely noticed a huge uptick in volume of applications. Earlier in the year, we were getting almost nothing. Now we're getting hundreds of resumes a week for each open position, and the bulk of each one of those resumes do not come close to even being in conversation range of the posted JD.

There's just a lot more to wade through from an HR and hiring perspective now, orders of magnitude more. It takes way more time/resources and is way more draining for the people involved.

I think my suggestion is, do what you can to stand out. Don't go overboard or anything, but if you're submitting your resume to an HR software or something, maybe try and find someone in the hiring chain on LinkedIn and email them directly either with your resume or just asking how its like to work there before you submit. Something like this.

Those types of conversations are going to depend a lot on their context.

Like, if your company is a large company that has a lot of operationalized tooling around corporate agile, one team saying "hey lets not do this" is not going to go over super well. A smaller company with fewer and/or more autonomous by culture teams will have more success.

But it will also depend on what kind of way its communicated. Can't just say "lets stop doing sprints", you have to make sure you're justifying it and/or offering alternatives that speak to the needs of the other members of your team/company.

Modern corporate Agile isn't the same as Agile Manifesto Agile. Even though they have basically the same name, don't mix the two up.

Sprints are one tool in your toolbox. Use them when it makes sense to do so.

I view them as most helpful around scope limiting. The goal is working software of some sort by the end of the sprint. That requires you to think about the problem at hand and how to break it apart such that you can achieve that goal inside the sprint. Some work doesn't require this boundary. Some work does.

I can't really speak for the motivations of those people, but I don't consider potential direct financial gain to be "some laughs".

Yes. For example, I was a mod on a larger tech related subreddit (trying to keep it generic) that was a critical part of my tech stack and daily work at the time. The mods above me would regularly promote their POV on certain topics and do various things to demote/remove the things that they disagreed with. In this way, the community artificially seemed to be more in favor of particular directions on certain topics.

Did this have any material impact? I don't know. But its an example where a set of random people can at least try to leverage their position for more than just "some laughs". Its one example of what I mean about "influence peddling".

There's a lot more intangible incentives than you'd think. For example, general clout, influence peddling, an outlet for low power people to experience power, etc.. Many people don't care about those types of incentives, but there are some who do.

I was hired as a founding CTO a few years ago from a HN post. Without going into detail, the company grew, exited, and I'm still working for them.

Yeah, of course. But there's a difference in things like, "I don't want Tailwind, I want Bootstrap" or React vs Vue; instead of things like I don't like Ruby or I don't like convention over configuration. The former set of things ARE decisions you can make within the framework, while the latter are things you can't. You can have this exact same conversation about most frameworks, it doesn't have to be just about Rails. I also had a Symphony repo set up in a similar way when doing consulting many years ago.

Having said that, some of Rails opinions are becoming more optional lately.