An extremely detailed and well written article about exactly what the title says. My biggest take-aways:

1. “Only make a decision when you have at least three offers in hand.” Don’t put yourself in a position where you’re desperate for any job that comes up. Waiting until you have multiple offers can also allow for some negotiation of the offer.

2. Use a system, such as CRM software (Highrise is a good option – it’s free for up to 2 users and 250 contacts!), to organize leads and help you follow up as you progress in the application process.

3. Use rejection as an opportunity to learn how to improve your future applications.

4. Be honest with the technical skills that you highlight in your covering letter and cv. Don’t pad your list with libraries and frameworks that you used once a while ago. This will just hurt you.

5. Technical challenges can be, well, challenging. Not being able to complete one may not mean the end of the line in the interview, and how you handle not being able to complete one definitely matters. Even if you blow it, technical challenges are a good learning experiences for the future in removing unknown unknowns.

6. Getting work gets easier the longer you have had work.

This post details some of my experience in the Firehose Project.

I finished Nomster last week and was ready to keep learning at a break-neck pace. The Object Oriented Programming lessons appeared on my dashboard and I got coding along with Ken. After the finishing the videos, I wanted to test out my newly learned skills and started work on the first Image Blur coding challenge.

From the description, it seemed like a light warm up compared to what was going to come in Image Blur 2 and 3, and I thought I would breeze through it in a matter of minutes. After all, I had been doing similar (and many more difficult) challenges for weeks through both Code Abbey and Code Wars. Instead, I spent a frustrating hour trying to figure out what I was doing wrong.

Image Blur 1 was the first time that I built a class to solve a problem. Normally, I would just create a method or two and go from there. I built the Image class, defined my initialize and output_image methods in the class, created a new instance of Image, called output_image on it, and then got this error:

wrong number of arguments (1 for 0)

What do you mean, wrong number of arguments?! I fiddled around with my code, I googled, I banged my head in frustration against my desk. What was wrong?! What had I missed??

I stepped away from my code for a few minutes, hoping for some subconscious clarity. Upon returning, I finally realized the fatal flaw: I hadn’t defined initialize, I defined initalize. Notice the slight, one letter difference. I fixed it and the code ran perfectly.

I believe it was on Reconcilable Differences that John Siracusa mentioned that it’s often the variables or elements that you are most sure of that cause the errors in your code. After I experienced this, I fully agree with him. If you’re getting an error, always check what you are most sure of. I bet you’ll find something you missed.

When I posted the ABCs of Programming earlier this week, I embedded a video from YouTube. The video looked fine on my iMac, but when I looked at it on my iPhone, it was hideously oversized. A quick google search lead to this fantastic utility.

Just paste in the URL and it automatically generates responsive embed codes. Works with YouTube, Vimeo, Google Maps, Instagram, Vine, and more.

Update: I just learned that Bootstrap already includes responsive embed by default.

One of my favourite shows is the Office (US). Last week, Holly and I watched the episode where Dwight executed a “fire drill” and Stanley had a heart attack. Scared by his inability to help, Michael hired a first aid instructor to give a presentation. The first aid instructor began her presentation by asking if anyone knew the first aid “ABCs” (Airway, Breathing, Circulation). Indignant, Michael replied that he couldn’t remember the first aid ABCs because the ABCs of sales are “Always Be Closing”. You’ll want to see what happens next:

The concept of “ABCs” got me thinking: what are the ABCs of programming? What immediately came to mind, and what I believe to be true is Always Be Coding. Daily practice has been one of the biggest drivers of my continuing progress. The process of thinking through challenges and developing the code that solves them takes all of the syntax I learned when I just started and pushes it to the front of my brain, making it more easily accessible in the future, which frees up brain power to actually solve the challenge.

One of the biggest problems that I had when starting out was finding places to practice. To save you the trouble, here are some of the best resources that I’ve found:

1. Codecademy – This one is a cheating a little bit, since it’s more of a learn-to-code resource. However, I found the structure of most of the lessons (and especially jQuery – I don’t think I’m able to forget $(document).ready) to be very practice friendly. After you’re finished the lessons, you’ll want to find another resource.

2. Practice Python – Before I started learning Ruby, I was learning Python. Both languages are really great, with many similarities that make them fairly easy to transition between. Practice Python has 24 beginners programming exercises for Python programmers with solutions to all but the last. It doesn’t look like this site is being updated any more, but the exercises are still fun practice.

3. CodeWars – CodeWars is the ultimate practice site, with hundreds of challenges for all different skill levels that are doable in many different programming languages. They range from giving you practice in programming fundamentals to mind-bending challenges. I don’t use CodeWars as much as I could because I found some of the descriptions to the challenges to be hard to understand.

4. Code Abbey – My personal favourite. They currently have 211 challenges of varying difficulty, all of which are well explained. You can solve them in any order and in a variety of programming languages. After they are solved, you can view what others did, which is a really great learning resource!

5. Reddit’s Daily Programmer Subreddit – These challenges are constantly being updated, doable in any language, and you will likely receive feedback from other redditors after posting your solution. However, I found that even the “Easy” challenges were very difficult when I was a beginner.

Whatever method or resource you use, it is important to practice regularly. And once you start practicing, I’m sure that you will see improvement in no time!

Have another practice resouce that I haven’t listed? Let me know via Twitter!

The first programming nearly everyone does is the simple “Hello, world” script. It’s instant gratification at its best. Type something into a computer, the computer spits something out. You’re a programmer!

I’ve come a long way from my “Hello, world” days, but I still learn a ton every day. This blog is my way of showing myself what I’ve learned. The cliche is that until you can explain a topic to a 10 year old, you don’t really know the topic. Consider this blog my explanation, although I doubt if you’re a 10 year old.

I’m currently in my second week of the Firehose Project bootcamp, learning Ruby on Rails, algorithms, data structures – all that I need to know to be a competent beginner programmer. I plan to cover topics that I’m learning as I go through Firehose, as well as anything incedental that I’m learning or thinking about.

Here’s to getting better!