How we got 1,500 GitHub stars by mixing time-tested technology with a fresh UI
medium.freecodecamp.com
How we got 1,500 GitHub stars by mixing time-tested technology with a fresh UI
1–10 of 37 posts
Re: How we got 1,500 GitHub stars by mixing time-tested technology with a fresh UI
#2Despite the title, the article raises an interesting point: why do we prefer new code, with less features, to old but robust projects.
> Unfortunately, we were affected by cognitive bias: old code is bad code. But the truth can be the opposite. The old code is battle-tested by thousands of users in hundreds of different projects. Most of the critical bugs have been fixed, the documentation is complete, there are tons of questions and answers on StackOverflow and Quora.
I'm quite guilty here; I've realized that I always check the date of the last commit on Github before testing a project. I feel like I do this more for small projects where documentation and use cases might be missing, and for which I'm expecting help from the community.
Re: How we got 1,500 GitHub stars by mixing time-tested technology with a fresh UI
#3Despite the title, the article raises an interesting point: why do we prefer new code, with less features, to old but robust projects. > Unfortunately, we were affected by cognitive bias: old code is bad code. But the truth can be the opposite. The old code is battle-tested by thousands of users in hundreds of different projects. Most of the critical bugs have been fixed, the documentation is complete, there are tons…
[deleted]
Re: How we got 1,500 GitHub stars by mixing time-tested technology with a fresh UI
#4Despite the title, the article raises an interesting point: why do we prefer new code, with less features, to old but robust projects. > Unfortunately, we were affected by cognitive bias: old code is bad code. But the truth can be the opposite. The old code is battle-tested by thousands of users in hundreds of different projects. Most of the critical bugs have been fixed, the documentation is complete, there are tons…
Old last commit date could mean two things:
1. Project left in unfinished state and development stalled, in which case it's reasonable to run away from it.
2. Project done (fulfilling it's purpose) and turned to maintenance mode, in which case I'd be quite happy (as a matter of fact I'd prefer) to use it as I know I'm dealing with a stable codebase and don't need to be afraid of breaking changes in the future.
I think it would help if maintainers would state the "completeness" in the README file.
Re: How we got 1,500 GitHub stars by mixing time-tested technology with a fresh UI
#5How much do github stars sell for these days?
Re: How we got 1,500 GitHub stars by mixing time-tested technology with a fresh UI
#6Despite the title, the article raises an interesting point: why do we prefer new code, with less features, to old but robust projects. > Unfortunately, we were affected by cognitive bias: old code is bad code. But the truth can be the opposite. The old code is battle-tested by thousands of users in hundreds of different projects. Most of the critical bugs have been fixed, the documentation is complete, there are tons…
I do that and then look at issues, if there are lots of issues with no solutions from the team behind it then I'll look for something else.
I might be that person looking for answers and never get support.
Re: How we got 1,500 GitHub stars by mixing time-tested technology with a fresh UI
#7Despite the title, the article raises an interesting point: why do we prefer new code, with less features, to old but robust projects. > Unfortunately, we were affected by cognitive bias: old code is bad code. But the truth can be the opposite. The old code is battle-tested by thousands of users in hundreds of different projects. Most of the critical bugs have been fixed, the documentation is complete, there are tons…
Maybe because we're swayed by superficial, yet impactful choices: the use of a "modern-looking webpage with a visually-attractive theme", the use of the latest technologies - or at least those the community is talking about, buzz around the project, etc.
I realize it's tedious, but even older projects could do with periodic updates to tutorials, documentation, webpage updates and outreach to draw new interest from the community.
Re: How we got 1,500 GitHub stars by mixing time-tested technology with a fresh UI
#8Ignoring the fact that Github Stars are a aweful metric for anything else than vanity, "More bells and whistles" feels like a terrible advice and you should much more focus on a "easy-to-get-started" readme with just the minimal amount of beels and whistles to effectively communicate what your thing is really about.
Re: How we got 1,500 GitHub stars by mixing time-tested technology with a fresh UI
#9Despite the title, the article raises an interesting point: why do we prefer new code, with less features, to old but robust projects. > Unfortunately, we were affected by cognitive bias: old code is bad code. But the truth can be the opposite. The old code is battle-tested by thousands of users in hundreds of different projects. Most of the critical bugs have been fixed, the documentation is complete, there are tons…
Maybe because we're swayed by superficial, yet impactful choices: the use of a "modern-looking webpage with a visually-attractive theme", the use of the latest technologies - or at least those the community is talking about, buzz around the project, etc. I realize it's tedious, but even older projects could do with periodic updates to tutorials, documentation, webpage updates and outreach to draw new interest from th…
"It may be stable, but is it pleasant?" to use, to develop with, etc. That matters. There is definitely a goldilocks zone for libraries/frameworks, where they're mature enough to be reasonable to use in production, but still recent enough to not require a lot of effort to bring up to date.
Re: How we got 1,500 GitHub stars by mixing time-tested technology with a fresh UI
#10Ignoring the fact that Github Stars are a aweful metric for anything else than vanity, "More bells and whistles" feels like a terrible advice and you should much more focus on a "easy-to-get-started" readme with just the minimal amount of beels and whistles to effectively communicate what your thing is really about.
I'm extatic one of my project reached 100 stars. Sometimes we need to feel good.