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
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.
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...
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.
(Edit: phrasing)
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.
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.
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.
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.
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.
It makes me think of the classic Glengarry Glen Ross scene. "If you want to work here, CLOSE!"
> 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...
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
P.S.
I'd listen to Ira more if he didn't sound so annoying.
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.
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 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 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 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...
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.
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".
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'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.
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.
(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?
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.
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.
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.
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.
[1] https://github.com/franciscop/uwork
[2] https://github.com/franciscop/loadware
[3] http://github.com/franciscop/server
PS, I think all of those (and some more) were done within the last 2-3 months.
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.
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.
I think this actually supports my idea of letting ideas grow on you before executing them.
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.
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...
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.
- 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.
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) ?
https://en.m.wikipedia.org/wiki/Myspace
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.
I was about to give up and get a day job.
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?
I'm in!
This is more fun: https://levels.io/12-startups-12-months/
Nope, busy 7.5 years into one side project; thanks for asking.
Welcome to Hacker News, where everything gets shit on!
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.
