Rookie Mistakes: An Adventure in Programming
or: mistakes I made so you don’t have to
Feature creep. Off-by-one errors. Caching silliness. Feature creep. Git struggles. Referencing cursors improperly. And did I mention feature creep?
If you’re just starting to program, these may sound like gibberish—but stick with me now and I’ll give you a hand.
My first semester of Computer Science was a great one. I took the (in)famous CS50, did a bunch of cool problem sets, and made a neat little final project. But like any beginner, I had my fair share of high and low level issues. While CS50 taught me a ton of things, the class was more about learning than warning.
So let’s get to learning from warning!
But first, a warning of my own: I’m not a coding wizard or seasoned professional; I’m sharing tips and tricks that have worked for me.
Or: How to Stop Worrying and Ship Your Code
Without a doubt, feature creep was the biggest high-level (read: conceptual, not technical) problem I ran into. In short, feature creep is when you just keep adding new awesome features to a project. While being ambitious is great, it loses its charm when it leaves you with a half-baked, half-finished project rather than a totally finished project with fewer features.
This shouldn’t hamper your ambition, though: put your ideas down on a sticky note, write it down in Evernote, or (my personal favorite) make a Trello board for it. I’ve included a sample one I just made up below, but I encourage you to create one that works for your personal workflow. It might seem like overkill, but it keeps you (and your ideas) in check.
This is actually something of a trope in the tech world: “stay focused and keep shipping.” Seriously, even the Zuck says it!
Stick to your guns. Once you make a plan, stick to it. Don’t move anything from your “future” category to your “next version” one until the features list is empty and your code works to do something—even if that something isn’t the final version of your program in all its glory. (There’s nothing embarrassing about pushing a version 0.1; Rome wasn’t built in a day, and, in all probability, your dream project won’t be either.)
At the very beginning, this may be overkill: you don’t need a Trello board to write a “hello world” program. As you start to do more free-form work and—dare I suggest—projects of your own, having a solid workflow can work wonders.
Have a brilliant idea out of the blue? Great. Jot it down, then forget about it until you’re done with your immediate to-do list.
Or: How to React to Technical Problems
OK, I lied. I’m not going to literally teach you how to avoid things like off-by-one errors, pointer referencing issues, and caching complications. In fact, if you don’t know what what those are, I’m not even going to tell you about them.
Why? Because another big thing I’ve learned is that there is no cheat sheet in programming: it may sound clichéd, but the way I’ve learned best is through the things that made me want to hit my head into my desk in frustration.
You’re going to have to trust me on this, though: if there were a hundred-point list of things not to do when programming, I’d give it to you in a heartbeat. It’s the same issue as with learning a language, or mathematics, or whatever: teaching a bunch of facts helps a little, but what you really need is to learn the process.
With programming, you’re bound to be stumped. It doesn’t matter if you’re a beginner or an expert: everyone gets stumped sometimes. (You’ll probably get better at working around problems, though. Just keep at it and see.)
That can be really annoying, but it’s also your best troubleshooting tool. You always know the issue is right in front of you.
And don’t get mad, get even: if your program isn’t doing what you want it to, don’t let it win. Figure that sucker out. You can do it. Yes, really.
Easier Said Than Done? Nah.
Something amazing that I’ve found while struggling with code is the welcoming vibe and general vastness of programming communities. There are whole websites dedicated to sharing experience, code, and advice. More so than any other field I’ve seen, other programmers want you—yes, you—to succeed and write great code. Reach out and you shall be rewarded.
As with all communities, you might run into a bad seed. If you’re really trying and they’re being a jerk towards you, that’s their problem, not yours. Don’t let someone nasty discourage you.
This brings me to an important caveat: just because you may be able to Google (or StackOverflow) your way past a problem doesn’t mean that you should.
It’s extremely tempting to run into a problem, google a fix, copy it, and move on — but the odds of you remembering how “you” fixed it an hour later are pretty slim. On the flip side, you’ll never forget how to fix a bug that took hours of frustration to fix all on your lonesome.
If it’s a small problem, look long and hard at your code before asking for help, because it could be something super simple. Reviewing your code works particularly well with a debugger. If that doesn’t help, try sleeping on it. (I’ve found that the hardest, most daunting obstacles I’ve come up against are really simple when I come back to them a day or two later.)
If you do end up using outside resources (friends, internet, etc.), that’s totally fine: just don’t follow advice or copy code that doesn’t make sense to you. You’re just cheating yourself and putting off the actual conceptual problem. I recommend going through the
And you shouldn’t be ashamed of running into a conceptual problem, because a problem is only a problem if you don’t figure it out. (P.S., you totally can. I felt stupid a lot of times this past semester, but I pulled through A-OK.)
Learning to program has been one of the most fun and interesting things I’ve done in the past few years. I’ve spent hours upon hours frustrated at my code and, by extension, myself. Sometimes when you find a solution you feel silly, while other times you feel like the smartest person on earth. On net, writing code is a great feeling.
Warning: it really gets addictive once you get into the swing of it. You can do amazing things with your coding knowledge—even as an advanced-ish beginner, like I am.
So whether you’re starting to program, or already started, or started and gave up before: give it another shot. The barrier to entry can be high, but the satisfaction and payoff will make up for it. I promise.