Photo by Marc Mueller on Unsplash

Insights: My Journey Into Programming

One year ago, I began my journey into programming. What surprised me the most was that some of my biggest challenges along the way were psychological. Here, I share my experiences below with the hope that they may help just one person.

Lesson #1: Finally knowing how to code can be a “false summit.” Don’t get discouraged; keep learning.

For those of you who don’t hike, Wikipedia does an excellent job of defining what a “false summit” is:

a false summit is a peak that appears to be the pinnacle of the mountain but upon reaching, it turns out the summit is higher. False peaks can have significant effects on climber’s psychological state by inducing feelings of dashed hopes or even failure.

Once I felt confident with my coding abilities, the first thing I wanted to do was write an algorithm to auto-trade stocks. I spent hours tinkering with the authorization phase of a trading platform’s API, only to get extremely discouraged. Turns out, knowing how to code is only a piece of building anything useful—solutions to real-world problems often lie outside your scope of knowledge. I realized I had to get used to being outside my comfort zone.

Lesson #2: You don’t always have to be coding. Go explore.

The amount of hours I spend writing code is minimal.

This one stems from #1 above. I would say that most of my time is spent on learning different APIs & tools or brainstorming how to solve different problems.

The act of coding itself is insubstantial, it’s simply a medium for manifesting ideas — if the idea is not well thought-out, the code will reflect this.

Lesson #3: Coding is not for the weak. An obsession to persevere is required.

A lot can go wrong. A semi-colon in otherwise perfect code can break everything.

Personally, my toughest challenge was getting used to throwing away hours or sometimes days of work. This would happen for a lot of reasons:

  1. The problem wasn’t what I thought it was
  2. The solution I came up with was too complex
  3. The solution was outright wrong
  4. I knew I could do better- less code, fewer chances for errors, etc.

There were many times I would get up from my computer and walk away angry. Occasionally, I fought back tears.

If you’re sitting at your desk frustrated at why your code won’t run or why the output is not what you expected, take a break. Go for a short walk. Sometimes you just need to step away and clear your head. Even the best programmers encounter these problems. When you get back, go back to the basics; print everything and assume nothing.

Today, I can proudly say that I embrace throwing away work (when necessary). Often, when solving new problems I find myself writing code to simply prove out an idea. Focusing on the problem itself leads to more meaningful code in the long run. Rarely is code written once and only once.

The creation process is supposed to be constantly evolving. Try not to get emotional about the specifics of what you wrote; throwing something away or changing it does not mean your first version was a waste of time.

Lesson #4: Before writing a single line of code, look to see if someone else has already done it.

There are so many great open source projects and libraries out there. Many of those are already battled-tested by hundreds of users (or even companies)! Embrace them. Building everything on your own from scratch can be wasteful. It’s important to become familiar with development landscape.

That being said, before using anyone else’s tool or library, I recommend making sure your foundational skills for that resource exist (i.e. don’t try to use a tool for which you don’t understand any of the code/logic behind it).


Share your experiences below! What were your biggest challenges when you were learning how to code? Thanks for reading; hit the ❤ if this article helped you.