The 3 Realizations That Made Me a Better Programmer
It didn’t happen overnight
It took a few months for me to conceptualize what I had learned. It took over a year before I could build things independently.
I had a few helpful realizations along the way.
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
do X, and everything would work out.
Of course, that’s not how we do it.
Instead, I need to:
Y, and put it in
Y, 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:
sort order on x axis: A, D, E, B, C, F.
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
location dimension on
I come up with something like:
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
END as SortOrder
Now I can sort by SortOrder, which I defined, instead of by ascending or descending.
Other than the initial
END, this piece of SQL is exactly what my brain imagined it should be. But it wasn’t as simple as
sort it like this: ADEBCF. Sort what like this? Which dimension? Which table?
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.
Y, and put it in
Y, and make it do
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
Y and put it in
Z. I wrote code that gets
Z from nowhere and tries to put it in
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.
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.