params.json

{"name":"12days.github.io","tagline":"A 12-day experiment in building and shipping code","body":"### What is 12 days of coding?\r\n\r\nIt is 12 projects in 12 days. Each project would be started, finished, and shipped in a given October day.\r\n\r\nIt is an experiment in coding and learning.  It is an experiment in teaming and creating a culture of doing.\r\n\r\n### Why 12 days of coding?\r\n\r\n[Josh](https://github.com/JoshuaJWilborn) and I both had time to kill.  But, not too much.  We wanted to do something fun, build up our coding skills, and our portfolios.  \r\n\r\nAnd we wanted to learn: learn to be better coders, learn to be better builders, learn more about our interests. And that was it. We didn't want to get ahead of ourselves.\r\n\r\nWe thought a good way to do this would be to create a set of constraints around our efforts. Constraints are key to discipline and focus.\r\n\r\n* One of the first choices we made was to keep it short and simple (KISS principle). \r\n* We are devoting around 2-weeks to this experiment. \r\n* We are keeping this to 2-person engineering team. \r\n* We are doing projects we can reasonably finish in a day.\r\n\r\n### Overview: our values and methodology\r\n\r\nTo be effective, you have to have a process. The hero is neither the knowledge nor the superstar coder. The hero is the process. We want to learn to be better at a successful-building-process by doing.\r\n\r\n__Values__\r\n\r\nWe'd brainstorm a one sentence idea, then share them with each other after 5-minutes. We did a few of these 5-minute sprints. We then scored them using four criteria. The criteria are, in essence, team values:\r\n* Interesting - are they interesting to us?\r\n* Simplicity - are they simple enough (for us) to tackle?\r\n* Uniqueness - are these ideas unique to us and to others?\r\n* Utility - would we use them?\r\n\r\nYes, they are arbitrary. Yes, they are imperfect set of categories. We can live with that. Can you?\r\n\r\n__Methodology__\r\n\r\nWhat about the process? No ground-breaking principles here:\r\n* Build on strength - for speed, use familiar technology (for us, mostly Ruby on Rails)\r\n* Prepare - for new technologies (e.g. a Node app), do some advance reading/tinkering\r\n* DRY - Do not repeat yourself - look for gems wherever possible\r\n* Best practices - we will use TDD; red-green-refactor; frequent commits\r\n* Pragmatism - product should work; function over form (i.e. it doesn’t need to be pretty)\r\n* Modularity - we will try to build templates we can reuse on subsequent days\r\n\r\n### How you can get involved\r\n\r\nDo you like what you're reading? Try your own mini-rapid-project(s). Do it solo. Do it as a pair. What would you get out of a process like this? How would you structure your efforts? Write about it and send us a link to your post or project. \r\n\r\n* Josh Wilborn - <joshua.j.wilborn@gmail.com>\r\n* David Kim - <daviddarden11@gmail.com>\r\n\r\n[Robert Fletcher](github.com/mockdeep/), whose open-source project [Better Means](github.com/mockdeep/better), is an inspiration, and is our coach.\r\n\r\nThanks for reading, and please let us know if we can help you in some way.\r\n\r\nDavid Kim, [dklounge](https://github.com/dklounge)","google":"UA-44430419-1","note":"Don't delete this file! It's used internally to help with page regeneration."}