Tyler King
@tylerking.app
Professional hater. Co-founder / CEO of Less Annoying CRM. I talk about bootstrapping, tech, entrepreneurship, and business practices that annoy me.
Podcast: startuptolast.com
Podcast: startuptolast.com
I assumed that because you didn't refute it the last time we had this conversation: bsky.app/profile/tyle...
What you just shared isn't data, it's an anecdote. Just like me saying "Notion has more bugs than ever". It's ok for both of us to make these observations, but neither of us have "data"
What you just shared isn't data, it's an anecdote. Just like me saying "Notion has more bugs than ever". It's ok for both of us to make these observations, but neither of us have "data"
No one has data to back up their opinion on this topic. We're just talking on bluesky!
But I think it's pretty clear that software has not entered some golden age over the last couple years where improvements come much faster and there are way fewer bugs.
But I think it's pretty clear that software has not entered some golden age over the last couple years where improvements come much faster and there are way fewer bugs.
November 25, 2025 at 10:02 PM
I assumed that because you didn't refute it the last time we had this conversation: bsky.app/profile/tyle...
What you just shared isn't data, it's an anecdote. Just like me saying "Notion has more bugs than ever". It's ok for both of us to make these observations, but neither of us have "data"
What you just shared isn't data, it's an anecdote. Just like me saying "Notion has more bugs than ever". It's ok for both of us to make these observations, but neither of us have "data"
Sorry to be rude, but we've already discussed this. I don't have data, and neither do you. That's not an interesting thing to keep pointing out.
It's ok for conversations to be about personal experience, especially when many people can relate to that experience as is the case here.
It's ok for conversations to be about personal experience, especially when many people can relate to that experience as is the case here.
November 25, 2025 at 7:53 PM
Sorry to be rude, but we've already discussed this. I don't have data, and neither do you. That's not an interesting thing to keep pointing out.
It's ok for conversations to be about personal experience, especially when many people can relate to that experience as is the case here.
It's ok for conversations to be about personal experience, especially when many people can relate to that experience as is the case here.
I'd never heard of that before. Very interesting!
I'm not sure that in the case of subscription revenue, other businesses have to change (especially the ones I want to support which are mostly solo creator types who could certainly survive on one-off donations) but it's an interesting comparison
I'm not sure that in the case of subscription revenue, other businesses have to change (especially the ones I want to support which are mostly solo creator types who could certainly survive on one-off donations) but it's an interesting comparison
November 25, 2025 at 6:05 PM
I'd never heard of that before. Very interesting!
I'm not sure that in the case of subscription revenue, other businesses have to change (especially the ones I want to support which are mostly solo creator types who could certainly survive on one-off donations) but it's an interesting comparison
I'm not sure that in the case of subscription revenue, other businesses have to change (especially the ones I want to support which are mostly solo creator types who could certainly survive on one-off donations) but it's an interesting comparison
By "certain job roles" I mean something like support.
There's a fixed amount to do. If you're already giving fantastic support, doubling productivity doesn't really help.
But product/dev doesn't work that way. There's always more to do, so wouldn't laying people off be a competitive disadvantage?
There's a fixed amount to do. If you're already giving fantastic support, doubling productivity doesn't really help.
But product/dev doesn't work that way. There's always more to do, so wouldn't laying people off be a competitive disadvantage?
November 25, 2025 at 3:03 PM
By "certain job roles" I mean something like support.
There's a fixed amount to do. If you're already giving fantastic support, doubling productivity doesn't really help.
But product/dev doesn't work that way. There's always more to do, so wouldn't laying people off be a competitive disadvantage?
There's a fixed amount to do. If you're already giving fantastic support, doubling productivity doesn't really help.
But product/dev doesn't work that way. There's always more to do, so wouldn't laying people off be a competitive disadvantage?
Interesting point that you can't 2x dev productivity and expect results without also 2xing other roles.
But devs *are* the bottlenecks sometimes. Software quality has not improved. There are more bugs than ever. That's not because of a product/marketing bottleneck.
But devs *are* the bottlenecks sometimes. Software quality has not improved. There are more bugs than ever. That's not because of a product/marketing bottleneck.
November 25, 2025 at 2:59 PM
Interesting point that you can't 2x dev productivity and expect results without also 2xing other roles.
But devs *are* the bottlenecks sometimes. Software quality has not improved. There are more bugs than ever. That's not because of a product/marketing bottleneck.
But devs *are* the bottlenecks sometimes. Software quality has not improved. There are more bugs than ever. That's not because of a product/marketing bottleneck.
But if the products aren't better, doesn't that sort of hurt the argument that the workflow is better? Better input must result in better output or else it's not actually better.
(I think the best argument here is that there's just a lag and the output will show itself soon enough)
(I think the best argument here is that there's just a lag and the output will show itself soon enough)
November 25, 2025 at 1:21 AM
But if the products aren't better, doesn't that sort of hurt the argument that the workflow is better? Better input must result in better output or else it's not actually better.
(I think the best argument here is that there's just a lag and the output will show itself soon enough)
(I think the best argument here is that there's just a lag and the output will show itself soon enough)
Interesting. They're obviously talking their own book, but yeah, that's the closest I've seen to an explanation for how the work can feel entirely different while the results feel exactly the same.
November 24, 2025 at 1:08 PM
Interesting. They're obviously talking their own book, but yeah, that's the closest I've seen to an explanation for how the work can feel entirely different while the results feel exactly the same.
How do you collect that? Is it just a question on the free trial signup form?
November 24, 2025 at 4:28 AM
How do you collect that? Is it just a question on the free trial signup form?
No one has data to back up their opinion on this topic. We're just talking on bluesky!
But I think it's pretty clear that software has not entered some golden age over the last couple years where improvements come much faster and there are way fewer bugs.
But I think it's pretty clear that software has not entered some golden age over the last couple years where improvements come much faster and there are way fewer bugs.
November 22, 2025 at 12:57 PM
No one has data to back up their opinion on this topic. We're just talking on bluesky!
But I think it's pretty clear that software has not entered some golden age over the last couple years where improvements come much faster and there are way fewer bugs.
But I think it's pretty clear that software has not entered some golden age over the last couple years where improvements come much faster and there are way fewer bugs.
But this gets to the original question I asked: I hear individual devs like you say things like this. If true, it would suggest software should be getting much better. Open source projects should have way fewer bugs. But I don't see that actually happening.
This is not a golden age of software.
This is not a golden age of software.
November 22, 2025 at 12:12 PM
But this gets to the original question I asked: I hear individual devs like you say things like this. If true, it would suggest software should be getting much better. Open source projects should have way fewer bugs. But I don't see that actually happening.
This is not a golden age of software.
This is not a golden age of software.
I agree that a lot of new products are seeing results from AI. But which of these is true:
- The reason established products aren't seeing results is because they aren't trying hard enough
- Big projects don't benefit from AI in the same way, and the new projects will grind to a halt eventually
- The reason established products aren't seeing results is because they aren't trying hard enough
- Big projects don't benefit from AI in the same way, and the new projects will grind to a halt eventually
November 21, 2025 at 8:25 PM
I agree that a lot of new products are seeing results from AI. But which of these is true:
- The reason established products aren't seeing results is because they aren't trying hard enough
- Big projects don't benefit from AI in the same way, and the new projects will grind to a halt eventually
- The reason established products aren't seeing results is because they aren't trying hard enough
- Big projects don't benefit from AI in the same way, and the new projects will grind to a halt eventually
But established companies are *talking* as if they're adopting it quickly. Layoffs are happening because of it (I know that's not the real reason, but that's what they say). Valuations are changing based on it.
You'd think there'd be an example of it actually happening somewhere
You'd think there'd be an example of it actually happening somewhere
November 21, 2025 at 8:23 PM
But established companies are *talking* as if they're adopting it quickly. Layoffs are happening because of it (I know that's not the real reason, but that's what they say). Valuations are changing based on it.
You'd think there'd be an example of it actually happening somewhere
You'd think there'd be an example of it actually happening somewhere
This is similar to how I constantly see other bootstrapped SaaS founders share incredible numbers (lead gen, expansion revenue, increasing ARPU, etc.). The metrics imply these companies should be growing so fast they they surpass us in a matter of months.
And yet very few ever surpass us.
And yet very few ever surpass us.
November 21, 2025 at 7:31 PM
This is similar to how I constantly see other bootstrapped SaaS founders share incredible numbers (lead gen, expansion revenue, increasing ARPU, etc.). The metrics imply these companies should be growing so fast they they surpass us in a matter of months.
And yet very few ever surpass us.
And yet very few ever surpass us.
These aren't even marketing emails! They're just letting me know a shipping label has been printed and another one saying the package has been picked up by the delivery company and another one saying it's been assigned an estimated delivery date and another one...
November 20, 2025 at 1:25 PM
These aren't even marketing emails! They're just letting me know a shipping label has been printed and another one saying the package has been picked up by the delivery company and another one saying it's been assigned an estimated delivery date and another one...
Yeah, I have those all turned off because I don't really get the point. So many emails get miscategorized that I still have to check the other inboxes, so it just makes extra work checking them all instead of just one.
November 20, 2025 at 12:32 AM
Yeah, I have those all turned off because I don't really get the point. So many emails get miscategorized that I still have to check the other inboxes, so it just makes extra work checking them all instead of just one.
From what I can tell, I don't think FilterHawk would be able to determine if an email is an unimportant transaction email related to an ecommerce purchase unless I specifically set up filters telling it how to match that (e.g. a filter for each sender) which I don't think would really save me time.
November 19, 2025 at 9:26 PM
From what I can tell, I don't think FilterHawk would be able to determine if an email is an unimportant transaction email related to an ecommerce purchase unless I specifically set up filters telling it how to match that (e.g. a filter for each sender) which I don't think would really save me time.
At least with those I feel comfortable marking them as spam.
When they're transactional emails related to a purchase I just made, I can't really in good conscience call it spam, it's just annoying and unnecessary.
When they're transactional emails related to a purchase I just made, I can't really in good conscience call it spam, it's just annoying and unnecessary.
November 19, 2025 at 9:22 PM
At least with those I feel comfortable marking them as spam.
When they're transactional emails related to a purchase I just made, I can't really in good conscience call it spam, it's just annoying and unnecessary.
When they're transactional emails related to a purchase I just made, I can't really in good conscience call it spam, it's just annoying and unnecessary.
It's a bit of work to make the shrub, but this one is a real crowd pleaser: tylerking.notion.site/Sloe-In-The-...
For less winter and more fall: tylerking.notion.site/Apple-cider-...
For less winter and more fall: tylerking.notion.site/Apple-cider-...
Sloe In The Snow | Notion
Directions
tylerking.notion.site
November 18, 2025 at 11:44 PM
It's a bit of work to make the shrub, but this one is a real crowd pleaser: tylerking.notion.site/Sloe-In-The-...
For less winter and more fall: tylerking.notion.site/Apple-cider-...
For less winter and more fall: tylerking.notion.site/Apple-cider-...
This never really made sense to me because doesn't that mean unit tests can't test functions that call other functions, so only the very lowest level code can have unit tests?
And even that code depends on the compiler, etc.
So I think being a purist about unit tests is an untenable position.
And even that code depends on the compiler, etc.
So I think being a purist about unit tests is an untenable position.
November 17, 2025 at 3:01 PM
This never really made sense to me because doesn't that mean unit tests can't test functions that call other functions, so only the very lowest level code can have unit tests?
And even that code depends on the compiler, etc.
So I think being a purist about unit tests is an untenable position.
And even that code depends on the compiler, etc.
So I think being a purist about unit tests is an untenable position.
I don't feel confident speaking to php norms (I mostly do my own thing), but in college I was taught that unit tests test functions that are entirely self-contained and have no dependencies. The same input gives the same output without regard for anything else in your code base.
November 17, 2025 at 2:59 PM
I don't feel confident speaking to php norms (I mostly do my own thing), but in college I was taught that unit tests test functions that are entirely self-contained and have no dependencies. The same input gives the same output without regard for anything else in your code base.