# The 3 Realizations That Made Me a Better Programmer

## It didn’t happen overnight

Nov 9 · 5 min read

I developed an interest in programming when I was a child — before I knew what programming really was. I learned HTML as a kid and built the most stereotypical ‘90s websites. I learned SQL as a teenager when I had a summer job in IT. After going to college and grad school way too many times, and after working for a few years, I went to a coding boot camp and learned some JavaScript and Ruby.

It took a few months for me to conceptualize what I had learned. It took over a year before I could build things independently.

# 1. Programming Is Not Really About Telling the Computer to Do X

This was a pretty big misunderstanding when I began learning. In my mind, I just needed to write a command, like , and everything would work out.

Of course, that’s not how we do it.

• Do to
• Get from
• Get from , and put it in
• Create in
• Create in , and make it do

… and so on.

I didn’t realize this until I started using code to solve actual problems.

Example: I pull a bunch of data from BigQuery and connect it to Data Studio. I make a nice bar graph with that data. Now, I need to do a custom sort of the parameters on the X axis, which are tied to dimensions in BigQuery. I could sort by ascending or descending with the click of a button, but that won’t fit my use case. I need to code my way out of this one.

In my mind, I’m thinking: .

Then I think to myself … that’s not enough. What do those X-axis values represent, and where do they come from? Let’s say they come from the dimension on .

I come up with something like:

`SELECT *,CASE  WHEN location = 'A' then 1  WHEN location = 'D' then 2  WHEN location = 'E' then 3  WHEN location = 'B' then 4  WHEN location = 'C' then 5  WHEN location = 'F' then 6 ELSE 0 END as SortOrderFROM `table001``

Now I can sort by SortOrder, which I defined, instead of by ascending or descending.

Other than the initial and , this piece of SQL is exactly what my brain imagined it should be. But it wasn’t as simple as . Sort what like this? Which dimension? Which table?

My first JavaScript project helped me come to a similar realization. I was pulling stats about Pokémon from the PokéAPI. Great — I got the stats. Now what? They’re not showing up anywhere except for in the console. Obviously. Because I didn’t put them where I thought I was putting them. I only programmed half of what I intended to program.

It sounds like common sense, but it’s only common sense if you understand exactly what you’re trying to accomplish. When you’re new to programming, it might take awhile to have a conceptual understanding of the problems you’re trying to solve.

# 2. We Write Code to Solve Problems

Of course, it’s hard to learn when you’re doing a prescriptive tutorial. You’re not solving a real problem. You’re following a set of instructions that, when followed correctly, produce a certain outcome. By design.

A nondeveloper could follow a well-written tutorial and produce a simple app, but if you were solving a problem that hadn’t been solved yet, there wouldn’t be any instructions to follow.

You might be doing something fun. Hopefully, you’ll create problems that need to be solved. But if you’re just doing guided tutorials, and you’re not sure how you would apply these exercises to actual problems, it’s going to take you awhile to grow.

The skills you learn should be transferrable. There’s no point in doing a tutorial if you can’t apply the same skills you’re practicing to a different scenario.

For that reason, all of the examples above should include the word because.

• Do to because …
• Get from because …
• Get from , and put it in because …
• Create in because …
• Create in , and make it do because …

Let’s say you learn to make a to-do list app. I did that once. What did I learn? I learned how to make a to-do list app. I didn’t learn how to use the same concepts to make apps that function in a similar way.

# 3. Pseudocode Helps With Algorithmic Thinking

I used to spend a lot of time in trial-and-error mode. If something didn’t work, I just tried it a bunch of different ways until (a) it finally worked, somehow, or (b) it didn’t work, and I ended up on Stack Overflow.

I always assumed it was my lack of understanding of the language I was using. In retrospect, it was actually a problem with algorithmic thinking. I wanted to get from and put it in . I wrote code that gets from nowhere and tries to put it in .

I realized that pseudocode is a great way to jump-start the process of thinking algorithmically. Brayden Copley provides a solid example of pseudocode with his FizzBuzz solution.

The first time I tried FizzBuzz, I sat there thinking about the syntax of Ruby before I even thought about how to order the statements I’d eventually write. I Googled things like “how to write conditional statements in Ruby” and “Ruby divisible by,” but I was focusing on the part that didn’t really matter. The part that DID matter was how to get from point A to point B in a way that actually worked.

FizzBuzz is easy. Many real-world problems are not.

Pseudocoding is a great way to think through complex problems without worrying about the language you’re using.

My initial inability to think algorithmically was easily overcome. I stopped focusing on which language to learn next, and I started focusing on how to think my way out of a problem.

## It has been a year since I began studying JavaScript and Ruby.

Now, I work as a technical writer. I read code more often than I write it. When I do write it, it’s usually a small snippet for a specific purpose. I don’t often build entire apps the way I did when I was developing my portfolio.

But now, I use code to solve problems. I know exactly what I’m trying to accomplish with each line of code that I write. When I get stuck on something, I pseudocode it until I find a solution that makes sense.

I continue to learn each day. While I focus most of my efforts on technical writing, I’m confident that these realizations will help me grow as a developer.

Written by