Without any ado, I’m going to discuss a new theoretical method, the 1212 learning process. The process is simple. Trying to learn new a new software stack quickly? Do four projects, each of which are your own choosing. They will be ugly, they will be painfully unoriginal, and they will be wonderful little troves of knowledge. You will spend decreasing amounts of time on each project:
- 1 month on the first project
- 2 weeks on the second project
- 1 week on the third project
- 2 days on the final project
These projects will most likely not see the light of day, but you will learn a bunch of things. They will also be distinct projects from one-another to encourage variety in your day-to-day problem solving.
Project 1: The Warm-Up (1 month)
This gives plenty of time to trip over yourself constantly at the beginning and not feel the immediate doom of a close deadline. Every mistake can be seen as a learning experience, and the time spent on hitches will be a smaller percentage of the total time you have.
Project 2: The Build-Up (2 weeks)
By this point, the small things should be easier to navigate around. More significant steps need to be made per day but there is still a bit of time to iron out any unexpected issues. It is possible that some polish may be foregone.
Project 3: The Refinement (1 week)
Efficiency combined with consistency will be paramount here. Some simple workflows may be second nature at this point, but now things are more serious. A bad enough setback could put you behind, but your skills from the previous two projects will help to understand the intricacies and work around the issues.
Project 4: The Crucible (2 days)
Your ability to very quickly get something out the door will be forcibly squeezed out of you. The shortest path to success is the only path.
What this is, and what this isn’t
This process flushes out the bad projects you will inevitably make when taking on a new tech stack. By setting progressively shorter deadlines, you’re pushing yourself to move. We want to see through the things that don’t matter and get to the core of what we want to get out of the door.
This process does not intend to produce any software of value. While happy accidents are always a nice possibility, they are not the intention.
Some last things
So you might be wondering, does this process actually work? No clue; I just made it up. The good news is that I’m currently working on my 1-month project, so I am on my way to understanding the viability of the approach.
The project is an aggressively simple one, create a simple blogging application using Ruby on Rails. It needs to be a straightforward, possibly ugly, but functional MVP. In theory, it would be something I’d use if I wanted to sell to the totally-niche subgroup who desperately needs yet another blogging software. My hard deadline is June 15th.
For the ultra curious, the project is available to look at on Github. At the time of writing, lots of stuff is (justifiably) missing, but stay tuned for progress on future posts!