Six weeks ago I set out to gain some basic knowledge about "popular programming languages," which I missed during university, but I didn't really know where to start. Following recommendations from the horde of web developers that is Toronto's tech scene, I checked out the suite of languages taught by CodeAcademy... namely HTML, CSS, PHP, JavaScript, JQuery, Python and Ruby. None of these tutorials went into great depth, but they gave me the overview I was looking for.

Very briefly summarized:

HTML places elements on a webpage for display on a web browser, and allows individual elements to be customized.
CSS customizes the look of HTML elements, and allows a single set of customizations to be reused across many HTML elements.
PHP is processed server-side and can be used to modify HTML pages on-the-fly before those pages are sent to the client's browser. PHP can be used as a general scripting language, but it is annoying to learn/write.
JavaScript can also be used to modify HTML pages, but it is processed client-side which makes it useful for different tasks. Lots of libraries are available and JS can be used for general scripting tasks.
JQuery a JavaScript library which creates interactive HTML elements, such as moving images or clickable text.
Ruby and Python are both easy-to-use Object Oriented languages. They use simpler syntax and provide more built-in functions than a language like C, but suffer a performance hit and may become unwieldy when you want to write something very specific.

Now it's time to look back at what went right/wrong in this project, and figure out how to improve for the next one.

1) The resources, CodeAcademy and later RubyMonk, were great.

These web tutorials hit an excellent balance between detail and brevity that felt missing from my university textbooks and the typical tutorials which pop out of a search engine. Both of these tutorials center around an in-browser coding environment for examples and exercises, and I suspect this is the key to their success. When a lesson seems obvious (what is a variable, how do you parse a string, etc), I can simply write down the syntax and move on. But when an idea is less obvious (Ruby's splat operator), I can immediately start playing with it without losing the context of the lesson.

Perhaps the biggest takeaway here is that I didn't find these great tutorials on my own, they were recommended to me by other programmers. So the next time I want to learn a language, I'll probably skip Google entirely and just start asking for advice. Seems obvious, when I put it that way.

2) The LESSONS ARE SHALLOW

It may not come as a surprise that "introductory" tutorials didn't give me a great deal of depth. While I'm fairly comfortable carrying on a conversation in these languages, and can handle code fragments, I would struggle to write full programs. So for my next project, I'll write some full programs.

3) ENVIRONMENT GIVEN IS NOT ENVIRONMENT LEARNED

The tutorials in 1) were great because they offered an in-browser coding envionment for hands-on examples, but using their environment doesn't teach me how to set up my own for a real project. There are certainly benefits to skipping environment setup in a language tutorial, but it doesn't feel right to say "I learned Python" while not currently knowing how to execute the code that I've written.

The solution is fairly simple: For my next project I want to write some Python and/or Ruby, and before that I'll have to dedicate some time to figuring out environment setup.

4) The articles are useful for me, but not for anyone else

To any reader other than myself, this series of articles is probably difficult to read. They're full of my own idiosyncrasies and skip over topics which I already understood. I have to decide if it's worth taking the time to fix these issues for other readers.

Would fellow students benefit from my notes being improved? Only if they skip the original tutorials, which they never should given that my best notes still aren't going to beat a professionally-written tutorial.

How about potential employers? It's difficult to imagine an employer taking the time to read pages of my notes in any format. But they might glance through to see what sort of work I did, and I should strive to make a good first-impression. So perhaps I shouldn't change my basic writing style, but should put a bit more effort into categorizing and summarizing my notes. Make it easy for a person to figure out what my notes contain.