Hacker News new | past | comments | ask | show | jobs | submit login
A one-side-project-per-month challenge (github.com/1ppm)
227 points by ggoerlich on Dec 30, 2016 | hide | past | favorite | 119 comments

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.

Edit: grammar

> 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 have a nearly five old idea that is very similar. Eventually someone will build it (well) and it'll become very beneficial!

If you would like to work with somebody on it; hit me up. Or if you have some ideas you'd like implemented, let me know.

>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.

You are losing the challenge. And not caring the least.

> Instead, you'll learn to actually finish

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.

(Edit: phrasing)

Ironically I think the meanings are the exact opposite! "Project" means billable to me, while side-project means "hobby" or practice.

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.

[1] https://training.kalzumeus.com/newsletters/archive/do-not-en...

[2] https://blog.asmartbear.com/working-startup.html

[3] HN doesn't generally allow for changes to the title. Why it was allowed in this case is unclear to me.

It might mean for you, but some people just enjoy creating stuff for fun with no intention to make money.

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.

When the product is contracted work*.

When the work is for yourself, you set the due date. Setting the due date at 1 month is bound to yield unsavory results.

>When the work is for yourself, you set the due date. Setting the due date at 1 month is bound to yield unsavory results.

People have created profitable side projects in a couple of weeks or even less.

In software development? Defintely. In art? No.

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.

Deadlines are set for art all the time, and some of the greatest works were commissioned on a deadline.

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.

Man I'm glad you're not making business decisions for my company...

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.

As the old Apple folklore page says, "Real artists ship."

It makes me think of the classic Glengarry Glen Ross scene. "If you want to work here, CLOSE!"

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.

[0] https://blog.codinghorror.com/quantity-always-trumps-quality...

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


Makes you want to become a ceramics instructor just so you can have a primary source.


I'd listen to Ira more if he didn't sound so annoying.

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!

(not trying to be negative, just my take on it)

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?

> 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 that's a decision to be based off of what it is. If that's a concern, and if open source has limited inherent value to you or the project, perhaps it shouldn't be.

For me, i highly doubt my currently projects will make any money. Primarily home automation, and home cloud-lite stuff, Storage, etc. Nothing ground breaking, and where it might be "ground breaking" (though it's not), i specifically strive to not have it be ground breaking - a pillar of my work lately has been simplicity, ease of use and ease of maintenance - being side projects and all, i don't want anything i write to confuse me in two years.

So yea, i have no concerns about it being open source - and so i default to OSS. If it gains any adoption, i get contributors, testers, UX requesters, etc, all things i want. So OSS is purely a boon for me, in these cases.

edit: Plus, i like being able to add a trail of work on my resume/site/etc that i'm proud of. For few side projects that i have left closed source, i split off as much code as i could making them into OSS libraries and such. Even if the core of it can't be OSS, some of it can i'm sure :)

I had to recheck that this wasn't written by me N months prior, it's exactly the same motivation and benefits I've found.

Only thing is I make Javascript things instead of home automation.

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.

[1] https://www.amazon.com/Antifragile-Things-That-Disorder-Ince...

[2] http://www.wsj.com/articles/SB100014241278873247351045781209...

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.

There's a big difference between learning how to program and starting a library/project every month. If you want to learn how to build something, which is what programming is, there is a straitforward way of learning how to do so.

Phase 1 is where you learn what programs look like. Pick any language. Learn all of the syntax and and meanings behind everything. Get to the point where you can start a project and write some code down and get a simple solution to a 1-step problem.

Phase 2 is when you pick a long term goal. Something you want to build. Maybe a game, maybe a website, maybe automate some portion of your life. After that, you write out all of the things that go into making that happen. An itemized list of absolutly every feature you want to include. Then you go to phase III

Phase 3 you break every goal into sub-goals, and those sub-goals into further subgoals so you have a tree. Stop breaking into sub-gaols when your goals are something like "Read config from file", "Grab user from database", "Render N many objects sequentially to the screen", "Wait to hear from clients wanting to connect".

Phase 4 is when you read up on how everyone else is doing all of the things you want to do. Make a huge list of mappings from sub-goals to stack overflow links on the topics.

Phase 5 every day, pick one of your sub-goals and implement a little prototype doing that sub-portion of your code.

Phase 6 reduce your tree. Go through every sub-goal and merge it into it's partent subgoal's prototype. If you get to the point where the code is messy and hard to follow abstract, optimize, and clean your solution as needed. Do not proceed to the next sub-goal until you are completely happy with how your current sub-goal looks.

Phase 7 test, test, refine, refine, clean, clean.

Doing this may take a year to get 1 project done but it will be the cleanest, most organized, and probably gest example of how you can write code. I think this one project would be worth more then 100 other projects where you "do it live".

That's certainly a good way to learn, though it's by no means the one and only best way. I personally think the best way is to go to MIT and do an EECS major. But we all have our different ways of approaching education, and I respect yours as much as I respect a person who learns based on building simple applications the can relate to and engage with better because they're more interesting.

No college education will teach you the material if you don't actually care. Many people hear "go take a CE degree' or "CS degree" and think "Now I'm a programmer" when they get out. They feel they know everything they need and as soon as they hit the real world reality drops on them like a sack of bricks.

I'm at a "decent" university and currently in my 3xx level classes people don't know how to "do coding" and I'm constantly having to help people learn some material that, had they taken the time to program on their own, they'd know. There is value to a degree but it's not in knowing how to do your skill. The value comes from 1) having a degree, 2) knowing people who have degrees, 3) being able to talk the lingo to people who respect degrees.

Now granted, 6.001 is great and I love SICP but I don't know if you can show me data of people who know absolutly nothing about computers/electronics going into those courses and being able to "do electronics" or "do computers" after getting out. I'd wager that the data will show there's a higher corilation of people who come in knowing something about computers or electronics from their own experiance who are able to get more out of the classes.

Sadly I don't think universites publish this data (would probably be bad press for them).

I'd love to be proven wrong though. It would remove another large chunk of my cynical world view.

One could dismiss your 7-phase plan with a similar argument.

I doubt it given all the IT people, including HN readers, saying the college grads usually cant program worth anything. Whereas, the people who learned a creative, building skill by building straightforward or creative solutions to various problems often program better. Surprise!

The vast trove of empical data out there on activities like programming suggest that practice is main way people get better. There's also a sizeable anount of evidence saying ideal practice is a series of problems that increase in difficulty, a bit harder than before, and not insurmountable. Plus, learning techniques & observing examples from experienced professionals.

College isn't likely to teach you much programming skill at all. Now, programming practice + a college education in CompSci concepts can make for a programmer with more tools in the toolbox (taps head). It's not a substitute for repeated, informed practice of act itself.

Uh..... I don't disagree with you, but you're responding to something I didn't even say....

You actually didn't say anything. You implied 7 arguments existed that would dismiss the comment. Your comment itself was a dismissal with no content. So, I instead argued against it by using the status quo of evidence on going to college vs practicing a skill for building a hands-on skill.

This is just..... wow. It's like you're talking to a wall.

I think I'm done contributing to this site. Thank you for showing me the light.

Couldn't have said it better myself.

> 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.

My take with the analogy here is that you're still playing the guitar to make songs (an end product), instead of just learning how to pluck strings for the sake of plucking strings and testing how different strings of different materials feel for the heck of it.

But that latter thing is still something guitarists do. You might throw some new strings on and noodle around for a day with no particular purpose in mind.

Likewise it's fine to write code with no bigger goal other than to play with a library or a language.

There is a different between prototype and project. If you're experimenting with features you're not making a project. If you're making a project (I hope) you're not experimenting with features. That should be done in a prototype.

There's overlap. Most FOSS or personal projects are prototypes for something built for fun or learning. Something can be a project without it needing success, money, or quality.

I believe Fred Brooks got famous pointing that out although it was unintentional for who he wrote about. ;)

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.

What kind of project was it that paid out?

The first of the bunch: https://SendToMyCloud.com

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.

Sounds like a good idea.

What worries me a bit in this idea is that it takes a surprising amount of time to polish a project so that it is "done". Or at least left in a state where it is easy to pick up later, by yourself or someone else.

I have tons of projects where the "beef" is mostly done but README, example code, tests, etc are lacking.

Starting a project takes surprisingly long too. Setting up a build system, test framework, CI builds etc always take much longer than I anticipate.

Keep these pitfalls in mind. Best of luck to you.

One or two side projects is enough for me. Side side projects is taking it too far imo: there are other things I'd rather spend my time doing.

Can you serialize your long term project into 12 smaller ones?

Yes, otherwise it would be overwhelming. I try to make bite sized subprojects so I can walk away and the project is in a shape that is easy to pick up later.

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).

Kickstarter, AirBnB, Github, Scribd, Bleacher Report, Hulu, Codeacademy, the 100+ startups that message me for interviewers every year, etc.

I was only making claims for rapid prototyping. I still contend for prototyping there is no better framework than Rails. From the start DHH designed Rails specifically for prototyping of web apps, and your custom prototyping infrastructure will sit very nicely on top.

No better Ruby framework than Rails. We both agree there!

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.

[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.

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.

Ken Thompson wrote Unix in a month.

Allegedly, it took him a month - https://www.princeton.edu/~hos/Mahoney/expotape.htm. But the idea had probably been growing on him for several years, while working on very similar projects.

I think this actually supports my idea of letting ideas grow on you before executing them.

Further it's a tiny subset of MULTIC project that he worked on for some time. Some of MULTIC design ended up in UNIX. One can argue UNIX's design began as far back as that where he was doing something else but pivoted in new project with weaker hardware.

Wasn't that all he was doing? Also, could be mistaken, but pretty sure he was Ken Thompson.

> 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.

Well, sort of. I have established a habit of thinking about my problem during workdays and planning actions for my commute. During the commute I execute one or two planned actions.

This works really well for me, since I easily get overwhelmed if I just sit down without an action plan.

But occasionally I use longer sessions to cleanup, refactor and review my code and assess the current state of the project.

Sone days I just read up on some subject instead of coding. But there is always a risk in getting bogged down by resesearch until the point where you can think of 20 possible solutions. I then sit down and code a bit to help me decide which method would work best for my concrete case. You can always come back and reevaluate a decision if you discover problems further ahead...

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.

Just added two projects:

- 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.

I had the same idea: starting one project per month for 2017. I guess 2016 is too now short to achieve something relevant ;-)

Still haven't finished my Game a Month project for January 2016...

I did 3 months in 2014 (I think?) then got stuck. It wasn't so much finding the time that was the issue for me, but deciding on a game I'd like to build. Although that's pretty much the story of my side projects, I spend more time procastinating over what to build rather than building it.

I keep getting distracted by turning parts of my side projects into their own side projects.

The game I was working on (basic Berzerk clone) was simple enough, but once I decided I needed to use Lua (why? I don't know, I just did) and rewrite the ECS (it's still terrible) and have a vector-based camera for 2D scrolling, which Berzerk never even had (and rewrite the vector class, of course, even though it already worked) and I spent a week writing a state machine for basic enemy AI, implementing it, wondering if an ad-hoc possibly Turing complete pseudolanguage implemented in std::vector was really the correct solution, hating it even though it worked despite being an affront to programming, and deleting it, along with all of the game states that used it, and starting over from scratch, I realized I wasn't actually making a game anymore, so I gave up.

And by "gave up" I mean I'm working on the nth complete rewrite right now. The ironic thing is, it could have been done by the deadline - most of the gameplay was already there, if I'd just focused on the forest and not the trees.

But in my defense, the camera is pretty darn smooth, and I seem to have gotten a lot of useful code out of the effort, but not an actual game yet.

1GAM challengers are very welcome! Just add your games to the Hall-of-Fame list!

Awesome. I'll be sure to do that in 2026 when it's actually done.

Feel free to join me! I wrote a little article on how to come up with project ideas. You could start right away: https://medium.com/@gerji/12-months-12-side-projects-are-you...

We do something similar at work. Here's two of the monthly side projects we've come up with this fall: https://www.zombocam.com https://www.musicvideodispenser.com

I really love to see that. I believe great programmers are the one who've started countless projects from scratch on their own (of course my opinion is oversimplified here). This, 1PPM, is really what you're looking for if you want to become a great programmer. Nothing else, just that. So go for it.

I...don't know about that. I've worked with several programmers who were great at getting something up and running, but we're kind of crap at going deeper--adding depth, maintaining. I'd go as far as to say they typically had an attitude of "I got it up and running, mission accomplished!" Maybe they need to get closer to that 1000 mark to learn the value of planning for the long term, making something you can continue to build on, etc.

Hmm… I like the idea. I think I might take it up, focusing on finishing things I’ve already started but never published, with either prototype implementations or something for which I’ve made at least some progress. I’ll get through half the year on those alone!

My "side project" (or actually just one of them) has taken +10 years and thousands of hours.

So I just wonder that what kind of things that produce value can you expect to create in 1 month (assuming you're putting like few hours every day) ?

MySpace went from idea to launch in 10 days per the Wikipedia article:


This project a month scheme is a crap shoot that will produce little of value in terms of tech released itself. A few valuables among a bunch of misses. Yet, decent ideas can be prototyped in a month or less with enough feedback to determibe if they're worth further action.

Did this 2 years ago, radically changed my life: https://levels.io/12-startups-12-months/

I was about to give up and get a day job.

Found your post-project debriefings very interesting to read, thanks for documenting your experience so thoroughly.

If you don't mind, I do have a question: what did you do in terms of the legal side? I.e. did you start a new company for each month, do each within an existing corporate umbrella, or just not worry about that until you needed to? Or maybe something else entirely?

Personally I'd be happy with one project a year or even a decade really ;-)

Do you have 3 lives? You can't afford that if you want to build stuff. We actually have 15 years (on average) of useful life from 20 to 70 if you're lucky.

I really like this idea. There is a terrible tendency to over engineer the things we make as developers. The practice of finishing and shipping as actually much easier said than done.

I'm in!

I was thinking about doing something similar this year. I settled on one project per quarter, which would let me take on things slightly more ambitious. But in a way, I like the extreme constraints set by one project per month, which will likely force someone to approach projects completely differently than they're used to.

Funny, I started the ggraph project (https://news.ycombinator.com/item?id=13283961) pretty much exactly one month ago.

I just launched www.fibretiger.co.za an online fibre comparison site in South Africa, we got over 8 fibre networks and more than 20 fibre isps.

I'm just going to place this here:


I just began https://pingtiger.com

How do I submit ideas for other people?

My guess is fork and do a pull request? Or create an issue beforehand to ask if it's ok to do that.

We are building a MVP in 3 days. Long weekend! Its doable yo! Simple AS potatoes! Look MA no POLISH. ;-)

> 12 Months / 12 Side Projects - Are you in?

Nope, busy 7.5 years into one side project; thanks for asking.

Good software, like wine, takes time.

The main idea I think is not to build quality software, but to actually get shit done. You can refactorize later if you feel like the project has future.

> I'm surprised by all the negative reactions.

Welcome to Hacker News, where everything gets shit on!

Please don't diss this community while participating in it.

Your comment actually does the thing it is criticizing. That's indicative of how complex the problem you refer to is.

We detached this comment from https://news.ycombinator.com/item?id=13284556 and marked it off-topic.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact