Stuck? Stop Pouting and Start Checking Boxes

Life is great. You’re coding along, passing tests left and right. (Fail fast? More like --fail-never, amiright?)

And then it happens: a test fails. And fails. And… fails again.

About twenty minutes later, you start pouting. Sighing. You may even begin to question the integrity of the spec file — after all, you can’t really be this dumb, right?

Gaga knows best.

Stahhhhhp. There’s a better way! Instead of letting your frustration cloud your judgment, use a checklist. Because as any good INTJ can tell you… #ProcessRules.

Every developer (in every stage of experience) has their own personal set of foibles and fail-traps. So be sure to notice yours, and then add it to your checklist.

To help get you started, here’s mine:

Read the README

Whether you’re doing a coding lesson or navigating a new API, an ounce of pre-reading is worth a pound of, uh, failure. Read it first, and then read it again if you get stuck.

Reading is fun..damental.

When I skip the README because I just can’t wait to get started coding, I spend more time later fixing silly errors.

Check Your Return Values

Your programs pass around so many values that sometimes you may begin to feel like Lucy in the chocolate factory. Just me?

Passing values = wrapping chocolates (??)

When I have a failure involving types — for example, a nil or string value instead of an array — I’ve learned to look back one or two steps to see where the return values went awry.

The most common culprit for me is the IF statement that ends with a variable assignment, shovel or puts. These return the new value, shoveled value or nil (respectively) — and sometimes the program expects something else.

For example, check out the code snippet below. What if our program expected #add_to_dirty_pile to return the full @@dirty_clothes array after every new Pants object was added to the pile? Neither the IF nor the ELSE in the below example would do that.

class Pants
attr_accessor :brand, :status
@@dirty_clothes = []
    def initialize(brand:, status:)
@brand = brand
@status = status
    def self.dirty_clothes
    def add_to_dirty_pile
if self.status == "clean"
puts "Don't be wasteful... those pants are clean!"
@@dirty_clothes << self
# add explicit return value here, e.g. @@dirty_clothes
pants = "Levis", status: "dirty")
=> [#<Pants:0x007fa36d0a80f8 @brand="Levis", @status="dirty">]
=> [#<Pants:0x007fa36d0a80f8 @brand="Levis", @status="dirty">]
pants2  = "JNCO", status: "clean")
=> #<Pants:0x007fa36d081ac0 @brand="JNCO", @status="clean">
Don't be wasteful... those pants are clean!
=> nil

The moral of the story? Understand the expected return value for every method and then check to make sure you’ve structured your code to return it!

Clearly Define the Problem

You’ve poked around in Pry. You’ve played around in your IRB. You’ve read and understand the Rspec failure message and spec file (obviously). It’s been half an hour since you started down this rabbit hole and you feel like you may die in the dark — alone, and still failing the test. Yikes.

But… do you even know the problem, brah? Or are you just typing?

Typing typing typing typing and still failing.

When I pause to clearly define the problem, I often realize that I haven’t fully processed the test failures or error messages. Instead, I’ve jumped feet-first into a pool of mindless tinkering. I often do more harm than good.

For me it helps to comment out a brief synopsis of the problem right there in my code (I delete it later). I include the specific error message and my theories about what could be happening. This focuses my tinkering and speeds up my process.

When tests and errors get you down, don’t pout — get out your checklist. Even though yours may be much different than mine, one thing’s for sure: checking your boxes will save you time and frustration. Good luck!