Inevitably, you will run into problems and obstacles while building your product. Nate and Natty had the following advice to offer on debugging.

One of the most important techniques we used when learning how to code is debugging. It allowed us to do two things: fix our own code when it was broken and parse through others’ code to better understand how they were doing things.

From a backend perspective, debugging is essential. When I first started writing code, I would write what I “thought” was the correct way to do it. Ninty-nine times out of a hundred I was wrong and the code would blow up with some ugly exception that I had no clue about. Copying and pasting the exception into google got me decent mileage, but the real silver bullet I discovered was just to start from the beginning of the method and step through it using the ruby debugger and figure out where I had gone wrong. Almost always I had forgotten to assign some variable or I was calling a method that did something different than I thought.


Complete 10-second survey to read full article!

Inevitably, you will run into problems and obstacles while building your product. Nate and Natty had the following advice to offer on debugging.

One of the most important techniques we used when learning how to code is debugging. It allowed us to do two things: fix our own code when it was broken and parse through others’ code to better understand how they were doing things.

From a backend perspective, debugging is essential. When I first started writing code, I would write what I “thought” was the correct way to do it. Ninty-nine times out of a hundred I was wrong and the code would blow up with some ugly exception that I had no clue about. Copying and pasting the exception into google got me decent mileage, but the real silver bullet I discovered was just to start from the beginning of the method and step through it using the ruby debugger and figure out where I had gone wrong. Almost always I had forgotten to assign some variable or I was calling a method that did something different than I thought.

The other huge thing that is related is that I read and still read copious amounts of open source code written by other people. I’m better at understanding it now, but at the beginning I would take a debugger and walk through the code myself to try to figure out exactly how their code was working so I could make my own code better.

This is super important on the front end as well. Using tools like Firebug or Web Inspector to take apart existing sites and figure out how they’re doing something or making something beautiful is a great way to learn better techniques for front end development. They’re also essential for figuring out how to fix a layout when it’s broken, or how to figure out why an AJAX request didn’t respond the way you would expect.

This is a great, free resource to use when learning how to program and really helped us to bridge the gap from a basic programming book to what current philosophies on development were.

Somewhat related are tools that help you keep your code/team in order. By far the most important is a good version control system. This is something that they don’t ever teach even in college classes, but it’s hugely critical to building a project in the real world. We use git at Everlater and it’s been an amazing choice. When coupled with GitHub, it makes working in a team of two seamless even if you’re working on almost the same code.

Also important is some way of keeping track of the quality of your code as your project grows. This includes a good issue tracker (we simply use the to-do list feature of the free version of Basecamp), and a good way to know when there’s something wrong in your application (Hoptoad is great for Rails devs).

Comment by starttowonder
One important reason to use debugger for languages like Ruby that do not give you a compile time error is to make sure you are able to go thru each and every line of code in the debugger and are sure code is doing what it is supposed to. Because there might be a typo buried in an if statement that might not be caught when testing but this might blow up later on when that if is hit. I know preparing test cases is important, but I am not sure if someone can hit all the lines of code using different test cases unless they are using a debugger to write the test cases itself.
July 2010
Price: $2.99 Add to Cart
  • Lifetime guarantee
  • 100% refund
  • Free updates