Personally, I don't ever give up on projects like this (the one he discussed in the article is a cool idea also).
I work on small projects like this, I get them to a point, I pause. I come back a day or a week or a year later when I need it again (and find it broken) or want to add some feature. Sometimes I hate my code and want to rewrite it from scratch but I try to avoid that impulse as much as I can.
For me the key is to just never think of it as "giving up", I'm just not working on a particular project right now.
I agree, and I think the author does too. Note that they said they were "putting it back on the shelf" and were willing to come back to it.
I think distance and time can help with perspective, too. In a number of projects, stepping away (especially during the rat-holing on useless cruft features or w/e sections) and coming back later can help bring some good clarity.
Author here. I think all the buzz that this is getting make me want to give it another shot. I'll probably throw away most of the code and start from scratch though - one thing I learned from programmers much smarter than me is that the first solution is never the best one.
I don’t think you need to throw your code away, I think you need to fix your ranking algorithm. People use Craigslist even though it’s got minimal styling. CSS isn’t UX.
And to fix your ranking algo you need to understand places more deeply. The core of your product. You mentioned yourself that ranking by page views was flawed.
First of all, it seems that you can probably categorize places into a distinct set of categories. Historical landmarks, locations of past events, locations of ongoing or regular events, buildings for large businesses or government, metro areas (cities, counties, states) etc. Figure out what you actually think is interesting.
Probably don’t include a link to Manhattan on your map next to a local business for example.
Choose a city you’re not familiar with and figure out if the top links are interesting to you. Tweak your algorithm and check another city. Simple isn’t always good, the world is messy and you’ll have a lot of edge cases.
Is your use case "I'm a tourist in New York, who would like to learn more about my whereabouts." or "I live in New York, and I would like to be surprised with historic facts about places in my community", or what?
Divide into testing market/user-experience vs technical hypotheses:
"Would it be fun" you can test by faking it, like curating it by hand for a small specific area (e.g. a popular street in a popular part of a popular city; or your hometown; or somewhere that appeals/you want to visit).
"Can I make a general algorithm using publically available data to do this for everyone, for everywhere, automatically" is the technical hypothesis. It seems like a really challenging problem! But because it is clearly defined and scope-limited, I feel it's more straightforward than the first one.
Can't read the artice but I do have some generic observations.
Most projects aren't going to work, so that can be one of the primary goals, mainly to find out whether or not that's the case, without too many compromises.
So most of the time to be realistic you have to try real hard for it not to work quite early on, or that could be something where you end up wasting too much time on a hopeless effort.
Some people never quit, and it can be difficult to know when to mothball something or give up altogether.
Mothballs can be your friend, especially when there are a greater number of promising projects than could ever be fully completed anyway.
Progress can surprise you though, but more often than not many things will take an unexpected downturn before you ever see a case of an unexpected upturn.
Yeah "the shelf" is where projects go. Never give up.
There's some kinda weird zombie projects though;
Project Deja-Vu: halfway through a new project you have a vague
recollection of having done something similar before, and when you
search your archives and find exactly what you're working on - even
with the same comments (maybe this is an age related thing )
Project "Father give me legs...": Every time you look at it you're
overwhelmed with a wave of guilt, memories of broken promises...
Project impossible: It's a brilliant idea, everything works except
that one NP-complete quantum-entangled function to send SMS text
messages backwards in time to remind yourself not to do something.
Writing small, unfinished projects is great ! At least I think so. It's what keeps me passionate. It's a way to learn new things (language, framework, etc...).
I don't like much the phrasing "I give up". How about "I had fun, learned while enjoying it, and now move on to my next unfinished project". Great article though !
Thanks for reading! I came to the same conclusion. I don't see people post about their "failures" enough (although true failures are rare because you can always learn something from them) so I figured this would be a good thing to share.
That's true, I guess we see a lot of "success project" and feel ashamed to share our projects with half-started README. But what a great coffee-with-colleague-topic it makes !
I love to do small projects even if they technically don't finish. Sometimes those are useful later down the road when I am working on a bigger project and that little project comes in handy. For example, I just created my own poor man's CMS in Go that processes Markdown to HTML. A while ago, I had played around basic Go library that does that so I just used it easily in my project without needing to spend too much time figuring out that library.
Sounds like the general definition of "finish" doesn't match with your own. One could "complete" or "finish" a project if the goal was to learn something specific (or general), although others wouldn't considered it finished unless it was deployed and others use it.
I think lots of us would be better off if we redefined "finish" to basically mean "done", which you can define however you want :)
Wow, I really like that rule. I’ll often discourage myself from playing with a POC because of how nebulous the timeline can feel. I’m going to this that next time.
Author here and I 100% agree. The reason I was able to get a lot of the prototyping done within the first few days is by using ChatGPT. On the flipside I think the code that it wrote was not very maintainable so I should have started from scratch after validating my PoC.
I think this is really important, because pushing through on one project that's not working makes you neglect other projects that are more deserving of your time, attention, effort, love, blood, sweat and tears. Opportunity cost.
I had a really compelling but unproven idea once, for a gap in the market for a library. I made an absurdly ruthlessly minimal prototype in 2 hours; then spent 1 long day (9 hours) making a website. My rule was if no one appreciated it in 10 days, I'd forget it. Someone did, and it ended up making me ramen-FU-money.
This. I have done this for 30 years and never, ever thought about a side project “this could be a commercial success”.
What’s described here is a lot further along than I normally take a project.
There is always a more interesting project to make that has no potential of being “successful” than the most interesting idea among potentially successful projects.
I think for some people the entrepreneurial angle itself is enough to make a project attractive. But I never quite understood it.
I also never ponder personal projects from a commercial standpoint. But I sure see that narrative here on HN frequently.
I have to conclude that most people on HN talking about commercializing are doing purely software projects.
My projects very often include hardware. Commercializing hardware+software projects is hard... orders of magnitude harder than just software. That's probably a factor in why the idea of making money from wiring/soldering/dremeling/hacking things is so far from the forefront of my mind.
As for what's attractive... novelty and usability/street cred do seem to be my subconcious goals. "Street cred" or even just aspiring to have people use a software tool is certainly a form of non-profitable entrepreneurship.
Street cred is a pretty big part of why anyone does anything. Money is one way to get that but having something that no one else does is even better in my opinion. I spent a few weeks making a custom version of a board game that I really enjoy and while I could never commercialize it (for copyright, trademark, and a whole slew of other intellectual property reasons), I think having it for myself makes it even more valuable.
I think it is a common dream of escaping 9-5 worklife. I find myself trapped in that quite often, trading fun for possibility of financial independence.
I think your attitude is healthier. But fame and fortune do attract people. There is also something else exciting about a gap in the market: a kind of discovery and a way for the impact and usefulness of your efforts to be multiplied.
Same here for physical "ideas"/ecommerce stuff. By constantly "failing", I've gotten very efficient at knowing whether an idea or product is worth attempting.
I will say there is a certain charm to being ignorant that I've seen bring people success (including myself). I've attempted ambitious SEO projects when I was less experienced and succeeded, and looking back in hindsight they were pretty crazy given the success odds.
I can see becoming more efficient at feeling confident in your opinion, but how can you know you were right - particularly the ones you dismissed? (Though I don't know what else one could do).
> Our philosophy is to find the fun first and do a lot of prototyping and a lot of iterating very early on. There are probably more projects that I've worked on that haven't turned into final games than have.
> We have ideas. We have prototypes. We spend a lot of time trying out ideas. Probably two-thirds of them don’t end up going anywhere, but experimenting with those kinds of things is fun.
To answer the OP question, I can't find the interview I was looking for now, but I remember that he said that he stops working on a prototype when he realizes that he's learned enough from it.
I think unfinished projects are important. On a personal level, I've had many unfinished projects that felt (at the time) like failures. At one point in time, I had two different ideas for parse libraries that I had to give up on because I couldn't figure out how to make them work in a way that was remotely useful. However, a few years later, I was able to create a third, otherwise unrelated, project that I realized I could use to unify the previous two.
If you're not running into situations where you have to put away a project as unfinished then it might mean that you're not pushing yourself to and beyond your capabilities (which, depending on your goals, can be totally fine). And just because something ends up unfinished, doesn't mean that it might not be able to come back later in a different form.
I think these are necessary pre-requisites to larger projects that you may try to bring to market. If it's too daunting and you can't ever finish then the reality is you're probably not yet competent enough. Hayao Miyazaki went through thousands of unfinished short stories and Manga before working at Toei and other studios then he finally developed enough confidence and competence and started hitting homeruns later. It wouldn't have happened without that prior buildup over decades.
I have spent my middle and high-school years writing about 1000 games. Literally. Most of them I just stopped when the interesting part was done. I have kind of finished like 5-6 at all.
Best time of my life.
Also sometimes wrote (finished) software for companies as a freelancer.
Then I finished high-school and started uni where my startup was founded with a friend. I had a successful exit lately.
For me, due to life circumstances of severe chronic pain, until relatively recently my life and projects were mostly on hold.
To cope with my projects "dying" 10+ years ago from no longer being able to work on them, aside from the grief of going through my entrepreneurial baby "dying" - the main project I was working on and putting all of my effort on, and was going well - I began to tell myself that things were simply on hold, on the backburner, and I will revisit them again in the future.
My ideas and understanding and strategy since evolved, and so even though I wasn't actively working on projects - they and myself were still evolving.
Totally agree! I have so many unfinished projects, but I also find that I end up using bits and pieces from those unfinished projects in new stuff. I always learn something from them.
I’ll be blunt. You were being a perfectionist. That is a guaranteed way to kill momentum and ensure you never have any fun.
So the algorithm wasn’t great and the map was slow. Rome wasn’t built in a day. I get it, you have a vision in your head for how you want it to work and it wasn’t there yet. But this is actually a psychology problem and not a project problem.
I was about to say, it loaded pretty quickly and I found two interesting places right around the corner from where I live. If this is a "failure", I'd hate to hear how he classifies my personal projects...
Could you elaborate on it being a "psychology problem" please?
I agree with your perfectionism point; but how to test the hypothesis that it would be "fun"? A rough prototype can easily not be fun, even if the hypothesis is true! User experience seems hard...
Perhaps this is the reason for Mark Cerny's Method in game dev: to complete a slice of a AAA game to shippable standard, to tell if it's worth completing. Because players can't evaluate the experience of a game without the finished game. It's a hell of a lot of work, like $3 million; but doing just a slice makes it less than the $30 million for the whole game.
Whereas, for some reason, for Zelda: Breath of the Wild, they developed a cheap 2D prototype to test out their "physics" and "chemistry" ideas. How were they able to test their hypothesis so cheaply?
What makes a hypothesis cheap to test? Is it a bit like unit tests versus functional tests?
I think it’s more like lack of focus and priority.
The author identified all the things they needed to do, and described the process of doing everything but those things despite seemingly knowing exactly what was needed contemporaneously.
Obviously it’s no fun to try and force a non-fun project through to the end, and I agree with the author’s analysis that they should have stopped sooner.
I’m guessing it wasn’t fun which is why the author did what I often do when I sit down at my computer to work and want to blow it off: I spend a bunch of irrelevant time physically close to where work happens, but I don’t do any work.
In this instance, I'm not sure why the author is giving up.
That said, I do find in industry it's worth knowing how and when to kill a project. I always push for the creation of a kill list when ideation begins.
I think its usually when the project becomes a burden (the author notes as such in the conclusion), this is a bit simplistic as sometimes you just have to push past this to get somewhere, but if its a hobby project it should bring you some joy. When you see yourself doing fake productivity its bad news.
I also find that sometimes I will scope tasks too big, take too long to finish them and get demotivated, if I break them up further I can keep momentum (even if the breakup is during the original task).
Having said that I don't think giving up is necessarily a failure case that people think it is, I often take a lot of learnings after attempting to do very ambitious projects that I eventually scrap, but the learnings stay with me.
OK so they gave up after one month of tinkering because “the hypothesis was wrong”. Was it though?
The hypothesis was “if you could drag around a map to search for articles nearby and sort them by pageviews it would be more fun and could potentially help with vacation planning.”
After one month they realized it would be harder than they thought. They had a clear idea of how to proceed, but just didn’t want to do it. That's totally fine, but the original hypothesis was not really tested here.
You don’t even need a map UI to test the ranking algorithm. At least, simply sorting by page views is probably not ideal. Some recency bias would be useful.
I did skim, but I got the impression it was tested as a NO because of all the irrelevant articles (whole city pages, death of Epstein etc. )
This is the scraping tarpit! And why I avoid scraping projects. Even if there is a nice api it is still like a scraping project as there is tonnes of raw crap to deal with and categorise.
Machine learning might help. Not necessarily a LLM but could just use attention architecture to predict yes/no relevant or irrelevant, maybe.
> there is tonnes of raw crap to deal with and categorise
This is a fair use case for LLMs. "Read this article and decide if it meets this criteria". There will be some false positives and some false negatives but it will probably have a 95%+ success rate out of the box, which is more than good enough for a project like this.
This works. I recently used this approach to find baby names on Reddit. I would show GPT a list of articles and ask "list the article IDs among these which appear to be about baby names". Then further show each of those articles and ask "what baby names were mentioned in this post and its replies?".
Could it be done with “scroll around on a map” performance? I would think you’d have to process the whole Wikipedia data set ahead of time. I don’t know if that’s difficult or not.
I would bet it could be made to be that performant.
You wouldn't need full GPT-4 performance to do this sort of sentiment analysis, a cheaper, faster model would work fine.
Furthermore, you wouldn't need to ingest the whole article; just the intro paragraph would be fine. Overwhelmingly, the information needed to determine if this is the sort of article suitable for inclusion is in the intro section at the very top of the page; just one or a couple paragraphs.
Add to that that every page could be run in parallel, and you're looking at probably less than two seconds of processing time for loading all articles in an arbitrary location.
Bonus points that an article's suitability is unlikely to change, so this only needs to be done once, and then the article's id and suitability bool can be stored in a table somewhere.
I ran across it trying to solve a (regime of) a problem in proteomics, but it’s got old-school P(click | impression) style problems written all over it.
> I think the biggest takeaway from this is that if something is worth building, you'll know right away. A barely functional prototype from another project I worked on almost 4 years ago got over 1000 upvotes on Reddit in a day just based off of a gif.
I like the rest but I think this is very wrong.
It’s very easy to simply imagine your idea is good and will be good if well executed. This is especially true in games.
A well-executed game can be fun, when a poorly-executed version of the same idea is not. But if execution is everything, how can you experiment to test the hypothesis without making the whole thing?
This is the point of prototyping. You implement important game mechanics and interactions with just enough fidelity for it to be believable. If it’s fun, you’re on the right track.
So, important game mechanics and interactions, not the entire game.
If it's fun even without full-fidelity, it's fun. But if it's not fun, it might just be the lack of fidelity - not believable enough. I guess one needs an opinion for how much fidelity is enough to know, for the specific mechanics/interactions.
EDIT can always increase fidelity.
Through this discussion, I realize I'm more interested in "feel" than fun as such - e.g. a sense of place, being somewhere, in a walking simulator; or the feel of guns in COD. Not a mechanic; but perhaps a kind of interaction.
Not necessarily "cinematic", but probably more akin to issues in cinema than game mechanics.
I suppose one can still isolate an aspect and iterate on it; but it seems fidelity is important here...
Games don't get more fun with more fidelity, minecraft and terraria are very low fidelity but still fun. Fidelity improves other aspects, but not the "fun" part. Audio feedback and visual feedback are very important for fun though, like the knocking you hear when hitting things in minecraft and blopping from picking things up, but it is better to try to make things fun without that at first since those can make just clicking around in a forum fun.
Execution is not everything. A well executed concept of a bad vision is still not great.
People love to pretend that game dev is just a matter of prototyping to find a fun mechanic, and while that can be true for a few things (mostly niche movement), it’s generally not true of most games. It’s important to identify where the player consciousness is within a game.
Binding of Isaac, to pick something somewhat random. It probably wouldn’t be that fun doing random rooms to prototype. It probably wouldn’t be fun doing random items. It has to be a whole sequence of runs before you get the feeling that it works.
> the fact that the popups often don't load until all the page views are fetched (I'm assuming because of some rate limiting on Wikipedia's side),
Its a nice idea, but the Wiki backend might be the reason why they abandoned their own geolocating website efforts, which might be what you are now experiencing.
I think it would be nice for Wiki, to have an option which includes geolocated wiki articles in the surrounding area, just like they have the "see also" at the bottom of the page sometimes.
Problem with this though, is this feature might also not exist to prevent article stuffing in tourist areas, or area's where realtors/estate agents might be trying to sell expensive property.
For OP, maybe he could’ve simplified the problem to test it. Limit your articles to ones about one city only. Cache all of the links on your machine. There’s only 6 million English articles on Wikipedia anyways, and you can download a dump to play with.
If the limiting factor becomes your radius of articles, you know you’re on the right track.
Sometimes a prototype takes longer than a couple of days to build out. That's ok too. I’ve been working on a prototype for the last 6 months but I enjoy the problem.
> and many of the prominent articles that showed up were things like YouTube headquarters shooting" and "Death of Jeffrey Epstein" while more interesting places like "Pittock Mansion" and "Ghirardelli Square" were hard to come by.
I had a very similar project idea few years ago, but I was going to use wikitravel.org as the source of data.
There’s no answer to “when you should give up” even in the case where you say you are gonna make the next Facebook, who’s to say you should give up? You give up when you give up and you learn about yourself so the next time you can make better judgement.
I do think sometimes it helps to finish a project and ship, you can be surprised that your internal dialog is different than what others think when they use it
As someone who also makes these kinds of things all the time (sometimes it works, most of the time it does not) — let me just thank you for the "fake productivity" angle you highlighted. I am right in the middle of one of those, pushing the launch further out, yet again, and reading your article made that crisp and clear (in my case: changing from SQlite back to MySQL, from JWT via Auth Header to JWT via Cookies, etc.).
I also wanted to mention that clearly knowing the hypothesis to test for at the very beginning isn't all that easy, in my opinion. A lot of the time, you need to walk down the path, even walk it for a good long while, until you hit the right angle or context to truly see where the project could land. You (hopefully) start these things with a "good enough" reason, but it often needs a lot of shaping and refining to get it all back into the light, for a wider audience.
Curiosity in learning new things will (should) always be a good part of what fuels the effort, it's a safety net (for me as a developer anyway), shielding me a bit from ending up with purely wasted time once it's clear that it didn't lead anywhere. At least I learned something new along the way.
Very cool prototype, and a very interesting idea to sort nearby Wikipedia articles by number of pageviews.
Just a note that the Wikipedia app for iOS does in fact have a map with nearby articles, and we will soon bring the feature (back) to the Android version.
As soon as you know it won't work. Of course, that's the hard part. The level of near-delusion required to get something off the ground makes it very difficult to know when to let go.
I must be missing something… wikipedias app on my iPhone does have search by location feature. Is the author talking about this missing feature on android perhaps?
131 comments
[ 2.6 ms ] story [ 245 ms ] threadI work on small projects like this, I get them to a point, I pause. I come back a day or a week or a year later when I need it again (and find it broken) or want to add some feature. Sometimes I hate my code and want to rewrite it from scratch but I try to avoid that impulse as much as I can.
For me the key is to just never think of it as "giving up", I'm just not working on a particular project right now.
I think distance and time can help with perspective, too. In a number of projects, stepping away (especially during the rat-holing on useless cruft features or w/e sections) and coming back later can help bring some good clarity.
And to fix your ranking algo you need to understand places more deeply. The core of your product. You mentioned yourself that ranking by page views was flawed.
First of all, it seems that you can probably categorize places into a distinct set of categories. Historical landmarks, locations of past events, locations of ongoing or regular events, buildings for large businesses or government, metro areas (cities, counties, states) etc. Figure out what you actually think is interesting.
Probably don’t include a link to Manhattan on your map next to a local business for example.
Choose a city you’re not familiar with and figure out if the top links are interesting to you. Tweak your algorithm and check another city. Simple isn’t always good, the world is messy and you’ll have a lot of edge cases.
Is your use case "I'm a tourist in New York, who would like to learn more about my whereabouts." or "I live in New York, and I would like to be surprised with historic facts about places in my community", or what?
"Would it be fun" you can test by faking it, like curating it by hand for a small specific area (e.g. a popular street in a popular part of a popular city; or your hometown; or somewhere that appeals/you want to visit).
"Can I make a general algorithm using publically available data to do this for everyone, for everywhere, automatically" is the technical hypothesis. It seems like a really challenging problem! But because it is clearly defined and scope-limited, I feel it's more straightforward than the first one.
Most projects aren't going to work, so that can be one of the primary goals, mainly to find out whether or not that's the case, without too many compromises.
So most of the time to be realistic you have to try real hard for it not to work quite early on, or that could be something where you end up wasting too much time on a hopeless effort.
Some people never quit, and it can be difficult to know when to mothball something or give up altogether.
Mothballs can be your friend, especially when there are a greater number of promising projects than could ever be fully completed anyway.
Progress can surprise you though, but more often than not many things will take an unexpected downturn before you ever see a case of an unexpected upturn.
There's some kinda weird zombie projects though;
Project Deja-Vu: halfway through a new project you have a vague recollection of having done something similar before, and when you search your archives and find exactly what you're working on - even with the same comments (maybe this is an age related thing )
Project "Father give me legs...": Every time you look at it you're overwhelmed with a wave of guilt, memories of broken promises...
Project impossible: It's a brilliant idea, everything works except that one NP-complete quantum-entangled function to send SMS text messages backwards in time to remind yourself not to do something.
I don't like much the phrasing "I give up". How about "I had fun, learned while enjoying it, and now move on to my next unfinished project". Great article though !
I think lots of us would be better off if we redefined "finish" to basically mean "done", which you can define however you want :)
I have many unfinished projects.
The goal was not to build a thing - it usually was more an excuse to learn.
Although sometimes it was to build a thing. I once wrote a podcast downloader in powershell because all the ones out there sucked.
Worst case you’ve learned something new or had fun.
I am yet to regret a single instance when I regretted sharing unfinished, scrappy work:
https://untested.sonnet.io/Share+your+unfinished%2C+scrappy+...
One approach I really liked was the 2/2/2 rule:
2 hours for a poc → does this even make sense?
2 days for a prototype to share with friends
2 weeks to build something useful (paid if your goal is to charge for it)
You can leave the process at any stage. Each stage teaches you something new.
I had a really compelling but unproven idea once, for a gap in the market for a library. I made an absurdly ruthlessly minimal prototype in 2 hours; then spent 1 long day (9 hours) making a website. My rule was if no one appreciated it in 10 days, I'd forget it. Someone did, and it ended up making me ramen-FU-money.
Can relate. I think the problematic word is "complete"; it's a kind of perfect. Initially aim at incomplete/minimal, then build.
What’s described here is a lot further along than I normally take a project.
There is always a more interesting project to make that has no potential of being “successful” than the most interesting idea among potentially successful projects.
I think for some people the entrepreneurial angle itself is enough to make a project attractive. But I never quite understood it.
Someday maybe, but if not, that's fine anyway because I learned something and had some fun.
I have to conclude that most people on HN talking about commercializing are doing purely software projects.
My projects very often include hardware. Commercializing hardware+software projects is hard... orders of magnitude harder than just software. That's probably a factor in why the idea of making money from wiring/soldering/dremeling/hacking things is so far from the forefront of my mind.
As for what's attractive... novelty and usability/street cred do seem to be my subconcious goals. "Street cred" or even just aspiring to have people use a software tool is certainly a form of non-profitable entrepreneurship.
You are allowed to do things just for fun.
I think it is a common dream of escaping 9-5 worklife. I find myself trapped in that quite often, trading fun for possibility of financial independence.
I will say there is a certain charm to being ignorant that I've seen bring people success (including myself). I've attempted ambitious SEO projects when I was less experienced and succeeded, and looking back in hindsight they were pretty crazy given the success odds.
Never tell me the odds.
> Our philosophy is to find the fun first and do a lot of prototyping and a lot of iterating very early on. There are probably more projects that I've worked on that haven't turned into final games than have.
> We have ideas. We have prototypes. We spend a lot of time trying out ideas. Probably two-thirds of them don’t end up going anywhere, but experimenting with those kinds of things is fun.
To answer the OP question, I can't find the interview I was looking for now, but I remember that he said that he stops working on a prototype when he realizes that he's learned enough from it.
If you're not running into situations where you have to put away a project as unfinished then it might mean that you're not pushing yourself to and beyond your capabilities (which, depending on your goals, can be totally fine). And just because something ends up unfinished, doesn't mean that it might not be able to come back later in a different form.
Best time of my life.
Also sometimes wrote (finished) software for companies as a freelancer.
Then I finished high-school and started uni where my startup was founded with a friend. I had a successful exit lately.
https://joeldare.com/how-to-lose-money-with-25-years-of-fail...
For me, due to life circumstances of severe chronic pain, until relatively recently my life and projects were mostly on hold.
To cope with my projects "dying" 10+ years ago from no longer being able to work on them, aside from the grief of going through my entrepreneurial baby "dying" - the main project I was working on and putting all of my effort on, and was going well - I began to tell myself that things were simply on hold, on the backburner, and I will revisit them again in the future.
My ideas and understanding and strategy since evolved, and so even though I wasn't actively working on projects - they and myself were still evolving.
So the algorithm wasn’t great and the map was slow. Rome wasn’t built in a day. I get it, you have a vision in your head for how you want it to work and it wasn’t there yet. But this is actually a psychology problem and not a project problem.
I agree with your perfectionism point; but how to test the hypothesis that it would be "fun"? A rough prototype can easily not be fun, even if the hypothesis is true! User experience seems hard...
Perhaps this is the reason for Mark Cerny's Method in game dev: to complete a slice of a AAA game to shippable standard, to tell if it's worth completing. Because players can't evaluate the experience of a game without the finished game. It's a hell of a lot of work, like $3 million; but doing just a slice makes it less than the $30 million for the whole game.
Whereas, for some reason, for Zelda: Breath of the Wild, they developed a cheap 2D prototype to test out their "physics" and "chemistry" ideas. How were they able to test their hypothesis so cheaply?
What makes a hypothesis cheap to test? Is it a bit like unit tests versus functional tests?
The author identified all the things they needed to do, and described the process of doing everything but those things despite seemingly knowing exactly what was needed contemporaneously.
Obviously it’s no fun to try and force a non-fun project through to the end, and I agree with the author’s analysis that they should have stopped sooner.
I’m guessing it wasn’t fun which is why the author did what I often do when I sit down at my computer to work and want to blow it off: I spend a bunch of irrelevant time physically close to where work happens, but I don’t do any work.
That said, I do find in industry it's worth knowing how and when to kill a project. I always push for the creation of a kill list when ideation begins.
I also find that sometimes I will scope tasks too big, take too long to finish them and get demotivated, if I break them up further I can keep momentum (even if the breakup is during the original task).
Having said that I don't think giving up is necessarily a failure case that people think it is, I often take a lot of learnings after attempting to do very ambitious projects that I eventually scrap, but the learnings stay with me.
The hypothesis was “if you could drag around a map to search for articles nearby and sort them by pageviews it would be more fun and could potentially help with vacation planning.”
After one month they realized it would be harder than they thought. They had a clear idea of how to proceed, but just didn’t want to do it. That's totally fine, but the original hypothesis was not really tested here.
This is the scraping tarpit! And why I avoid scraping projects. Even if there is a nice api it is still like a scraping project as there is tonnes of raw crap to deal with and categorise.
Machine learning might help. Not necessarily a LLM but could just use attention architecture to predict yes/no relevant or irrelevant, maybe.
This is a fair use case for LLMs. "Read this article and decide if it meets this criteria". There will be some false positives and some false negatives but it will probably have a 95%+ success rate out of the box, which is more than good enough for a project like this.
You wouldn't need full GPT-4 performance to do this sort of sentiment analysis, a cheaper, faster model would work fine.
Furthermore, you wouldn't need to ingest the whole article; just the intro paragraph would be fine. Overwhelmingly, the information needed to determine if this is the sort of article suitable for inclusion is in the intro section at the very top of the page; just one or a couple paragraphs.
Add to that that every page could be run in parallel, and you're looking at probably less than two seconds of processing time for loading all articles in an arbitrary location.
Bonus points that an article's suitability is unlikely to change, so this only needs to be done once, and then the article's id and suitability bool can be stored in a table somewhere.
https://static.googleusercontent.com/media/research.google.c...
I ran across it trying to solve a (regime of) a problem in proteomics, but it’s got old-school P(click | impression) style problems written all over it.
I like the rest but I think this is very wrong.
It’s very easy to simply imagine your idea is good and will be good if well executed. This is especially true in games.
A well-executed game can be fun, when a poorly-executed version of the same idea is not. But if execution is everything, how can you experiment to test the hypothesis without making the whole thing?
If it's fun even without full-fidelity, it's fun. But if it's not fun, it might just be the lack of fidelity - not believable enough. I guess one needs an opinion for how much fidelity is enough to know, for the specific mechanics/interactions.
EDIT can always increase fidelity.
Through this discussion, I realize I'm more interested in "feel" than fun as such - e.g. a sense of place, being somewhere, in a walking simulator; or the feel of guns in COD. Not a mechanic; but perhaps a kind of interaction.
Not necessarily "cinematic", but probably more akin to issues in cinema than game mechanics.
I suppose one can still isolate an aspect and iterate on it; but it seems fidelity is important here...
Your point on a/v feedback reminds me of "cow clicker", started as a joke, creating the idle-game genre.
People love to pretend that game dev is just a matter of prototyping to find a fun mechanic, and while that can be true for a few things (mostly niche movement), it’s generally not true of most games. It’s important to identify where the player consciousness is within a game.
Binding of Isaac, to pick something somewhat random. It probably wouldn’t be that fun doing random rooms to prototype. It probably wouldn’t be fun doing random items. It has to be a whole sequence of runs before you get the feeling that it works.
Its a nice idea, but the Wiki backend might be the reason why they abandoned their own geolocating website efforts, which might be what you are now experiencing.
I think it would be nice for Wiki, to have an option which includes geolocated wiki articles in the surrounding area, just like they have the "see also" at the bottom of the page sometimes.
Problem with this though, is this feature might also not exist to prevent article stuffing in tourist areas, or area's where realtors/estate agents might be trying to sell expensive property.
Nice effort and article.
If the limiting factor becomes your radius of articles, you know you’re on the right track.
Sometimes a prototype takes longer than a couple of days to build out. That's ok too. I’ve been working on a prototype for the last 6 months but I enjoy the problem.
I had a very similar project idea few years ago, but I was going to use wikitravel.org as the source of data.
I do think sometimes it helps to finish a project and ship, you can be surprised that your internal dialog is different than what others think when they use it
I also wanted to mention that clearly knowing the hypothesis to test for at the very beginning isn't all that easy, in my opinion. A lot of the time, you need to walk down the path, even walk it for a good long while, until you hit the right angle or context to truly see where the project could land. You (hopefully) start these things with a "good enough" reason, but it often needs a lot of shaping and refining to get it all back into the light, for a wider audience.
Curiosity in learning new things will (should) always be a good part of what fuels the effort, it's a safety net (for me as a developer anyway), shielding me a bit from ending up with purely wasted time once it's clear that it didn't lead anywhere. At least I learned something new along the way.
Just a note that the Wikipedia app for iOS does in fact have a map with nearby articles, and we will soon bring the feature (back) to the Android version.