I'm surprised by all the negative reactions. Of course you're not going to be making anything substantial in a month (most likely). Instead, you'll learn to actually finish (or semi-finish) projects and ship them regularly.
This is very much like One Game a Month (http://www.onegameamonth.com/). The idea is that write, learn, ship. It's nice.
If you find that one of your projects takes off, or you really like it, then continue to work on it.
> If you find that one of your projects takes off, or you really like it, then continue to work on it.
I think this is the thing. It's a slightly weird set of incentives for you to create a new project every month, irrespective of whether last month's worked out or not.
I'd instead describe it as "12 months of ruthlessness". Start a project at the beginning of the month. Has it gotten anywhere by the end of the month? Do you have a result (and that can be an open sourced module as much as it can be a user-facing product)? If not, shut it down, start something fresh on month 2. But if you do have a result at the end of the month, keep at it.
I agree, I would prefer a milestone challenge where people put up demos/videos/blogs of their progress (same project or not). Maybe my first month's project is creating a site for people to share their progress towards whatever their goal is. If you think that is a good idea, vote me up :)
>I think this is the thing. It's a slightly weird set of incentives for you to create a new project every month, irrespective of whether last month's worked out or not.
It's not always necessary to spell out everything.
If one's 3rd month product proves widely succesful and shows great potential, they can always decide by themselves to continue on it and not go on to their 4th and next months' products.
They don't need that spelt out in the challenge rules... And if someone is so dense that they do, there are slim chances that they'd be creating any great product anyway...
Well, sure, but if you're doing the "The 1 side project per month challenge" and the "1 side project per month" part is optional, what are you actually doing?
Obviously the "1 side project per month" part is not optional, it's conditional, which is something different.
The "1 side project per month" challenge being conditional on not having too much success with one of the monthly projects (thus prompting you to stop and focus on that) is not that different on it being conditional on numerous other things:
1) In that you continue to want to do the challenge (e.g. it's perfectly legitimate to decide it's BS and give up after a few months).
2) In that you have the time to do it (e.g. you might suddenly have to stop because you have too much on your plate from your day job a few months in).
3) In that you are able to do it (e.g. you might have to stop if you have a health issue).
And tons of other things besides.
So the question makes no more sense than asking "if you decide to run at your local marathon, and you stop after 12 miles because you got tired, or because there's an emergency at your home, or because you strained your ankle, or because you just felt like it, then what are you actually doing"?
The answer is obvious: you are doing the challenge for AS LONG AS YOU PLEASE.
This is the pretty close to hitting the nail on the head. In order to actually complete something, you have to learn to scope a project to be complete-able. This means you have to actually focus on your mvp and ship that and not let yourself get pulled into feature creep.
The headline should be "The One Project Per Month Challenge." For me, the term "Side-Project" implies that the goal is to generate revenue, which is not the goal of this challenge.
I realize that this is becoming horribly pedantic, but the term "side project" is used a lot [1][2] to mean: "Someone who works full time but also builds a product on the side in the hopes that it will one day generate enough revenue that they can quit their day job."
In the context of this thread (a complaint about negative comments) I thought I'd point out that the title had been changed from the original [3], and that the change could perhaps, for some people, cause them to think that this was about trying to generate income outside of their day job, when in fact it was about just doing some small projects on a timeline.
The problem isn't the idea of doing one thing per month. It's the implementation in my mind. I don't like when people just wander around programming aimlessly. I also don't like when we drop standards to meet deadlines (I've got a looooong history of doing this and I hate it, check my github). I think completeness, reliableness, and also practicality should be king.
You shouldn't be focused on pumping out something 24/7 you should be thinking of how to make the best product that you can possibly make.
These One Game a Month games are.... "creativly different". Now granted I couldn't do a game a month and I don't think I'll be able to finish my game even in my lifetime but I wouldn't feel right lowering the quality of the game I'd like to make to fit it into a month.
One Game a Month projects aren't about producing quality games, so much as learning to complete something within a deadline. If you can finish even a simple game in a month, then you know you can finish a more complex, longer term project. Finishing games is a skill in and of itself, and one most new game developers may not realize they need to develop.
Far from being aimless programming, it's meant to teach you to judge the value of your own initial concepts and estimate the time and effort it would take to pull them off, and to prioritize practical work over bikeshedding and unnecessary iteration. Having the arbitrary deadline is what helps you focus on the end goal - projects with open ended or nonexistent deadlines tend never to be finished.
I upvoted you because you pinpoint a real problem and I understand why you're afraid of it. Still I don't agree that this problem should necessarily thwart the 1PPM Challege.
A monthly project could be as small as a library you'd have to do for your real job, or a polished generalization of it (chec U. Check the first entry of the hall of fame: https://github.com/ggerhard/parsecal/blob/master/parsecal.rb is a 120 lines Ruby script. It reads and parses "data from a google calendar (or other iCal calendars) and create an Excel Timesheet." It could be the core of a web service but it doesn't have to be a web service when it's posted in 1PPM.
I do those often too but I do them because I need a library that does X or a service that does Y. Just building this doesn't make sense. Building things for some end goal makes sense.
>You shouldn't be focused on pumping out something 24/7 you should be thinking of how to make the best product that you can possibly make.
This is a false dichotomy. "Timely delivery" is also an essential feature of any product.
Or, as they say, the better is the enemy of the good.
While you're "thinking of how to make the best product that you can possibly make" others can just go ahead and make something. And that something, even if it's not the best product that one could possibly make, at least it would exist, then and there, and so would be million times more useful than any project that's still designed in someone's mind.
If we don't count the time needed to master their skills (which we don't for software development either), artists have often created profitable works in a couple of weeks or less.
Songs that were conceived and recorded in a few days have become big profitable hits (e.g. "Doctoring the Tardis"). And of course a napkin sketch from someone like Picasso can easily fetch like $1000 or $5000.
Define a 'game'. You could get the basics of any 8-bit game done in a weekend. Heck even faster than that once you learn a game library or save enough code from previous projects.
My definition of a game is an interactive story or experiance that is provided through information provided directly and indirectly to the player. However this is acomplished is acceptable but the only measure for it's success is if people enjoy it, just like any other art.
Isn't learning maintenance, support, refactoring, testing, etc., also valuable (especially for beginners)? I think it's in the first page of Site Reliability Engineering that the majority of time and costs are present here, which might suggest it is a more valuable job skill.
As a beginner I saw posts like this and felt like this was the way to go to learn as quickly and efficiently as possible. In retrospect I wish I had stuck with a single project, such as a comprehensive Django application, gotten a job in that domain to extend my skills, and then built from there.
This is very much like One Game a Month (http://www.onegameamonth.com/). The idea is that write, learn, ship. It's nice.
If you find that one of your projects takes off, or you really like it, then continue to work on it.
Edit: grammar