noodle

I don't think so. This boils down to a set of already installed, pre-configured gems in a starter project. That's always how Rails has worked. When I was consulting, I had exactly this for myself before Bullet Train ever existed - a pre-configured rails repo that I just forked when I started something new.

The thing w/ Bullet Train is that so much work is done for you, that if you don't like an opinion or two that they hold, you really should start from scratch, as tearing things out will just take longer. Its the downside of having so much integration and configuration already done.

> that companies are currently racing to go to market with some "ai thing" and most are chasing it because it is the "next big thing" in their mind, not because they know what problems for their end users that it can actually help solve.

And if you re-read my comment, what I am saying is that while I'm not exactly "racing", I do have a very clear problem for my end users that this actually helps to solve. Its possible I could've cobbled together a similar solution with other technologies, but I didn't see a very clear path forward on this user-facing problem until very recent developments.

I suspect that the people in this same boat far outnumber people in the Metaverse or crypto equivalents.

FWIW, I've found uses for it already that will improve the company I'm building in the very short term. Maybe you disagree in the magnitude of the value, but I find it to be at least somewhat significant. Enough to pursue.

I've never worked for any company where leaning into the Metaverse or crypto would generate any meaningful business value, short or long term. The promises for Metaverse and crypto are always about a nebulous future that could exist if only everyone collectively bought into the vision.

> The only reason people make apps that don't need to be apps is to get another marketing channel through App Store distribution and another user reach channel through notifications.

I wrote a longer response but decided to scrap it. The behaviors and expectations are different than you might expect from a pure engineering POV. Its not just sales and marketing. For better or worse, people want to interact with companies' apps on their phone via installing something "trusted" through their appropriate app store. Not responsive mobile web, not even PWAs (which are difficult for people who are not tech savvy).

At my most recent exited startup, we had a web app which was mobile responsive. People asked for a mobile app. We gave them a mobile app that was simply a webview that loaded the web app. Customers loved it. We got almost no inbound from it at all for various reasons, but existing user satisfaction, engagement, etc went through the roof. They could finally "use our app on mobile" even though they always could, and we consistently pointed them to the mobile web experience to do so. This is a market full of people who are average to below average levels of tech savviness.

I personally take a more pragmatic approach, though perhaps its "post-modern". How well-architected, tested, groomed, etc my code tends to be is proportional to the confidence the business has in the problem space.

If I have a detailed, firm spec that I know won't change at all, I'd spend some time planning and then build a DRYed up, abstracted, well-tested, etc solution. I know the solution is going to be sticking around for a while, more or less, so it makes sense to devote the effort to build a solid foundation.

If the thing I'm building is squishy, looking for heavy user feedback, will likely be iterated on quickly (i.e., very agile manifesto agile), I won't spend the overhead time for those things. There's a nonzero chance the code ends up in the trashcan, and the most important thing is to ship something and get feedback from real customers. You later go back and clean it up, based on the growing confidence in the permanence of that feature.

I personally agree with your point of view on what DRY is. But,I don't think that's what's being taught or talked about anymore. When people say DRY they usually mean an abstraction layer that merges two similar concepts into one, and the DRY you talk about is just standard operating procedures. Static analysis tools will ding you on DRY rules if you have code that looks pretty similar, urging you to refactor them to be the same. Etc..

Same. I think the article's title lays it out well. "Amazon's Big Dreams". Amazon wanted to do a specific set of things w/ Alexa and they've found that the market doesn't want any of that. I'll never buy something through my Alexa, for example.

What it could/should have been is the end cap for the Amazon brand in homes. A loss leader itself, but a constant reminder of the value of the company and the desire to keep spending money there due to the convenience it provides.

What the article makes it sound like they want is something more tangible. Something that quantitatively generates direct ROI. They'll never get that, or rather, that number will never add up to one that justifies Alexa's existence.

I agree with this point, though at least in theory this is a path for them to get more $ and therefore expand the network further/faster, also potentially increasing the size of the moat. We'll see if they actually do that, though, I guess.

I've hired for a few remote startups in the past. It certainly could be your resume, but my offhand is that your FAANG experience prices you out of the remote market, either directly (you're telling them) or indirectly (recruiters know you'll be expensive).

I've hired ballpark 500 people in my career, talked to a lot of FAANG candidates, and hired only one. Comp expectations compared to experience was just always way out of alignment. Only reason the one got hired was because they were a great fit and very open about being willing and able to take a pay cut to go full remote.

I'm not going to go into details for the purposes of anonymity, but I took over a website that is a resource for a community I'm very involved in in order to prevent that website from being shut down. It costs me money to keep afloat, but I keep it afloat to maintain it as an entry point for the community. It does come with some fringe benefits that probably makes it worth paying for as well, but "worth" is very subjective here.

It makes a little revenue with ads and Amazon referrals due to the traffic volume but it operates at a loss.

Rails on postgres with React in the frontend is my default swiss army knife. I know Rails well and it still gets stuff done fast, comparatively speaking. If the problem space I work in requires something different or solves the problem better than Rails, I'd switch.

Edit: post-mvp, I'd stick with Rails still unless there are specific difficulties with it. But I've yet to have major issues building a large Rails team/project, including present day.

Dunno the technology behind it specifically, but the various types of fast charging has really unlocked the potential in EVs, IMO. Making an EV act more like an ICE car is what made them pop in terms of viability.

The article is about corporate staff, not warehouse workers.

If they were making record profits, they would be looking to expand their profitable divisions, would they not? They would likely not lay people off, but reorganize internally to move resources away from failing areas and into the clearly thriving, very profitable areas; or start something completely new.

Hiring one good employee is expensive and difficult.

> What situation are people in that they have to result to this? Is this an issue with getting laid off and trying to find a FAANG job?

It's reflective of the type of company you're interviewing for.

I lived in Seattle for a while, and almost every startup in the area did some form of algorithm lottery interviewing, because the startups were created by ex AMZN/MS/etc employees and they just took the process they were comfortable with to the next company.

I lived in Atlanta and a few other smaller cities for a while before and after that, and no company did anything like this, because the successful tech companies were all born of people with no FAANG experience, with different backgrounds and with different experiences.

I've hired quite a few, and generally speaking they've all turned out great. Having said that, the volume of resumes that come in to the ones that I've actually hired is vast. Myself and my recruiters have probably sifted through 10,000 bootcamp resumes per 1 hire. You have to be ruthless about who you actually talk to.

Another tip would be, don't interview a bootcamp grad for mid-level jobs.

I briefly worked on starting a small competitor to TM as a contractor (which is incidentally still around and doing fine). The reason TM is hard to disrupt boils down to this:

Everyone makes more revenue when they go with TM - artists, venues, etc - everyone except for the ticket buyers, who pay out the nose. And TM plays the "bad guy" role in the equation to cover for all of those other people. Yes, TM holds a lot of contracts with venues, even owns some venues outright. But those contracts wouldn't exist if they weren't very juicy for the venue.

I run a small-to-medium (based on your definition) website that is entirely ad-supported. It occasionally peaks into the large territory.

It's not really "viable". This may be because of the industry it's in, which doesn't really purchase online advertising, and therefore cuts into the overall earnings potential.

I run it for fun and for certain incidental benefits, not for the $$$

I'm currently in an engineering leadership position hiring for a startup not impacted by this downturn. I see the numbers and do interviews, but not a Recruiter per se.

> Have you noticed that more people are applying for the same roles?

Seeing a slight increase in qualified candidates, not much of a change in unqualified candidates. By unqualified, I mean, as an example, a fresh bootcamp grad applying to a Staff level position.

> Do you have less roles to recruit for than before?

Have the same amount. Had a hiring plan, still have it, still working on finishing it up for the year.

> How intense is the competition presently for roles?

Not very. We're on a glide path to meet our hiring plan for the year without the pipeline being dry or being over-full. We're able to consider candidates individually without needing to hire anyone just to make the numbers, or reject people simply because we have too many applicants. If you're a good fit we make an offer.

I don't think the first paragraph and the second paragraph necessarily flow into one another. I've worked with a lot of people in tech that are very proficient at their jobs that have no clue about "basic" computing stuff like local networking, symlinks, chmod, user accounts, etc.. Because they don't need to be. And they're definitely worth the 6 figures they're paid.

Sure, I've done that before many times, as well. It isn't my preference, generally speaking, for earlier-stage startups.

> Hiring for a particular tool-chain or framework

Dunno about this one. This is very much so FAANG type of thinking, not really (newer) startup type of thinking. Sacrificing a few man-months to training is something that is hard to do when that's a significant percent of your remaining runway.

You could say the same thing about a lot of companies that were allegedly on the edge of IPO. Lots of IPOs got shelved due to the bad market conditions

> I'm thinking of starting out on my own someday, but I wonder, is it even realistic to have a 9-5 kind of structure in IT/software dev field ?

Yes. I've done it before, and am doing it now. Including at startups. It's about intentionally setting your own boundaries and being firm on them.

Every job in every industry will ask you at some point to give more than is required, and it's up to you to set the boundaries on when and how you say yes and no to these types of requests. My sister works in a non-technical industry and the text of your post could be something she's said to me in the past if you just replace "IT/software" with her industry. And again, her issues are all caused by simply saying yes to everything asked of her without any boundaries.

I've been hired to more than one job through these posts over the past ~15 years; and I've also done hiring for my teams successfully through these threads.

Having said that, in the last ~2 years, we've had FAR less success with these threads. Didn't post in the last one cuz it just didn't feel worth it.

> Any idea how to validate this part?

Productized consulting until you find commonality

The challenging part is the process is actually integrating an onboarding system into your app - doing the right thing at the right time in a way that looks seamless/intentional and works consistently. If you want to build a successful solution, I think this is probably the hump you're going to have to get over. No product out in the market is perfect, because everyone wants something different, and generic products are easier to extend/change. Make sure you aren't building YOUR version of an onboarding system and expecting others to buy into it - they probably won't.

> I'm just curious to hear how many of you have experienced something similar. Is it common? Is there something obvious I'm not thinking of to help avoid these situations?

Had the exact same thing happen, yeah. One person interviewed on camera and used their ID for employment verification (EVerify/I-9). Someone else was joining meetings instead, initially with their camera off, and then when confronted and turned camera on, was DEFINITELY not the same person.

The company is paying like $150k/mo in salaries (conservative ballpark based on 20 employees). $1k/mo at that point is a rounding error, and if in total that spend actually does move the needle on productivity in any significant way, its easily worth it.

I'm in my late 30s and no. I enjoy working with early stage companies and starting my own companies, and being a generalist is essentially necessary in those situations. If you do this as a specialist, you'll end up wearing many hats anyway just out of resource constraints.

Being a generalist also, IMO, makes you a more effective manager for crossfunctional teams, and gives you empathetic understanding on how the sausage gets made across the board, instead of just in a single domain.

But as others have stated, you can be both a skills/technology generalist while also framing yourself as a specialist. As I alluded to with my personal history, I consider and frame myself to be a startup specialist due to my broader base of skills.