Awesome and congrats, I might use this if I start training again (company pays the gym now!)
Tell HN: I made $1000 with my app and now making $500/mo
141–150 of 186 posts
Re: Tell HN: I made $1000 with my app and now making $500/mo
#142This is really cool. I've worked on a lot of side projects in my free time, and my most successful one (https://apps.apple.com/us/app/id1607228378) pulls in just $11 in MRR. Even though it's so little, I get really excited when I get a new subscription or a subscription renews.
I've had a lot of trouble trying to market the app. I've experimented with Instagram ads, but the conversion rates were really bad. I'll try the Instagram accounts strategy you mentioned and hopefully that helps.
Re: Tell HN: I made $1000 with my app and now making $500/mo
#143Earlier quoted context omitted.
Alternatively (I know nothing about the domain) perhaps allow the choice for free? (Needn't be 'tell me your gender here's data sharing agreement blah blah blah', could just be a choice between '~33lb' and ..whatever the current is that's apparently more appropriate for men.)
Yeah that's what I meant, sorry if I wasn't clear!
Ah sorry - I read it as 'offer the full free-form weight [that it is/I assumed it is with payment] for free'.
Re: Tell HN: I made $1000 with my app and now making $500/mo
#144>I can't pretend to have derived any life lesson that applies to everybody from this Part of what attracted me to software engineering in the first place was an interest in "how things work", and being able to move between levels of abstraction (e.g. I know how IP, DNS, TCP, HTTP and JSON works, but most of the time I can just treat it as "sending objects"). So it was a bit of a eureka moment for me to realize that r…
> It doesn't matter how well you code if people can't understand the user interface
The variation on it I like to emphasize is: it also doesn't matter how "readable" your code is if the user/customer finds it broken, so stop trying to optimize for readability as the primary criterion.
{correctness, usability} to the customer > code maintainability > code readability
Re: Tell HN: I made $1000 with my app and now making $500/mo
#145>I can't pretend to have derived any life lesson that applies to everybody from this Part of what attracted me to software engineering in the first place was an interest in "how things work", and being able to move between levels of abstraction (e.g. I know how IP, DNS, TCP, HTTP and JSON works, but most of the time I can just treat it as "sending objects"). So it was a bit of a eureka moment for me to realize that r…
> It doesn't matter how well you code if people can't understand the user interface The variation on it I like to emphasize is: it also doesn't matter how "readable" your code is if the user/customer finds it broken, so stop trying to optimize for readability as the primary criterion. {correctness, usability} to the customer > code maintainability > code readability
I disagree. All else being equal, readability is the most important criteria. And readability is the greatest contributor to maintainability. Next to that, being "well-organized" is what makes something maintainable.
If your code is correct but unreadable or disorganized, it will be hard to extend.
If your code is incorrect, but organized and readable, it will be easy to fix.
If your code is incorrect and organized, but unreadable, it will be hard to fix and extend, but easy to make it more readable, thus more extensible and fixable.
If your code is incorrect and disorganized but readable, it will be hard to fix and extend, but easy to refactor, thus more extensible and fixable.
And code is always incorrect.
Re: Tell HN: I made $1000 with my app and now making $500/mo
#146Earlier quoted context omitted.
> It doesn't matter how well you code if people can't understand the user interface The variation on it I like to emphasize is: it also doesn't matter how "readable" your code is if the user/customer finds it broken, so stop trying to optimize for readability as the primary criterion. {correctness, usability} to the customer > code maintainability > code readability
I disagree. All else being equal, readability is the most important criteria. And readability is the greatest contributor to maintainability. Next to that, being "well-organized" is what makes something maintainable. If your code is correct but unreadable or disorganized, it will be hard to extend. If your code is incorrect, but organized and readable, it will be easy to fix. If your code is incorrect and organized,…
> If your code is incorrect and disorganized but readable, it will be hard to fix and extend, but easy to refactor, thus more extensible and fixable.
The state you want to reach is "fixed", not merely "fixable". I've seen too many people applying your reasoning staying perpetually stuck in the broken-but-"fixable" state because they prioritize "readability" higher, and I'm saying your users don't care about that. They want a fixed (read: correct) state.
> And code is always incorrect.
This makes a strawman of my argument.
Re: Tell HN: I made $1000 with my app and now making $500/mo
#147Earlier quoted context omitted.
I disagree. All else being equal, readability is the most important criteria. And readability is the greatest contributor to maintainability. Next to that, being "well-organized" is what makes something maintainable. If your code is correct but unreadable or disorganized, it will be hard to extend. If your code is incorrect, but organized and readable, it will be easy to fix. If your code is incorrect and organized,…
> If your code is incorrect and disorganized but readable, it will be hard to fix and extend, but easy to refactor, thus more extensible and fixable. The state you want to reach is "fixed", not merely "fixable". I've seen too many people applying your reasoning staying perpetually stuck in the broken-but-"fixable" state because they prioritize "readability" higher, and I'm saying your users don't care about that. The…
> The state you want to reach is "fixed", not merely "fixable".
And my argument is that readable code is the most direct route to that state.
> > And code is always incorrect.
> This makes a strawman of my argument.
It would if it was actually part of my argument, and not a cheeky parting shot.
Here's the straightforward version. In my experience, the most productive way to approach code is to assume that at some point a bug will be found, or you will have to extend it. You may disagree, of course, but my views all flow from this assumption.
Re: Tell HN: I made $1000 with my app and now making $500/mo
#148I do 5-3-1 workouts using a spreadsheet and that has been a mess. I really appreciate your solution.
Re: Tell HN: I made $1000 with my app and now making $500/mo
#149That's fantastic - congrats!
Re: Tell HN: I made $1000 with my app and now making $500/mo
#150>I can't pretend to have derived any life lesson that applies to everybody from this Part of what attracted me to software engineering in the first place was an interest in "how things work", and being able to move between levels of abstraction (e.g. I know how IP, DNS, TCP, HTTP and JSON works, but most of the time I can just treat it as "sending objects"). So it was a bit of a eureka moment for me to realize that r…
> It doesn't matter how well you code if people can't understand the user interface The variation on it I like to emphasize is: it also doesn't matter how "readable" your code is if the user/customer finds it broken, so stop trying to optimize for readability as the primary criterion. {correctness, usability} to the customer > code maintainability > code readability
Your code might need to be: usable, fast to market, readable, maintainable etc. You have to optimize for whatever conditions you need.