The Best Way to Learn is to BREAK Things

I don’t know why we weren’t encouraged more as kids to color outside the lines. When I was growing up, everything had to be within the boundaries our parents and teachers gave us. Maybe times have changed (I’m not a father), maybe they haven’t – but working in the tech industry has made me realize this concept: things don’t always work the way (you think) they should.

Even more importantly, I think this is the best way to understand something: BREAK it down, BREAK assumptions, and BREAK the rules.

Now, as a software developer, this principle is foundational to my learning and how I write code (and honestly, I think this is a universal approach that can help you in all areas of life!)

Whenever I faced a problem, whether it be something as simple as a paper jam in a printer or something more complex like figuring out what ‘this’ is in JavaScript, I use these three concepts to help me find a solution. Let me show you what I mean.

BREAK IT DOWN:

In this first step, take some time to pause and consider everything, and I mean everything, that could be blocking you from getting to your goal.

Paper jam? Well, yes there is obviously a paper jam in the printer because the error says so. But you’d be surprised, that isn’t always the case.

What do we know for sure? I don’t have the page I printed in my hand.

1. Is the printer on? Yes.
2. Is there enough paper in the tray? Yes.
3. Did I see the error myself or did someone tell me about the error from the other room? For now, let’s assume I saw it myself (there’s a big difference by the way, more on this later).
4. Do I see a stuck paper when I open the printer? Yes.
5. Did removing the paper fix the problem after I closed it back up? Yes.
6. Can I print another page without running into the same problem? Yes.

OK – now we know it works! Sweet! But I had to ask myself at least 5 questions before I got to my expected result. It’s not always as simple as fixing the immediate problem. If I said no to any of the questions above, I could have gone about solving this problem a completely different way!

Coding can be approached in the same way. One of the things we are learning right now is how to read code. Learning to parse code like the V8 engine for JavaScript is ultimately key to ensuring you understand what the code is actually doing. Using the right terminology will help in the long run because you can BREAK down what is happening as your code is executed line by line. Here’s an example:

console.log('Number 5:', 5);

When I break it down, I’d read this line like this:

“The string ‘Number 5:’ and the number 5 are being passed as arguments into the log method of the console object”

*Note: JavaScript generally executes from right to left

Why not just say “console.log number 5 and 5”? Even though its might be an extreme example, imagine parsing through a Class with methods that have multiple conditionals, callback functions built using a library you just picked up – it can be easy to get lost in code, so breaking it down one element at a time can help slow you down and really see what is happening.

Furthermore, the dev tools are great for this with breakpoints! You can pause the code on each line and read it as you go to make sure you are on the right track logically. If you get an unexpected result… it’s time to BREAK assumptions!

BREAK ASSUMPTIONS

What do I mean by this? The truth is, we all see problems differently. We bring our own experience, knowledge and intuition with us when we attempt to problem solve. This is NOT necessarily a bad thing… but it is crucial to be aware of this as you address problems.

When I was a working in desktop support, I had a coworker who had a sticker on his monitor with the phrase “Users Lie” strung across it - reminding himself that people don’t always tell you the truth when something doesn’t work. Harsh.

I think a better way to think about it is this: “people (including me!) don’t always know how to ask a question or how to explain their problem.”

Don’t assume you know all the variables to a problem. Don’t assume all involved parties see things the way you do. We all have different levels of technical literacy – a broken computer monitor might just mean the cable was loose, not actually broken. Maybe you misspelled a variable name you were referencing or there’s a syntax error in your code. Maybe you weren’t explaining your problem to someone as clearly as you thought you were.

In my example about code reading above, think about this:

Code reading line by line helps you understand what is a variable, what is an object, what is a function, method, etc. as you read it. It’s easy to make assumptions when you are first starting out. Using the wrong vocabulary when you explain your problem to another developer can make it harder for them to see your thought process or identify the issue at hand.

It’s important to consider how you’d fix something, try it, read documentation, google it, ask for help, ask to re-contextualize the scenario, ask for clarification, just a lot of questions!

Lastly…

BREAK THE RULES

I think the best programmers are the ones that try to break their code while they build it. At the very least, those who have the curiosity to try and break things will learn quicker and why certain conventions are adopted over others.

There is always more than one way to skin a cat. When I get my code in a functional state, I try to figure out ways to refactor and/or test arguments that my function might not be anticipating. If someone using my page types something in a form incorrectly, will my code account for that?

If I’m code drilling as practice, I try to solve the problem on my own and once I do, I always check to see how others did it if that’s an option. Learning to see how others think and attack the same problem you faced can help with your development journey.

Once you found your answer, don’t settle right away! Give yourself some time to see if you can improve your answer or find better ways of doing things. Use whatever tools you have at your disposal to deepen your understanding and comprehension. At the end of the day, keep coding every day and you will become a better developer!