If you’re like me, the world of coding might seem at first like the final frontier of STEM (or the bewildering love child of algebra and the Voynich manuscript).
If you’re thinking of learning to code, but aren’t sure if you’ve got what it takes to get started, you’ve come to the right place. (Welcome — there will be a test after this.)
I’m nearly 30, a humanities nerd, and am terrible at math — three factors I always assumed precluded me from ever learning to code. Despite this, last year, I rolled up my sleeves and did an academic 180, taking a leave of absence from my grad school program and enrolling in an introductory Python course.
By the semester’s end, I loved that programming course so much that I’m now a computer science major, and want to become a developer.
Here are the biggest mistakes I made last semester, and what I learned from them.
1. Not running code before submitting it
[Louder for the people in the back]: Always 👏 run 👏 your 👏 code 👏 before 👏 submitting!
You never know when a minute detail — even a single character — will cause an error in your code.
Last semester, I made a small change to a ‘while’ loop that I thought would a) perfect the program and b) not require testing, since the change was so small, and my program had already run without a hitch that morning.
That little change was supposed to be the cherry on top. The pièce de résistance. The “unnecessary-but-I’ll-do-it-anyway-because-why-not” detail that would make the program be *chef’s kiss* perfection. Feeling confident about the project on the whole, I submitted my project with the update and didn’t give it a second thought.
Had I run the program after making that change, I would have known that the program didn’t run anymore. The little change I made rendered that program inoperable, and I got a 0 on the assignment.
Don’t be like me. Check your code, friends.
2. Starting projects at the last minute
Bugs don’t work on our schedules. I learned that the hard way, spending countless nights staring, in quiet desperation, at red error messages on my laptop screen, willing the errors to magically fix themselves by the 9 am due date the next day.
I used to be a journalist, so I’m used to deadlines. What I wasn’t used to was troubleshooting bugs — a process which could take a couple minutes, a few hours, or even a couple days. It didn’t take long for me to realize that the best time to start a coding project is now. Bottom line: start early and leave time to troubleshoot.
3. Writing code before the pseudocode
Just like essay writing, coding is a lot easier when you make an outline first. That’s where pseudocode comes in.
Pseudocode allows you to describe what you want your program to do, without actually writing any code. (Examples of pseudocode include: “get user’s first name”, “call main function”, and “return value”, etc.)
Pseudocode 👏 is 👏 your 👏 friend. It’s easier to manipulate and reorganize than actual code. Throughout the semester, I found that my code was consistently neater and less buggy when I wrote pseudocode first.
My takeaway: write pseudocode first, then code. It saved me a ton of time.
4. Not doing practice exercises
My professor tried to warn us about this one — he told us from the start to do the practice exercises. Unfortunately, I’m a jaded grad student, and my approach to schoolwork is “work smarter, not harder”. In this case, I thought I was working “smarter” by skipping the practice exercises (which weren’t required) and focusing on the assignments instead.
This choice deprived me of an opportunity to deepen my understanding of the programming language. By the time I got to the assignment, I found that I had a tenuous-at-best understanding of the mechanisms of that week’s topic, and would often struggle to debug my code. It didn’t save me time to skip the practice exercises; if anything, it wasted more than it saved.
Long story short: you have to write code to learn how to write code. Like any language, the more you use a programming language, the better you become at it.
5. Being afraid to break your code
This was the hardest lesson for me to learn this semester. More often than not, when I got my code to work, I held my breath, hit ‘Save’, and submitted it. My instincts screamed, “Don’t touch it! It works well enough!”
Trying to break your code — i.e., entering invalid input — is an awesome catch-most tool for bugs you may have missed. In my case, it sometimes felt like shining a flashlight into a dank basement — finding a lot of bugs that I’d rather not know about. It can feel like blowing on a house of cards, but it’s a great way to learn.
At the end of the day: if you’re thinking of learning to code, do it. You’ll only regret not trying it sooner. No one likes making mistakes, but I’m glad I made these. They pushed me out of my comfort zone, and shaped me into a better programmer.