End of Week 5 @ Epicodus

Wow, time is flying by. I haven't had time to write down a new post (still don't). So here is my quick recap of the past two weeks:

Since my last post, I've come to understand Ruby a lot more. We devoted two full weeks to building apps with Ruby in a command-line interface. This basically means that there is no web-page for your user-interface. Your interface is in the command line, aka the "Terminal," as Mac users know it. 

Command-line interfaces are interesting because they do what you tell them in a bare-bones style (although you can do some interesting things like add colors, flashing cursors, and ASCII Art).

ASCII Art can be really simple...

...or really complicated.

Ruby is quite a beautiful language. Once you grasp the syntax and understand the concepts of object-oriented design, it becomes easier and intuitive to work with. I'm still not quite there, but I'm getting better every day. Hey, it's only been three weeks of Ruby.

Last week was devoted entirely to building Ruby apps with PostgreSQL, a structured query language that holds the information run through our Ruby methods in a database. From the first day, I was absolutely loving it. Postgres really brings out the power of the Ruby language, allowing you to store, update, delete, and merge information as you wish. Merging SQL tables can be a bit tricky to wrap your head around, but once you get them, it's very useful and exciting. 

Tomorrow we start ActiveRecord. The homework that I've watched so far at learnhowtoprogram.com has already shown me some of ActiveRecord's potential. I am excited to finish the homework and get started building some apps with ActiveRecord. 

So there's my rushed review of the last two weeks. I hope to dedicate at least two days per week to writing blog posts that have a little more thought and structure to them! Until next time, keep on coding...

I found the problem

I have found the problem! The reason why I am so frustrated! The problem is…I don’t have a solution!

This was a joke that I have told a couple of my partners when we were really stuck. I would pretend that a light bulb went on, wait for it…then the punchline. They all laughed (win!).

It’s a stupid joke, but it breaks the tension and allows you to relax for a second. That break from the closed state of concentration; from the seriousness of focus to a relaxed and open state, is vital to learning and growth. But don’t take my word for it, I’m just some guy with a blog. Take it from John Cleese, one of the creative geniuses behind Monty Python, in a hilarious yet scientifically awesome speech on creativity, learning, and work. Totally worth the watch in its entirety, if you are so inclined. 

In all seriousness though, I was inspired to write this particular blog post when I came across an amazing book on Ruby while at Powell’s bookstore (a Portland staple and much cooler than I had envisioned).

That book is Ruby Pocket Reference: A Quick Guide to Ruby by Michael Fitzgerald. The following picture is the eager creeper face that I made when I came across it. Remind you of anyone?

This book is amazing. No story. Just straight up this does this. Right from the start. No chapters of history that, while interesting, take up way too much time. I’m enrolled in a bootcamp, not grad school.

The book reminds me of when I was learning another language from scratch: Spanish. I was on youth exchange to Venezuela my junior year in high school. Problem was, I had studied German in ninth grade (prost!). When I arrived, the only phrases I knew were “hola” and “yo quiero taco bell”.

I found a book called Spanish Verbs that was just a list of…you guessed it…verbs. So I spent hours in my room just studying and memorizing these words. But one of the most useful parts of the book was that it actually explained conjugation to me. Up until that point, I had absolutely no idea what that even meant. Most other books either assumed that I already understood it or did a horrible job explaining it.

Ruby Pocket Reference is similar in that it can be very useful to a beginner. It has lists of Ruby’s Reserved Words (if, else, def, etc), and operators (<<, [], =>, etc). But the most valuable part of the book are the concise descriptions of all the things that make up the language – Class Methods, instance variables, regular expressions, etc. I’m only 15 pages in, but am already more excited than [choose your own favorite thing!]* to finish it, and then read it again.

It may be difficult reading for the absolute beginner, because you will have no means to visualize the definitions and concepts as they would appear in a text editor like Sublime Text. But at the same time, it would be beneficial to those of you considering learning to program on your own, enrolling in a bootcamp, or pursuing other educational methods.

In an ideal world, I would have read through this book two or three times before I arrived for Epicodus. But then again, I’m not sure if I would have benefitted. After all, my perspective today is not that of a complete newb, given that we are already 8 days into Ruby. That’s like, 8 weeks in university time. :D

Either way, I am enjoying this book immensely. Why?

Things are beginning to click.

Clicking is good.

* Lazy writing, right?

Epicodus as Disney World

I don't have to try that hard to get the handwriting of a 5-year old

I've never been to Disney World. I grew up in a small town in New Hampshire, and my parents had the push-me-out-the-door in the morning, call-me-in-at-dark approach to entertaining me and my brothers during the summer.

That being said, there are still a few things about Disney World that everyone knows about. These include:

The lines 

The roller-coasters 

The homogenous culture 

As programming students, we can take these familiar concepts of Disney World characteristics and use them as metaphors for learning to code. Let's start with:

Lines

You needn't have been to Disney World to know that the lines are long. And standing in a line for hours on end is not fun. You're frustrated, agitated, and sometimes even angry. You may want to even walk away.

Translation: It is going to take some time for you to actually get on the ride. You are going to have to put in hours of what may appear to be standing around -- i.e. glancing at code that you can't read, reading explanations of methods you can't understand, or solving problems that you haven't the slightest idea where to start. But all of this frustration, trial and error, and even boredom is just a part of learning something new. 

When you're learning to code, don't try to skip standing in line. Sure, it may seem like others are moving up the line quicker than you, and that may make you feel bad. But you shouldn't fall in the trap of comparing yourself with others. Everyone learns at their own pace, and does so with a unique style that works well with some, and not so well with others. The wait can be long and arduous, but soon enough you get to experience the thrill of...

Roller Coasters

It's why we stand in line, right? The excitement, the thrill, the adrenaline. When you solve a difficult problem with code, and get to see the outcome of that solution in a web browser or even in Sublime Text, it is truly exciting. But roller coasters have their ups and downs, and this is how I felt this past week.

Monday was our first day introducing us to Ruby. I paired with someone of similar level to me, and we slowly made our way through the lessons. I learned a lot. The next day I was paired with someone of lesser ability, and we both struggled throughout the entire day. I felt terrible by the end of the day. Wednesday I paired with someone of similar skill again, and we blazed through our problems and ended up with beautiful-looking code. Thursday was also good, and my partner and I worked well together to finish the lessons with satisfactory code.

Friday was Freaky Friday, or whatever you want to call it. The teachers have been experimenting with what to do on Friday. The week before it was a review day where you get to work on old code. This past Friday was a challenge day. We get a single problem to work on, do it for two hours with one partner, and then switch partners. The catch is that each time you switch, you delete your old code and start over.

A lot of people liked this and were excited by it. I didn't. I am a more methodological, deliberate thinker when it comes to writing code. The time limit meant that you couldn't really think things through. And since we switched partners every two hours, the progress you made with a previous partner was lost. 

But I made sure that I didn't let this get to me. I remembered the good days from the past week, and the excitement that I felt during that time. I know that I will have good days and bad days -- but what will lead me to more good days than bad is my approach to dealing with those days that aren't so pleasant. As a wise man once said, "The problem is not the problem. The problem is your attitude about the problem." Any guesses as to who said it?

The Homogenous Culture

A friend of mine who used to work at Disney World once commented that the management takes culture and roles very seriously. This is done to maintain that culture of fantasy for the children. 

At Epicodus, although we have a diverse student body from many different backgrounds, we do live that same homogenous culture that is the world of the programmer. When I am among my fellow students, I feel as though I fall within an acceptable deviation from the average level of knowledge and awareness of programming. Some of our conversations would leave the average person grasping for straws as to what the hell we were talking about. At the same time, there are also those times where I feel like I just walked into another world that I don't really understand. 

Case in point, there was a Ruby Programmer's meetup last week. The first speaker rose to play hangman with the crowd. He described some esoteric programming problem as the "clue," to a solution that was some sort of Ruby method. My eyes and those of my fellow Epicoders completely glazed over. It was truly a foreign language...for now.

At the same time, the meeting was interesting and fun. Two other speakers (including Epicodus founder Michael Kaiser-Nyman) spoke on interesting subjects that I could largely follow. We then enjoyed a few brews afterwards, and I got to speak with some interesting characters about work and other topics such as economic philosophy.

Epicoders also like to have fun outside of class. I'm more partial to Friday's happy hour, as I enjoy my craft beer on the weekends. Others have gone roller skating, hiking, and other activities. It's easier to make friends when you share a common interest.

Just like at Disney World, where children with dreams of living out their fantasies with their favorite Disney characters come true, dedicated students with a desire to live out their programming fantasies can enjoy the benefits offered by a programming bootcamp, or any other group where motivated like-minded people congregate regularly to learn, teach, and grow. 

Cookies

Last Friday I entered class to see the phone table (where we all place our phones upon entry) filled with three trays of cookies. Having skipped breakfast, I didn't hesitate to grab one of these scrumptious looking temptations. They were even better than they looked. 

When Michael told us at stand-up that he baked the cookies the night before, I was surprised. For a guy that is running two businesses, I don't know how he finds the time to shower, let alone bake cookies, which tasted like they were made from scratch. Seriously, they were really good.

I was reminded of this while setting up this blog the other night, particularly when designing my title image. "Epicoder's Delight" was a play on words based on my experience with the word "Epicurean." 

Back in college, a colleague of mine at the student newspaper wrote a column called "The Epicurean", which reviewed local restaurants. That was the first time I came across the word, so I figured it had something to do with food. However, according to the Stanford Encyclopedia of Philosophy:

The philosophy of Epicurus (341–270 B.C.E.) was a complete and interdependent system, involving a view of the goal of human life (happiness, resulting from absence of physical pain and mental disturbance), an empiricist theory of knowledge (sensations, including the perception of pleasure and pain, are infallible criteria), a description of nature based on atomistic materialism, and a naturalistic account of evolution, from the formation of the world to the emergence of human societies. 

So, maybe "Epicurean" doesn't correlate directly with food. But I'm sure that Epicurus would have something to say about the pleasures to be had from good food, which coincidentally is largely indebted to atomic manipulation (thermodynamics, i.e. 350 degree heat ;). 

It should be noted that I could be entirely wrong that the name Epicodus was inspired by Epicurus. It could just be a concat of "Epic" and "Code," or something else entirely, although this seems unlikely.

Either way, I learned one thing from this experience and reflection: Bake on, Michael, bake on.

End of Week 2 @Epicodus

This morning I unwound from another intense week at Epicodus with an exploration of the city. It was nothing too adventurous -- just a visit to the east side of the river from my downtown apartment. But during my walk, I decided that maintaining a blog that reflected on things I have learned and experienced would probably be a good idea. So here she is.

The first two weeks of study were devoted entirely to Javascript, with a bit of jQuery, html and css to turn the scripts into functioning pages. We developed our skills by diving right into creating applications with our pair on the first day.  It was pretty exciting.

I was less terrified on the first day than I would have been if it were not for the pot-luck Michael threw the night before. I got to meet most of the other 59 students that I would be working with over great food and a few beers. This really calmed my nerves. Turns out that I wasn't the only one who was nearly a complete newbie to the world of programming.

When the first day finally did arrive, we created a script called "Queen Attack". We had to write a js script that identified when the queen could attack an opponent in chess. My partner and I worked together to devise a solution to this problem and created one pretty quickly. We then moved on to the next two lessons and completed those just in time. By the end of the day, I felt a sense of accomplishment and adventure that I hadn't felt in a long time. And this is coming from a guy who worked in the financial services world where I engaged clients worth tens of millions of dollars on a regular basis.

Pair programming was especially useful for reaching a solution. When my partner was at a loss for where to go, I would offer some insight, and vice versa. We were both excited and motivated to solve the problem. The rest of the room appeared to share this same enthusiasm. I could feel the excitement and energy and was glad that I was part of it.

The next 9 days grew increasingly complex. We switch pairs every day, which lets us not only get to know someone new in a more intimate manner, but also to see different styles of learning, working, and skill levels. I have been happy with most of my pairs, although there are a few that I don't think that I really want to work with again, largely due to differences in working style and skill. Curiously, the most interesting days have been where I have been paired with someone of similar skill level, which forced us to really understand the concepts and syntax, take it slow, and apply ourselves to reach a solution. Probably 6 out of the 10 pairs I've worked with fall into this category, and working with those partners has been the most rewarding, as far as learning js goes.

Other partners have had higher or lower skill levels than me. This was also interesting in its own right. When I was the more skilled partner, I really had to take the reigns and work even harder. This didn't always produce the best results, as I'm still pretty new to the syntax and thinking like a programmer. But it did have at least one purpose: motivating me to learn more outside of class. When I was the less-skilled programmer, I learned a lot of neat tricks and ways of thinking, but didn't learn as much as when I was with others of comparable skill. 

I also noticed a few of my pairs brought books to class, so I ordered a few of my own from Amazon:

Pragmatic Guide to Git by Travis Swicegood

Version Control with Git by Jon Loeliger & Matthew McCullough

Practical Object-Oriented Design in Ruby by Sandi Metz

Secrets of the Javascript Ninja by John Resig & Bear Bibeault

One of my partners had the two git books (and even a third!). I picked up his copy of "Pragmatic Guide" and decided to purchase it about 10 pages in. The other books had good reviews on Amazon, so I figured what the hell. These books are in addition to the book "HTML & CSS" by Jon Duckett that Michael recommend we purchase before class started. I'll make a post reviewing each of these books in a few months.

Anyways, I will write here from time to time, with, at the very least, a weekend review. This post doesn't capture the full breadth of my last two weeks, but it's a start. So I'll revisit some other interesting things in later posts (like my first night in Portland, which was a bit wild).

Monday we start in Ruby, which is very exciting for me. That's largely what I'm here for. If Javascript was as interesting and exciting as it was these past two weeks, I just can't wait to see what Ruby can do.

Til next time, code on young Padwans.