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.
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.
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.
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.
I remember quality vs. quantity story of ceramics class. [0]
> The ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality. His procedure was simple: on the final day of class he would bring in his bathroom scales and weigh the work of the "quantity" group: fifty pound of pots rated an "A", forty pounds a "B", and so on. Those being graded on "quality", however, needed to produce only one pot - albeit a perfect one - to get an "A".
Well, came grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity. It seems that while the "quantity" group was busily churning out piles of work - and learning from their mistakes - the "quality" group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay.
I love this story and I want it to be true. I've tried to trace it in the past but seems every source tells a story without any details. So not sure if this is a parable or actually happen. I believe that practice/iteration is the way to improve, it just seems a little too black and white
In a similar vein on producing quantity of work before trying to be perfect, I always refer to Ira Glass's video The Gap. Must watch if you haven't seen
I made a resolution like this a couple years back because I had never completed any nontrivial software projects.
For me, it worked better to start with much smaller projects and scale upwards. I started trying to do a project a day. Initially the scope would always be too large to complete in a day, but with this quick feedback loop I learned to narrow scope. Then I proceeded to week-long, month-long, and one multi-month project.
It's a good method if a one month side project seems intimidatingly large to you — which was how I felt before this exercise, but no longer felt this way afterwards.
I couldn't do this. My big thing is i always want to be working on personal projects that solve problems in my life. If that ends up with cool stuff, great! But i've been burnt out too many times on making things for other people.
It's one thing if i set out to make a passive income, but that's work in my opinion. My side projects are open source commitments of mine, and assuming the "thing" works well and solves my problem, i'm contributing to it for years to come. Or at least until the problem is solved in another way.
If i'm really lucky, side project can become passive income (ie, providing hosted versions, etc), but that has yet to happen, and i'm fine with that. I'm solving my own problems, which i find quite enjoyable!
I like this idea, I've got a handful of side project ideas that I always go back and forth on having/losing steam on and I end up never finishing them.
I also go back and forth on whether my side project should be open sourced or not. Why did you decide to open source all of your personal projects? What if it became something great that you later find out could be sold for extra income, would you regret open-sourcing?
I think this definitely an interesting idea, I have at least 1 new idea a month but usually just talk to close friends about them and move on with life.
I agree that expecting to create 12 great projects next year is a stretch and odds are that 12/12 will become vaporware, however, the lessons learned and the potential (albeit small) for any one of them to actually become something makes this a worthwhile endeavor to me.
Actually reminds me of something I read from Antifragile[1]:
> Rule 4: Trial and error beats academic knowledge.
> Things that are antifragile love randomness and uncertainty, which also means—crucially—that they can learn from errors. Tinkering by trial and error has traditionally played a larger role than directed science in Western invention and innovation... [2]
Say what you will about NNT's writing style, but the guy makes a lot of sense to me.
Seems to be some people that think you can't do something in 1 months time. First of all I think the biggest thing you'll learn is how to CUT features out of something that you're building. Since you have 1 month, you really need to think about what problem you're trying to solve and cut out all the fluff that isn't necessary.
The second biggest thing you'll probably learn is HOW TO ship! A lot of people work on 'side projects' but no one ever really ships them. It's the hardest thing to do honestly. It helps you get over any insecurities you'll have building something. Especially when you release it to the world.
Building and launching is more than just building a product. It's a learning experience.
Code is useless if it is for nothing. Don't write code just to write code, write code to solve a problem you are having. If you're having 1 problem per month, then write 1 project per month. If you encounter 50 problems in one month write 50 projects in 1 month. If you encounter 0 problems in one month, write 0 projects that month.
This is right when you're already at a certain level of competence. I would be pretty disappointed to hear John Carmack was taking on this challenge, but it's a good one for people who need to just put some pencil to paper to get the practice.
> Don't write code just to write code, write code to solve a problem you are having.
What if the problem I'm having is that I don't know Haskell?
It's totally fine to code exercises that don't serve any useful purpose. Just like it's fine for me to make terrible songs on the guitar that nobody would ever want to hear.
I tried this about 2 years ago (or 3?) and man, it's a hard pace to keep up. I think I ended up with 4 projects out of the bunch before I needed a burnout break. One of the projects ended up supplying a bunch of mostly-passive income, so that was great.
One month projects sound great but with my busy schedule that would be only about 8-16 hours of butt in seat time, which isn't enough for a substantial project. I can think of some "toy" projects in that timeframe, though. And some peripheral utility projects that might be useful in the future.
I've been at my "main" side project for more than 5 years with no end in sight.
I wish I didn't have to have a day job. I'd have no issues keeping myself busy, but I'm a terrible businessman and I doubt I'd make any money.
That's what it's all about: to get something done and learn new things instead of (or in addition to) those long running, never finished side projects. I have a long running project too, 1PPM are my side-side projects.
The most important outcome for me when I did this (for 6 months) was my own webapp generating infrastructure, modules for common things with a whole lot of scripting to integrate 50-80% of all features (payments, chat, onboarding flows, landing page templates, dashboard templates, checkout flows, profile creation, etc.) depending on the app. Of course, building this infrastructure took about 4,5 months to put together and is an ongoing project, but was only possible after building 7 webapps in a row. I'm confident I could get a serious looking prototype for pretty much any webapp idea in less than a month, and depending on the app maybe less than a week.
(As an aside, if you're going to do this, you should also get Sketch and learn how to do graphics.)
I built all my infrastructure, modules, and scripts on top of Rails, and I may be biased, but I do credit my success with this to the ease, simplicity, and maturity of Rails. Popularity debates aside, is there any better framework for rapid prototyping than Rails?
Well if you're a Python person, Django is amazing, and if you're a golang person Gin Gonic is amazing. Not everything webapp is Rails, although Rails is wonderful for prototypes. The only two very large rails sites I was ever consciously aware of were Twitter (now all java) and Groupon (now mostly node).
I don't like this. Seems like encouraging a lot of bad starter projects that are never useful. It would be better to do code challenges/exercises for practice and learning. Like write a hashmap one month, write a linked-list (in C then in Rust) another.
If we want something useful, how about, contribute to a new open-source project every month. That challenge may end up with some major benefits to the community. It will also teach you how to work wth others, etc.
I added to the 1PPM README file, that a contribution to an open source project is a perfectly valid and highly encouraged project. Thanks for your remark.
The comments here are borderline nonsense. I kept up a pace of releasing a working web widget (didn't charge for them, but all meant to be useful) every four days for months. Last year I released at least three dozen without burning out and honestly probably would have been happier releasing more.
One for-pay product a month would be pretty reasonable, as long as you set expectations well. Sound hard? "Costs $3" sets the expectations correctly.
The amount of scaling back on ambition here is bizarre. This isn't shooting for the moon.
Now, marketing, that's something that takes time. I have no words of wisdom there.
I like the idea. Sounds a good approach to get good at doing things fast. You could even significantly improve the quality of your work.
Anyone remembers the pottery class experiment ? They partition the group in two. One partition would be graded on the number of pottery pieces. The other partition was graded on the quality of the best piece. The result was that the first partition no only got more pieces. They also made better pieces. They just practiced more.
I've been publishing around 1 library (some small and some medium for 1 person) every other week. However, most of them are related around building front-ends using ES6[0][1] or building websites with Node.js[2][3]. I am also doing some experimentation with robotics/AI (voice/image recognition) but those are just side projects like [4], not publishing anything.
Excuse my ignorance, but aren't we glorifying speed here at HN? I think one project per month is way too fast to acheive anything of substance. If you're spending one hour three days a week, you'll only have 12 hours to finish a project. Even if you quadruple that, 40h isn't all that much for completing anything interesting at all. I have spent more than a year off and on on my latest side project, and it's not finished yet.
Having felt the pressure in the coding community myself, I've spend significant time improving my speed and I now find myself being on of the fastest coders in my company. Sure, that buys you a certain type of edge. But even if you're fast, a lot of time goes to thinking about problems, reading research and such. And someone who's constantly panicking trying to write as much code as possible will most likely find themselves digging a whole for themselves.
i think the idea is to put a ship date or it won't get done. A month is arbitrary of course, but long enough to make 'something' in part time, but not long enough where you can slack and eventually abandon it. it's a mind hack to keep you on "schedule" with a end goal in sight.
I think instead of thinking about 1 hour three days a week, think about spending most of your weekends on the projects. You can get a lot done in 2 weekends.
It is a fast pace but I think the idea is to not set yourself up for huge projects that don't get done; work towards small projects that you can complete in a month.
> Excuse my ignorance, but aren't we glorifying speed here at HN? I think one project per month is way too fast to acheive anything of substance.
I think it's not about achieving anything of substance, it's about learning to code. Coding your own project from scratch is very hard and then effective for learning.
Slightly OT: are you actually able to do anything meaningful in a single hour? It usually takes a lot more for me to dig in into the topic, at least if there is multi-day pause between the sessions.
The valuable part of this article is to limit a startup idea to one month of initial effort. And don't continue the effort unless after a month you can gain some sort of useful validation that there is a market for your idea.
This also means that you will have to stick to the basic core of your idea and skip lots of details, in order to have something that can be shown after a month.
I've seen too many startup ideas that people started working on that weren't necessarily bad ideas, but their plan was to make an MVP, the scope of which would take a team of engineers at least a year to deliver.
I might give it a try, but on a slightly less intensive schedule--maybe one project every two months. It doesn't sound as catchy, but a bit more realistic. Best of luck with this initiative.
I didn't see anything in the premise requiring anybody to actually stick to the timeline. I doubt he/she is going to delink from someone for something like that.
[+] [-] davidwparker|9 years ago|reply
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
[+] [-] untog|9 years ago|reply
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.
[+] [-] wheelerwj|9 years ago|reply
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.
[+] [-] jt2190|9 years ago|reply
(Edit: phrasing)
[+] [-] gravypod|9 years ago|reply
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.
[+] [-] ben_jones|9 years ago|reply
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.
[+] [-] taneq|9 years ago|reply
It makes me think of the classic Glengarry Glen Ross scene. "If you want to work here, CLOSE!"
[+] [-] karimf|9 years ago|reply
> The ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality. His procedure was simple: on the final day of class he would bring in his bathroom scales and weigh the work of the "quantity" group: fifty pound of pots rated an "A", forty pounds a "B", and so on. Those being graded on "quality", however, needed to produce only one pot - albeit a perfect one - to get an "A".
Well, came grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity. It seems that while the "quantity" group was busily churning out piles of work - and learning from their mistakes - the "quality" group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay.
[0] https://blog.codinghorror.com/quantity-always-trumps-quality...
[+] [-] SonicSoul|9 years ago|reply
In a similar vein on producing quantity of work before trying to be perfect, I always refer to Ira Glass's video The Gap. Must watch if you haven't seen
https://vimeo.com/85040589
[+] [-] superquest|9 years ago|reply
For me, it worked better to start with much smaller projects and scale upwards. I started trying to do a project a day. Initially the scope would always be too large to complete in a day, but with this quick feedback loop I learned to narrow scope. Then I proceeded to week-long, month-long, and one multi-month project.
It's a good method if a one month side project seems intimidatingly large to you — which was how I felt before this exercise, but no longer felt this way afterwards.
[+] [-] notheguyouthink|9 years ago|reply
It's one thing if i set out to make a passive income, but that's work in my opinion. My side projects are open source commitments of mine, and assuming the "thing" works well and solves my problem, i'm contributing to it for years to come. Or at least until the problem is solved in another way.
If i'm really lucky, side project can become passive income (ie, providing hosted versions, etc), but that has yet to happen, and i'm fine with that. I'm solving my own problems, which i find quite enjoyable!
(not trying to be negative, just my take on it)
[+] [-] morbidhawk|9 years ago|reply
I also go back and forth on whether my side project should be open sourced or not. Why did you decide to open source all of your personal projects? What if it became something great that you later find out could be sold for extra income, would you regret open-sourcing?
[+] [-] gooseus|9 years ago|reply
I agree that expecting to create 12 great projects next year is a stretch and odds are that 12/12 will become vaporware, however, the lessons learned and the potential (albeit small) for any one of them to actually become something makes this a worthwhile endeavor to me.
Actually reminds me of something I read from Antifragile[1]:
> Rule 4: Trial and error beats academic knowledge.
> Things that are antifragile love randomness and uncertainty, which also means—crucially—that they can learn from errors. Tinkering by trial and error has traditionally played a larger role than directed science in Western invention and innovation... [2]
Say what you will about NNT's writing style, but the guy makes a lot of sense to me.
[1] https://www.amazon.com/Antifragile-Things-That-Disorder-Ince...
[2] http://www.wsj.com/articles/SB100014241278873247351045781209...
[+] [-] navd|9 years ago|reply
The second biggest thing you'll probably learn is HOW TO ship! A lot of people work on 'side projects' but no one ever really ships them. It's the hardest thing to do honestly. It helps you get over any insecurities you'll have building something. Especially when you release it to the world.
Building and launching is more than just building a product. It's a learning experience.
[+] [-] gravypod|9 years ago|reply
[+] [-] kolbe|9 years ago|reply
[+] [-] ebbv|9 years ago|reply
What if the problem I'm having is that I don't know Haskell?
It's totally fine to code exercises that don't serve any useful purpose. Just like it's fine for me to make terrible songs on the guitar that nobody would ever want to hear.
[+] [-] sjs382|9 years ago|reply
[+] [-] ianai|9 years ago|reply
[+] [-] exDM69|9 years ago|reply
I've been at my "main" side project for more than 5 years with no end in sight.
I wish I didn't have to have a day job. I'd have no issues keeping myself busy, but I'm a terrible businessman and I doubt I'd make any money.
[+] [-] ggoerlich|9 years ago|reply
[+] [-] ianai|9 years ago|reply
[+] [-] orthoganol|9 years ago|reply
(As an aside, if you're going to do this, you should also get Sketch and learn how to do graphics.)
I built all my infrastructure, modules, and scripts on top of Rails, and I may be biased, but I do credit my success with this to the ease, simplicity, and maturity of Rails. Popularity debates aside, is there any better framework for rapid prototyping than Rails?
[+] [-] SEJeff|9 years ago|reply
[+] [-] bluejekyll|9 years ago|reply
If we want something useful, how about, contribute to a new open-source project every month. That challenge may end up with some major benefits to the community. It will also teach you how to work wth others, etc.
[+] [-] ggoerlich|9 years ago|reply
[+] [-] hawkice|9 years ago|reply
One for-pay product a month would be pretty reasonable, as long as you set expectations well. Sound hard? "Costs $3" sets the expectations correctly.
The amount of scaling back on ambition here is bizarre. This isn't shooting for the moon.
Now, marketing, that's something that takes time. I have no words of wisdom there.
[+] [-] huherto|9 years ago|reply
Anyone remembers the pottery class experiment ? They partition the group in two. One partition would be graded on the number of pottery pieces. The other partition was graded on the quality of the best piece. The result was that the first partition no only got more pieces. They also made better pieces. They just practiced more.
[+] [-] franciscop|9 years ago|reply
[0] http://superdom.site/
[1] https://github.com/franciscop/uwork
[2] https://github.com/franciscop/loadware
[3] http://github.com/franciscop/server
[4] http://anchor.science/
PS, I think all of those (and some more) were done within the last 2-3 months.
[+] [-] strictfp|9 years ago|reply
Having felt the pressure in the coding community myself, I've spend significant time improving my speed and I now find myself being on of the fastest coders in my company. Sure, that buys you a certain type of edge. But even if you're fast, a lot of time goes to thinking about problems, reading research and such. And someone who's constantly panicking trying to write as much code as possible will most likely find themselves digging a whole for themselves.
[+] [-] SonicSoul|9 years ago|reply
[+] [-] ebbv|9 years ago|reply
It is a fast pace but I think the idea is to not set yourself up for huge projects that don't get done; work towards small projects that you can complete in a month.
[+] [-] joshux|9 years ago|reply
[+] [-] highCs|9 years ago|reply
I think it's not about achieving anything of substance, it's about learning to code. Coding your own project from scratch is very hard and then effective for learning.
[+] [-] tener|9 years ago|reply
[+] [-] halis|9 years ago|reply
This also means that you will have to stick to the basic core of your idea and skip lots of details, in order to have something that can be shown after a month.
I've seen too many startup ideas that people started working on that weren't necessarily bad ideas, but their plan was to make an MVP, the scope of which would take a team of engineers at least a year to deliver.
[+] [-] neovive|9 years ago|reply
[+] [-] ianai|9 years ago|reply
[+] [-] xchip|9 years ago|reply
- A physics engine: https://github.com/aguaviva/Physics
- A Neural network: https://github.com/aguaviva/ArtificialIntelligence
The point was to learn the basics by implementing everything from scratch, I also wrote a tutorial to make sure I understood the theory.
[+] [-] eb0la|9 years ago|reply
[+] [-] krapp|9 years ago|reply
[+] [-] ggoerlich|9 years ago|reply
[+] [-] sigvef|9 years ago|reply