What Coding Errors Teach Us                           (About Life)

What Coding Errors Teach Us (About Life)

Believe it or not, it's week 4 of coding class! And we've learned a lot about databases, migrations, SQL, ActiveRecord, associations, validations, and consuming & creating APIs. And through it all, there has been one constant. One delightful reminder of the order and structure that guide our code, the meticulousness and precision that code demands...


Anyone who has coded has been there, probably more times than we'd like to admit. But perhaps rather than hunting down each error as soon as it rears its ugly head, we should pause and reflect. Could our code be trying to tell us something? Something... about life? 

The Importance of Closure

syntax error, unexpected end-of-input, expecting keyword_end (SyntaxError)

In Ruby, a SyntaxError is raised whenever your code has an invalid syntax, and a super common reason is a forgotten "end" or "}" of an if statement

There it is, it's glaring at me, taunting me. Come on, computer. You know I started something, of COURSE I meant to end it. Really, there's no way for this to work unless I end it. Can't you just assume that I wanted to end the mother#^@%*&??

Alas, this is not the way code works. And for good reason. Turns out that closure is important both in code and in life. Without an ending, we cannot know that something is over; we cannot let go, move on and discover the outcome. Similarly, without an "end", our code will continue to wander in circles, searching for an answer and experiencing endless confusion.

In code as in life, only we can know where to put the "end". 

It's How You Say It

undefined method `.includes?' for nil:NilClass (NoMethodError)

A NoMethodError is raised when you try to invoke a method that doesn’t exist. So if I have a method called include? and I type includes?, my code will blow up. But why-oh-why doesn't Ruby think to itself, "Let me try that super similar method and see if it works. Oh, wow, it did! Hurray! Hey, Ruti on Rails, this is teamwork."

Once again, Ruby teaches us a valuable lesson about code and life: it's not just what you say, but how you say it. Your words - and how you deliver them - matter a lot. In professional settings, it is important to project confidence without dominating the group, to seek feedback and remember to praise others. In personal relationships, it is important to ask questions, to listen, to show mutual respect. 

This is also true when it comes to our technological communication. CAPITAL LETTERS give us the sense of screaming, too many "!!!!"'s can feel disingenuous, and entire conversations occur in emojis.

While we're wishing that our computers were just a little bit smarter, they have outsmarted us again - by reminding us to think about the how. 

Mistakes Are Not About Blame


Whenever possible, error messages specify exactly where that error took place. In the example above, my Rails code is telling me why it failed ("couldn't find voter") and what line it failed on (#17).

Errors point out our mistake as if to say, "Hey, look - over there! There's the sucker that's causing you problems. Go get him!" Now one might ask, since Ruby knows so precisely where my error has occurred, why it is so eager to point out the culprit but isn't as eager to help me resolve the issue?

Once again, Ruby shares its wisdom. In code, errors are fixable and are often easy(ish) to hunt down. It's not shameful to be a mistake and it's matter-of-fact to be called one. Similarly, in life, it's ok to be told you've made a mistake: it's not personal or meant to hurt your feelings. It's just true - and will likely help you perform better in the future. 

Errors are teaching us that mistakes are about improvement, not about placing blame. We should all strive to be less sensitive, just like our code. 

4 Coding Habits to Form Now (and why it matters)

4 Coding Habits to Form Now (and why it matters)

Coding is Kinda Like Cooking

Coding is Kinda Like Cooking