billllll

It's less a binary pay/no pay, and more the value of accessing the dev tools. If you consider the fact that AI companies are most likely losing money running the models, then AI tools are incredibly cheap - they're in some ways paying you to use it.

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.

Unreadable slop and "tasteful" choices are independent of each other. You can make "tasteful choices" that makes code unreadable (I know from experience).

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.

Nothing that you talked about pertains to art. Writing good code does not mean you're making art.

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.

Some of the worse engineers I've ever interacted with had too strong of a "taste" for what they felt were right and were completely unable or unwilling to work outside of that. Developing a superiority complex because you think you have "taste" is a great way to torpedo your team.

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.

Paying for Internet is not a great analogy imo. If you don't pay $1k/mo for Internet, you literally can't work.

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

Genuinely asking.

At the end of the day, they're subject to the same market forces. If the big publishers lose their shirts, that means small bloggers don't have any chance of making it big. The same market forces that make big publishers worse are going to squeeze smaller outfits and writers.

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.

I ride Muni, BART and Caltrain all the time (I'm car-free in SF), and I have no idea what you're talking about. Here are the actual statistics of crime per vehicle mile on Muni: https://www.sf.gov/data--crimes-muni

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?

Just because the shareholders didn't vote on it, or an exec didn't explicitly say "hey steal this" does not absolve the company. Leadership doesn't get to throw up their hands and say "not my fault" when something bad happens.

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.

Anyone else hosting MCP servers in a generally available way? Seems like that's the end goal given the network transports (especially the one in new spec revision).

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

VC funding is for sure less personal risk, but I don't think the other points are universally true.

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.

That's the reality of a lot of other degrees. Looks like it finally caught up to CS degrees.

Is Rust praised for its checked errors? I've personally found it extremely verbose since there essentially is no possibility for unchecked errors.

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.

How do you even "fix" loneliness? If you don't know that, you can't allocate resources. Plenty of research studies have been done on loneliness to find a silver bullet.

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.

I really doubt "literally" every software you used or worked for has multiple competitors doing the "exact" same thing. VC money can temporarily prop up multiple competitors doing the same thing, but over time, winners definitely spring up.

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.

Unlike regular businesses, software scales infinitely and delivers immediately.

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.

If you need to built quick, you can get all of this configured out-of-the-box with something like Supabase. If I had to set up all the roles and security myself, I don't know if I'd use it.

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.

Am I missing something or is step 3 missing some steps to validate the JWT and define the current_user_id() function?

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';

More than existing chatbots? Curious what anecdotes you have, whether it be on the customer-side or the service-side.

It's crazy how popular authoritarian demagogues have gotten around the world. His campaign, mannerism, and treatment of media and opposition can be a cut and paste of a bunch of different politicians of the world.

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

Including those events would certainly change the picture. I don't like how the article implies that all this was a result of GitHub founders being smart rather than SourceForge misplaying their hand. The article smacks of the irrational worship of successful founders that's so common.

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.

Curious how much of this is due to factors other than AI. The data is correlated, but at least for me, I'm not convinced of causation.

Also, I'm kind of surprised at the customer service numbers. Chatbots existed before ChatGPT. Are LLMs more effective than the previous solutions at decreasing escalation to humans? Or could it be other factors like the economy at large causing companies to make do with less customer service?

Didn't know Git had a bisect feature. I'll keep that in mind for later.

Other than bisect though, I do think a lot of the practices outlined in the article (checking the blame, logs, search, etc) is way easier to do in a web UI, at least for someone like me who hasn't tailored their workflow for the command line. The tooling is so ubiquitous that it's easily available. I personally think GitHub does okay in those regards.

Bitbucket dropped Mercurial support in 2020: https://bitbucket.org/blog/sunsetting-mercurial-support-in-b...

I just don't think there is good RoI for implementing Mercurial support. It really isn't about the interface (which I think most people agree hg is better than git). It's just the network effect: most projects use git so everybody learns git and they don't want to learn another tool even if it's better in some ways. At the end of the day, once you pay a higher upfront cost to learn the ~5 git invocations you need, your daily productivity between using git and hg is probably the same.

Google and Facebook is different: they have a unique use-case and scale, and massive internal tooling teams supporting their use-cases. Also, as an employee, you're probably more open to different VCS systems because if you learn hg at Facebook, you're learning it on company time whereas if you learn for an open source project, you're learning it on your time.

I agree there doesn't seem to be a good connection between work on version control and work on code search.

However, I don't think it makes sense to downplay git5. Anecdotally, basically everybody knew about it, and I'd constantly run into people using it (which is by itself noteworthy since nobody was exactly talking about version control all the time).

Git5 was at the time the most robust solution to chain commits, which was tedious bordering on impossible without some tool. Without definitive data, I wouldn't say users were less productive with git5: it definitely was a useful tool that people at least recommended for chain commits. I was definitely more productive with it.

There were a lot of footguns though, and I do think the hg wrapper that superseded it was way better.

At the risk of being overly critical sour grapes, I really had tools like Monibot in mind when creating Catalyst.

Out of the box, Monibot throws a bunch of data at you like database size, CPU %, requests, etc. None of these metrics really tell you if something in your webapp is broken. And if you want more useful metrics, you gotta instrument them yourself.

It does do some things that Catalyst critically misses (health checks, e-mail notifications). But at the same time, if you're going to prod, Monibot by itself is not something you'd be comfortable with. You're going to need to add other monitoring tools to get that peace of mind.

Hey, so right now while it's under development, it's free. Quite frankly, I'm not too familiar with pricing for monitoring tools, so I'd love any suggestions here.

Very cool, is Next support planned?

It's definitely in the pipeline!

How much traffic can it handle and what's the pricing for cloud? Can't find pricing on your site.

So right now, it's still under development, but if you have a small/medium sized project (like 5QPS maybe), it should work. Pricing is free for now while it's under development.

How are you different from the 20+ existing monitoring solutions?

You've listed a lot of different types of monitoring tools. You have error reporting, session replay, log muxing, metric dashboards, and distributed tracing.

Catalyst combines a few key features from each category, and makes them play well together. For example, you can find a broken endpoint via the error graph and click on the line to get a breakdown of path params, logs, and errors for that specific endpoint. You can filter by these breakdowns to find matching sessions (which is like tracing + session replay). You can basically go from identifying an error, to finding the underlying cause of the error quickly in one dashboard.

In my experience, most tools don't play well together, like if you see a rise in error rates for an endpoint in your dashboard, then you need to make a separate query in your logging tool or your distributed tracing tool if your tools even give you the fidelity to know what to look for. You end up having to compose (and pay for) multiple tools.Even platforms that provide multiple features like DataDog and SigNoz, the features are separate and don't interact.

Philosophically, Catalyst doesn't just want to optimize for setup time, it also wants to optimize for peace of mind time, i.e. you're confident if your webapp is broken, you'll know. Most existing monitoring solutions just dump data at you, and ask you pick out what's important, and a lot of times they don't give you the fidelity you need.

You an see a (very quickly made) demo here: https://www.loom.com/share/5b38a328ded94f93a980f1ba28081329?...

Thanks! Let get a demo video going. In the meantime, there are little snippets of the UI on https://www.catalystmonitor.com/.

It's a bit like Datadog in the sense that you do have dashboards but it doesn't monitor blackbox metrics (like CPU %, etc), and focuses on whitebox metrics like error %.

What Datadog and other monitoring products don't do (AFAIK) is give you the ability to drill into your error %. You can breakdown your frontend pages and backend endpoints by path params, status code, log messages, (and soon) user to find commonalities and narrow down your smoking gun. After you find your smoking gun, you can immediately get traces and log messages of what happened from frontend to backend.

For example, if I notice a server endpoint has a high error %, I can check my breakdowns to see if it's specific to a user or endpoint, and if there is any log messages that happened for every error. Once I've narrowed it down, I can quickly find sessions that include the server endpoint with the breakdowns I've selected, and see what happened on the frontend and backend(s). The idea is to provide this value with minimal setup.

Paging is definitely something that I want to implement.

Text is hard so I'll record a video.

I think it really depends on the leadership.

The worse case scenario is when the scenario you given: the "pet project," where a team goes nuts on a codebase they aren't maintaining, in which case it's effectively out-sourcing maintenance and tech debt.

Ideally, the home team leadership has a lot of leverage to push back on work by the away team, which means away team work is slow but at least it gets done.