Pseudo-code, humor, and the art of Googling

The most important things I’ve learned about programming so far have nothing to do with writing code. Rather, they are the things that happen before and in-between the code writing.

When I’m first given a problem or assignment to work through, my gut reaction is to dive right in to coding or asking questions on Google. It can seem counter-productive to do anything else. However, I’ve quickly realized this is not true.

The generals have a saying:
“Rather than make the first move
it is better to wait and see.
Rather than advance an inch
it is better to retreat a yard.” (Tao Te Ching, №69)

I’ve never been in battle, but I think I understand the idea in the quote above.

In battle, it might seem like moving forward is the most productive thing you could do, and that to retreat is to give ground to the enemy. To give them the advantage. However, this is not necessarily the case.

When coding, I find it helps to take a few steps back and see the big picture. Writing pseudo-code and thinking through my problem with pencil and paper sets me up for more thoughtful questions and insight. It actually saves me time in the long run.

Writing in pseudo-code

When we were first encouraged to do this, I didn’t see the point. Maybe this was because we were working on simpler problems that didn’t require extensive pseudo-code.

But, as the assignments got more complicated, this approach became invaluable. It gives me a chance to flesh out the problem from beginning to end.

// My pseudo-code process:// 1. Read over the problem.// 2. Write out in long form what I’m trying to accomplish, even if I repeat verbatim parts of the question. Where am I starting? Where am I going? What path am I taking? What side-paths may I want to take along the way? What tools do I need? What kind of functionality?// 3. Go back over my notes (from #2) and add in sub-thoughts to further flesh out the process and include questions I have for myself (or others, or Google) I’ll likely ask along the way.// 4. Start coding.// 5. Test each baby-step in the console.// 6. Repeat step five.// 7. Repeat step five. // 8. Repeat step five. [...]

Think first, then Google

Another gut reaction of mine was to ask questions on Google immediately. We’ve been told that 80–90% (or more) of a developer’s day is spent Googling how to do things. So why would I not do the same?

I cannot attest to this, not being a full-fledged developer yet. But what I am realizing is that there are ways of Googling that are helpful to me, and some that are actually counter-productive.

I’m finding that when I turn to Google first, a part of my brain is actually shutting down.

If I turn to Google before thinking, I’m not actually learning to think like a programmer.

What I mean is this: if I don’t take time to write pseudo-code and think through the details of the project, I’ll end up Googling in an inefficient way. I’ll end up wasting time.

In the short-term — even though writing psuedo-code might feel like I’m taking two steps back to go one-step forward — it actually is saving time and headaches along the way. It helps me be more thoughtful about the questions I ask on Google. I’ll be more likely to understand what I’m asking, and why I’m asking it.

console.log(“everything”)

This is huge. I didn’t realize it at first, but this saves an enormous amount of time and energy, too. It gives you a chance to test each idea in Chrome’s Developer Tools to see if it actually works, and if there are any errors or bugs to work out.

Failure is an opportunity. (№79)

This is where I think of the phrase: “Failure is an opportunity.” The console is unforgiving.

But because of that, it is also my best friend. It doesn’t beat around the bush and tell me my code looks great, that I’m handsome and doing a great job, and so on.

If something’s broken, the console lets me know. It doesn’t praise or berate me. It just tells it to me like it is. It keeps me humble and keeps me moving.

If psuedo-code helped me break the process down into baby-steps, the console helps me break it down into micro-steps.

For example, say one of my baby steps is to create a function that replaces the innerHTML of an element based on its id.

The console gives me the ability to find out if my syntax is correct when I use jQuery to target that id, if I’m actually capturing the innerHTML, and if everything is properly formatted when I run the function. All without changing a single line of code.

The console gives me the chance to fail, and learn from my mistakes. It helps keep things moving, and target where I’m specifically getting stuck. It helps me ask better questions.

Have a Sense of Humor

Programming can be frustrating! And I’m just a beginner at it. But if I can have a sense of humor along the way, it helps relieve the tension that tends to get me stuck.

I try to write humorous things in my pseudo-code, even if I’m making fun of myself, because laughing at myself helps relieve the tension, and helps keep me grounded.

If frustration gets me stuck, humor is a way of getting unstuck. It helps keep the code flowing.

function letsConnect(yes) {
  if (yes === true) {
    console.log("linkedIn");
    console.log("Twitter");
  } else {
    console.log("thanks for reading!");
  }
}