In my first post on the sabbatical series, I talked about my motivation for taking some time to level up my professional development and outlined the process I used to plan the escape from my last job. My first rule for planning was "learn how to pivot," and that advice couldn't have been more important and practical for my current journey. I left the first post, written the first week after I quit my job, with some pretty concrete (or so I thought) goals and actions needed to fulfill those goals. I even put blocks of time in my calendar to remind me when to switch to different activities and planned to follow my calendar into battle everyday until victory was declared and I had the brand new dream job I had always wanted. The problem was that my multi-tasking approach wasn't suited for what I was trying to do personally, and so I had to immediately pivot to a different plan of attack which I have carried out the last few weeks since writing that first post.
The main problem with my initial approach was that I had around four areas I thought I could work on that all included different skills I was trying to work on:
- learning new programming languages/frameworks
- contributing to open-source projects
- reading about/doing domain modeling
- writing about my progress through blog posts like this series.
I had thought that I should switch it up between these tasks to break up the monotony that comes from doing the same thing each day, all day; however, when you look at those tasks and how they could relate to each other, you might see a problem.
Hey...I'm new here, but I'ma fix all the bugs at once
To properly contribute to open-source projects, you have to first know the language and applicable frameworks or libraries that the particular open-source project you are trying to contribute to is using. Sure, there are documentation tasks, re-rolling patches, and other things you can do without much knowledge of a language or framework, but you aren't going to be useful in solving bugs or other issues unless you fully understand what you are working with.
I had spent a couple years working in Drupal, Drupal 7 mainly, and so I thought I could jump into development there; however, the current development branch of the next version of Drupal completely changes up the core of the project and requires some time to learn and get used to patterns and best practices for object-oriented programming, OOP, which I am currently not the most experienced with. I thought of helping out with Drupal 7 modules that have code and hooks I already understand, but my limited experience with contributed modules is that the maintainer of the project can dictate whatever they want. They can also just ignore you. The point I'm trying to make is that any investment in open-source contributions should be viewed from the long term. You are going to come in a NOOB and need to gain trust from the community even if you are the best developer since garbage collection. Anyone saying open-source projects don't have politics or egos behind them is a big fat liar.
Now, I'm not discouraging anyone from jumping into an open-source project cold turkey, but be warned that there will be a lot of history, personalities, and idioms that you will have to learn. You certainly can benefit from jumping into a project, but this is where I'd like to make a distinction between learning styles, and why I don't like to jump into working with something I don't quite feel comfortable with yet.
What you circling around for?...Jump in the Pile!
"Just do it!" You've probably heard that saying when asking someone how they learned to code or program in a certain language. The theory goes that you can read all the theory you want, but until you actually start doing something, you won't benefit from learning all that theory. Hell, you might even learn things you don't need , will never use, or will soon forget before you actually use them. If you get stuck while jumping in, you can just Google your problem and work your way in from there. Jumping in produces results quickly, and you can always refactor what you started with into something more useful later. The refactoring process in and of itself is a useful endeavor to undertake and reinforces the new concept you just learned and why the old code and concept are not optimal.
In theory, it's not a bad approach and might work best for you. If, I had started out by jumping into developing code for my sabbatical application several weeks ago, I probably would have some sort of a prototype now and maybe even be in the refactoring stages right now. If I had jumped into contributing to the next version of Drupal, I might already have some commits attributed to my name and have a much better understanding of how to build websites in the next version.
Deductive vs. Inductive Reasoning
I like to think of deduction versus induction as an example of why I think circling around a topic you don't understand is better than jumping into the "doing" of the topic at hand. Deduction works from the more general to the more specific. You start out with a theory and then work your way down to concrete examples that support that theory. For learning a programming language that is object-oriented, you might start off with learning OOP principles, since they apply to many programming languages including the one you are trying to learn, and then begin with the syntax of the language, hopefully reinforcing the OOP concepts long the way.
Generally, it's a good idea to choose a source for learning that has grouped many concepts together, maybe even into courses with defined pathways, rather than piecing together blog posts about the topics you are trying to learn. It's also a good idea to ensure that your instructors are seasoned in their profession and have "been there done that." This way, you get the "bad" code presented as something you might initially try next to an improved syntax they have come to use out of experience. One such online school that I can't recommend more highly is Codeschool. I basically gobbled up all the courses I could on Ruby and JS before suspending my account, but I'm sure I'll be back to learn more from them in the future.
Contrasted with deduction is induction where you move from more specific observations all the way up to generalized theories. For my case of wanting to build a web application, you might pick a framework and begin with initializing a new project. Since I wanted to learn Ruby on Rails, that might look something like this:
gem install rails rails new
From those two commands, you will have generated a lot of files and a start to an application, but you don't really have much to go on from there. Creating models, controllers, views, etc. will require you to Google for answers each time, and you will more than likely be getting answers from different sources and different authors without any coherent narrative to the story you are learning. Gotchas might not come up, and you may be learning outdated or primitive ways to do things where more elegant solutions exist. Sure, you will have a working prototype for an application before I will, but I'm not sure that will be a good thing in the long run.
I think the clear solution is to utilize both approaches when learning a new topic like a programming language.
When taking a more deductive approach, always be asking yourself how you could use a certain topic that you are learning. For example, while I was going through my learning of Ruby on Codeschool, I took all of the Ruby courses except one for APIs. I didn't plan to expose my application to other clients, so I stopped learning that course. However, all eight other course I took included concepts i definitely hope to implement soon.
When taking a more inductive approach, always be looking for pieces of code or concepts that really puzzle you and make you take a step back. Chances are, if you feel rattled by looking at a new pieces of code someone else is using as an example, you probably need to broaden your horizons and learn more abstract concepts. I had this feeling the first time I saw the "preventDefault()" function used in JS for anchor tags. I had no idea you could prevent their default action and that this was a common practice for AJAX calls. Sure enough, I needed to learn a lot more about the DOM and basic JS concepts in DOM interaction.
Sail on Rails
Since I went through a lot of course material on Ruby and Ruby on Rails, RoR, I thought it would be a good idea to use RoR as the platform for the Sabbatical.io application I was going to build. I want to do a form of Test Driven Development, TDD, called "test first" development. I can't really fully explain the tenets of TDD to you, but I know "test first" development just means you start with writing tests before you start coding anything. The tests fail, you make them pass, and then you move onto the next feature of your application. I would guess true TDD would involve all aspects of design being thought of with testing in mind or something like that. To accomplish my test first development, I will use Rspec to run my tests. Rspec is a behavior driven development solution for Ruby that has tight integration with RoR.
In order to update my sad bare Github repo to work with Rails and Rspec I will do the following:
- clone my repo locally
- create a gemset for this project
- install Rails
- install Rspec
- clean up code for push back to Github
- call it a day
The commands will look something like this:
$ git clone $ cd $ rvm use ruby-2.2.0@ --ruby-version --create $ gem install rails $ rails new . $ vim Gemfile ...adding 'rails-rspec' to development and test environments $ bundle install $ rails generate rspec:install $ vim .gitignore ...add stuff from https://github.com/github/gitignore/blob/master/Ruby.gitignore $ git add --all $ git commit -m "adding Rails and Rspec to project" $ git push origin master
I'm sure I forgot something there I will need to get started, but effectively I've started my Rails application and made sure that testing will be on my mind every step of the way as I develop this app.