No model maker is going to try to generate a profit off users using their models, they're gonna try to generate it some other way - much like dev tools.

Readability also has some level of objectiveness to it. There's only so many ways you can abstract a concept, and so many ways you can express logic.

In that sense, readability has way more to do with skill in abstraction, than taste. In fact picking bad abstraction layers or expressing logic in odd manners because of taste is a great way to write unreadable slop.

You shouldn't strive for internal consistency with yourself, you should strive for external consistency with the other developers in your team. If someone reads your code and immediately knows it was you, you probably aren't doing a good job.

And that's the difference. If you are doing a good job as a software engineer, no one should notice you. If you're making good art, everyone should see you. And that is the difference between devs who think they're good, and devs who are truly good.

Coding for others is not art, it does not have much meaning in of itself. Your users won't marvel at your choice of language or your usage of design patterns - they care about how the end product looks and works.

In a world like that where you have to work in a team, why you ever wear your inflexibility as a badge of pride? The ones who are the most useful are the ones who can code any way, any how, and can plugin anywhere - "taste" be damned. If you want to be a net positive on the teams you work on, stop thinking it's about you, because it's not.

What happens if you don't pay $1k/mo for Claude? Do you get an appreciable drop in productivity and output?

Genuinely asking.

And I know some people are going to say how writers and news "don't deserve" to make money because they haven't sacrificed enough upon the altar of tech, hustle, and Silicon Valley - I don't really care. I think newspapers and writing in general losing out is a blow to society.

Crime in SF and other big cities have been going way down. If anything, you're probably safer than ever in SF (and other common political targets like NY and Chicago).

Also, how can you know that Muni is more dangerous, if you're too scared to even get on in the first place? Can you really say your fear is based on facts and experience?

It is ultimately the responsibility of the company and its people to create a system where things like this are discouraged or prohibited. Not doing so is tacit approval, especially in this case where they have a significant history of doing the same thing.

Seems like everything I find requires running locally or hosting your own instance.

1. Re: hiring, you're probably not going to hire your first FTE right after raising money. You're probably going to do so after getting a bit of traction. I hear most investors especially today will push you to be lean and do more yourself. Either way, bootstrap or VC funding, you're going to bust ass, no way around it.

2. Re: salary, yes, some investors will encourage you to pay yourself, but you're probably not paying yourself a "full" salary right away.

3. Re: selling to cohorts is a bit overrated I think. The fact of the matter is, they're probably all early-stage tech startups, which means if you don't have a product that specifically targets early-stage tech startups, you're probably not going to sell to them.

I don't think it's as cut and dried as X is better than Y. It really is all about how much risk you want to take on, if VC funding is even an option.

Also, external crates like "anyhow" are required if you don't want to account for literally every single possible error case. Really seems like a pedantic's dream but a burden to everyone else.

Effective Java recommends checked exceptions only in the case where the caller may recover, but in practice you're usually just propagating the error to the caller in some form, so almost everything just becomes unchecked runtime exceptions.

For most people, it's not like there aren't opportunities to meet people and talk to people. It's well understood that no matter how many people you get exposed to for a period of time, meaningful relationships can't be forced.

Plenty of lonely people in big cities going to social events.

A lot of software that on the surface does the "exact same thing" often has different nuances, either to the business or the product that makes them appeal to different niches in the market.

Understanding the nuances and exploiting the market niche is your only goal when starting a business. It's not something you ever do or think about when working on software, but people who strike it out on their own quickly realize that simply building is not enough, you MUST give people a good reason to use your software. Just because you don't see or understand the nuances, does not mean they are not there.

You absolutely must have a "unique" selling point, even if it's just being cheaper. Otherwise, your competitors are just a click away.

I'd argue the author HAS found PMF, just not the kind that gets you to $1b.

The auth is workable - you can authn/z individual users, which is basically what you need with a real backend. Personally though, I think doing auth declaratively is a bit harder than doing it imperatively in code.

If you're just 1 or 2 devs on a fledgling product, I would dare say all your concerns about testing/version control/composability are totally worth it to be able to build fast (and some of it is mitigated with Supabase's setup anyways).

Personally, I think the idea is to eventually migrate to a true backend, without requiring any changes to the schema, and hopefully avoid lock-in.

Taking a look at the docs here:

https://postgrest.org/en/v12/references/auth.html

https://postgrest.org/en/v12/explanations/db_authz.html

It doesn't seem like current_user_id() is a provided function, and the docs claim nothing else is done with the JWT except validating it. It looks like your claim already includes user_id, so you'd have to get it from the claim using:

   current_setting('request.jwt.claims', true)::json->>'user_id';

At the end of the day though, I really hope it all works out.

In reality, I think there was (and still is, albeit small) market for alternative hosting, and there definitely were niches where SourceForge was better at (downloading binaries, for example). If SourceForge didn't misplay their hand, it's entirely possible Github won't have the near monopoly on open source hosting they have now.