The 1212 learning process

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!

We’re so back

A year went by and I ended up not writing much! So it goes. For what it’s worth, I definitely can’t complain about anything that has gone on since then. Even now, things have been pretty good.

And I think that’s why I’ve considered writing again. While things have been going well, there’s the gnawing sense that perhaps, things could be even better. I want to improve my existence through means other than my usual gaming/exercise hobbies. What might that entail, you ask? To that I say, lots of coding and talking to people. Perhaps even at the same time. But not exactly in the same way as my day job. It’s a bit much to explain, and I hope it will make more sense when I elaborate in a future post.

On the creative side of things, I did my share of drawing last year but I found it wasn’t quite what I enjoyed doing. Pixel art is still pretty fun though; I see myself coming back to it here and there.

As an update, I’m currently learning Ruby on Rails. I’m working through the Getting Started guide at a relatively decent-ish speed (took about a week to work through it). I’m towards the end of it, but of course we all know that’ll only be the beginning.

I intend to start iterating quickly on project prototypes. Then I will write about those too. My goal is to get really good at throwing together solid proof-of-concepts and getting them in front of people very quickly. I spend a lot of my time overthinking, and it’s about time that I practice not doing that. I have the experience to pick things up and work through them, but I have been in a comfortable position for so long that it’s easy to get complacent.

So hopefully it’s a tad easier to see why I’m writing this now. Until next time!