Like I mentioned in a previous post, Eva and Fong came up to San Francisco to learn programming with me. In this blog post I will write about how I taught them, why I structured the learning the way I did, and why it worked. It’s easy to list out everything they did/learned in chronological order, but that would be useless and you will miss the point. It’s important to understand the details and why it works, and so I will start with the fundamentals. Prepare for a long read.
Fundamentals to keep in mind through your ENTIRE programming journey:
Before Eva and Fong started, I created a blog for them. I told them to write about their programming journey and what they learned. In the beginning it is difficult, you can ask them. It took a week of nagging to get them to write just one blog entry. But now, it almost feel wrong not to write about the project they’ve spent alot of time on.
If you use an API on your project, tweet or email the company telling them what you thought about their API. When you receive a prize at a hackathon, show your appreciation by sending them a nice tweet, or write a blog post about it. Make each blog post the best ever, submit it to hacker-news with the expectation of making it to the front page (even though most of them dont).
The biggest benefit of a healthy communication is that it makes you responsible for your projects, which brings me to my next point.
Fong and Eva both learned that finishing a project is hard, but important. I made it clear that we will not start a new project unless they wrote a blog post about it, tweeted at API companies, and posted it to hacker news. Although the first project was just a Tic-Tac-Toe game, it was the best Tic-Tac-Toe game that they’ve ever made. You don’t ever want to write about a crappy project, so no matter now simple or irrelevant it is. If you are working on a project it has to be the best you can get it. I have seen too many developers work on side projects that never see the light of day. If you are learning programming, you have to learn from the beginning to value your time and effort and finish your projects to justify it.
The last 20% takes 80% of the effort. Developers can implement the ‘idea’ of a project in a day or two. It takes double that time to test every case and work out every edge case to deliver a ‘perfect’ product. Spend that 80% on the last 20% of your project, it will make a great story in many, many interviews.
If you are stuck, DO NOT stare at your code. Go out for a walk, get some fresh air, and think about it. You are stuck because there is something wrong with your logic and the best way to fix it is to think through it step by step in your head or on a paper. Programmers get paid alot of money because they think; Problems get solved when you think about it, coding is bitch work. Great project managers usually have an extensive coding background and are well trained in thinking and problem solving.
With that said, if you get stuck for more than 20 minutes and you’re not getting anywhere, ASK. If you can’t get any leads in 20 minutes then you’re NOT going to get anywhere closer in the next hour. Trust Eva. She wasted 5 hours one day from a stupid bug, hard lesson learned. Take a walk, and go work on something else. Then come back to it. Being able to detach yourself from a problem and divert your focus is a skill.
4) Think 2:
You probably figured it out by now, thinking is very important in a programmer’s life. DO NOT, especially if your are learning how to code, copy-paste code. If you want to learn how to do code something, copy-paste – “Look, it works!” will not get you anywhere. Instead, whenever you see code, you must understand what it is doing before attempting to try it. When you get better at this, understand other people’s code, simplify the code to exactly what you need, and the write it out. If you do this regularly from the beginning, you will be a phenomenal developer in a few months.
Learn how to figure out things yourself. DO NOT ask coding questions unless you’ve been stuck on it for at least 20 minutes. Programmers must be independent. They are great thinkers and great communicators. To become one of them you must be able to think logically and figure out why problems occur. A problem that many young developers face is that they have trouble writing out what they really need. Many of us has been there, you know what the problem is but you don’t know what to search for. This is a skill that you must develop right from the beginning, it ties nicely back to being a communication in point 1.
Now with these 5 points in mind, here’s a chronological order of what Eva and Fong learned:
Days 1-3: Basics of programming with Ruby.
I choose Ruby because it is easiest to get started with programming. There is very little syntactic constraints (spaces vs tabs, type declaration, etc.) in Ruby, so Eva and Fong was able to focus on the programming thought process rather than figuring out syntax. They learned if statements, loops, data structures, and solved programming puzzles like (FizzBuzz, replacing characters in a string, reverse an array, findMax). It is important to learn about classes and objects.
*note* I don’t teach them ruby specific syntax. I told them to always use parenthesis for parameters, and always write return at the end of each function. That way, when they learn other languages they’ll be able to pick up on them faster.
Day 4: HTML
HTML/CSS is not really a language, so it’s not necessary to spend too much time here. Eva and Fong spent a day with HTML and played around with a few tags, and whipped up forms, information pages, etc. I made sure that they ONLY used HTML tags. This builds up the excitement for CSS. Important things to learn here is block vs inline HTML, ids vs classes.
Day 5: CSS
After playing with HTML, the questions “how do you put this there, how do you make this ugly HTML page prettier?” came up. CSS is the perfect answer. Spend this day to style happily (all the HTML pages built the previous day). Important things to learn here is relative/absolute/fixed positioning, and the flow of HTML elements and how absolute and fixed positioning can take elements how of the normal flow.
jQuery takes a little bit of getting used to, and since there’s programming involved learning the jQuery framework took some time. Spent a few days making their html pages interactive.
Days 8-15: First Project: Tic Tac Toe
Days 16-20: Sinatra
After a project of Tic Tac Toe that never seemed to end, Fong and Eva couldn’t be more excited to learn something new. Learning some server side code is an exciting refresh from what they’ve been doing. I chose sinatra because it’s the cleanest, simplest, web framework I’ve ever worked with, and the simplicity makes explaining how the web works a piece of cake.
Days 20-22: PhotoShop
Photoshop is important for great design. It’s intimidating for those who has never used it before (at least for me at one point), but sites created with the help of Photoshop is a notch better that your typical bootstrap site. And all you really need to know is blending options. Any reasonably success developer will need PhotoShop, so it’s important to learn it, and use it for all of your projects.
Days 20-27: Project 2 – DragPic
Days 28-30: RSpec
At this point, Fong and Eva are comfortable with building web applications. At this point, they’ve realized how easily code can break, and how one change can destroy everything. Now, test driven development makes perfect sense. We spent a few days going over rspec, and Eva and Fong wrote out the test cases for their daily morning coding practice. Did I mention that they are solving 1 technical question every morning? From day 28 on, they had to write rspec for them as well BEFORE they start coding.
Days 30-35: BackboneJS
By taking on a project with a larger scope (like Dragpic), you learn alot, and run into problems that you wish had better solution. Only then do you truely appreciate the value of frameworks out there to help you. I have not yet found any great backboneJS tutorials, all of them provides TOO much information at once. Here’s how I taught it:
First, learn about model. Create a model for just ONE database entry. Learn how to modify it, save it.
Second, learn about views. Create a view for the model that you’ve been working on. Add event listeners, appreciate how the views can bind with the model so snugly and how well everything fits together.
Third, collections should now make sense. You cant manually type out every single model, especially if you don’t know how many models there are.
We never learned the routing class. I don’t feel like it’s important just yet.
Days 35-40: Android
1) Girls are amazing at coding.
2) Not graduating with a CS degree is NOT an excuse.
3) Coding is fun, everyone can learn it.
GO FORTH AND CONQUER!
Thanks for reading,
If you’d like to know more about their journey, go ask them!