Rubiks Cube

How to code logically?

Understanding programming logic with a logical approach.


As a course creator naturally get a lot of questions about programming with Pine Script. One question I seem to receive a lot is around how to write good code? Or at least somewhere in that realm. Below I will share with you one of my students questions, and the elaborate response I have prepared, which in turn inspired me to write this article.

The Question

Hi Paul

I have been struggling to process the info from lecture 33 until now (lecture 39). I am battling with the logical way to write and position the code. As an instance with lecture 38 and building the counter, I understand what it is doing, but I am battling to put that into the logic of how to write that. It was also the same for lecture 33 when I tried to do some of my own indicators, or just trying to add 2 SMA’s and have a crossover / under alert

Do you have any advice on how to get a better logical understanding?


The Answer.


Writing code is a bit of an art. Just like there are a lot of ways to paint a tree, there are also a lot of ways to code logic. On top of the multiple ways to paint a tree, you also have the choice to put that tree anywhere on your canvas! Similar logic follows with code!

Bob Ross Painting Happy Trees 🙂

Now I can’t draw a 1:1 analogy with art and code because code does require certain fundamental structures/syntax in order to compile correctly.  (Sorry you can’t become the Jackson Pollock of Pine Script lol.)

Jackson Pinescript

That being said, I’m fully aware of the agony resulting from a perfectly compiled script that just doesn’t work the way you intend. Whatever the cause of this logical blunder, it stands to reason that you need to FIND the error and CORRECT it. And on top of fixing errors quickly, it can also be a very painful process improving or adapting code or in the very least just trying to understand what the code is doing.

Bottom line… Understanding the code is important if you want to be a programmer. Just like understanding vehicles is important if you want to be a mechanic.

So here are some steps to help you improve.

Be patient and practice.

This is the most obvious thing you can do and I know it’s cliche. But I won’t leave it out because it’s important to understand that the struggle is real and will continue to be real for a while. So it’s important to have realistic expectations. 

What is reality???

There’s no finish line and there is no formal measurement of how long it should take you to get from point A to point B. I say this, because it’s really disappointing to find yourself still struggling after x amount time all the while your peers seem to be excelling and you just read another article titled something like “How I Went From Homeless To Senior Software Engineer At Google In X Months” — While most of these articles are just clickbait, some of them are true; but they are the outliers not the mean. 

The point is to focus on yourself, don’t compare yourself with others and trust the process.
The point is to focus on yourself, don’t compare yourself with others and trust the process.

Follow a Process

Thinking logically requires focus.

Focus requires concentration.

Concentration requires coffee…. Making coffee requires a process. 

Now the process of making coffee is pretty simple right? Well, I guess that depends on who you ask… because there are a few different methods. Considering we skip ahead past the farming, drying, and roasting processes. We typically find ourselves brewing our coffee the same way every day. That way could be a Kuerig, French press, drip, cowboy, takeout and so on.

The point here is that we don’t even THINK about the process, we just follow it and voila our coffee is ready. This autonomic way of brewing our coffee everyday enables us to focus on other things, like looking for our keys, finding a fresh pair of underwear… or writing good code.

Whatever it may be, our minds are not burdened with the process, because we have a process (Granted you’ve done it more than once).

Whatever it may be, our minds are not burdened with the process, because we have a process…

A paragraph ago.

Break Complex things down into simple steps

The sooner you start thinking in terms of processes, the sooner you will start thinking in terms of steps. And your ability to break complex things down into simple steps will translate into your ability to be a great programmer.

Cool. But how do I follow a process if I don’t even know a process? 

Good question.

Like brewing coffee, there is more than one process for developing code you can understand. It just depends on what stage of development you are in.

For simplicity, I will break up development into two stages. Each stage contains its own methods and processes.  

  • Stage 0: Blank slate stage. New development and code improvement happens here.
  • Stage 1: Debug Stage. This is where we spend the most time. 🙂

Stage 0: Blank Slate Stage.

XKCD Good Code
XKCD Good Code

If you’re just starting a new script here’s some steps you should take to ensure that your code remains readable and logical.

  1. Make some coffee… Or some tea. I’m actually making tea right now.
    • Refer to beginning of this section for tips.
  2. Write your logic down or visualize it if you’ve got a brain like Nikola Tesla.
    • You can make flowcharts.
    • You can use pen and paper.
    • The idea is to not waste time writing code until you’ve gone through this process at least once. Some things are not very clear, especially if you don’t fully understand the system or if you don’t fully understand how you should approach a certain challenge. There might be a bunch of ways to program your logic and if you’re like me, you’re going to warp your brain trying to mentally visualize each different way you could program this all while weighing trade offs. Because there will always be trade offs.
    • Planning ahead is good, but too much planning can paralyze you. So get something written down and build that. You can always come back later and modify it…
  3. Follow a convention.
  4. Follow the FAQ.
    • Chances are, you’re not the first person with this question. The pine coders website has a plethora of frequently asked questions and tips on their website. I use this a lot. You should too.
  5. Plot your results and spot check to make sure they are meeting your expectations. If not, you have a logical error and need to debug.
    • Debugging in Pine is kind of funny at first since the Pine editor does not have a built in Pine Debugger nor does it have an intuitive print()/console.log() function found in Python and JavaScript.
    • Don’t be dismayed, just look here and here and you will find lots of techniques for debugging. I also cover this process below.
  6. Refactor, tidy things up and add comments where needed.

Stage 1: Debug Stage.

XKCD Debugging
XKCD Debugging
  1. Make another cup of whatever you’re drinking. 
  2. Read the error log. PAY ATTENTION!
    • Assuming there is a syntax/runtime error… If it’s a logical error then you can skip this step because a logical error cannot be detected by the compiler and interpreter.
    • Click the first error that is printed. Every error after that one has been caused by the first one. This should bring you to the line that contains that error.
    • Pay attention to what the error log is saying. It may not make sense at first, but after a while you will know specific errors before you even see your error
      • In most cases it is a type error so check to make sure the type matches the expected type. (Helpful diagram found here)
      • It could be a syntax error so pay attention to all commas and parentheses and spaces etc.
      • It could be a server error, maybe your internet is disconnected? Is your computer plugged in? 😛
      • Scrutinize every character in your buggy statement. It pays to be detail oriented here. 
  3. Plot everything.
    • Split any multi condition statement into separate statements.
    • Use the data window. The data window is your friend.
  4. Start from the top. Talk out loud, and walk through the logic.
  5. Ask for help.

Bottom line

Be patient, follow a process and break your code down into bite size steps.

Leave a Reply