Recently, I made the decision to seek a TA / tutoring position at my university's CS department. As I am currently in my final semester of graduate school, I only saw the positives of being a tutor:

1. Help others overcome struggles
2. Improve peer-review skills
3. Reinforce my own learning
4. Give back to academia, especially my alma mater

So far, tutoring has been an absolute joy (while the grading part is... tedious). As the semester has gone on, more and more students have been coming to me during my tutoring hours. I also frequently tutor by appointment, whenever I have free time during my day.

Before I continue, I want to be specific about the tutoring topics and what these students are learning. I'm the TA for the CS2200 course - Data Structures. This course is the third programming course in the CS curriculum (after CS1, CS2, and not counting math-courses). The curriculum revolves around C++, a language I have the utmost respect for (mostly out of fear). TA aside, I tutor any CS student who walks in - and it's almost entirely students from those first three classes seeking help; beginners, if you will.

A language like C++ can be absolutely DAUNTING for beginners, especially once objects come into play. But this post isn't about C++, because any language can be daunting for beginners. And from everything I have seen from tutoring, this post isn't even about programming languages.

Students that come in for tutoring sessions are typically (and predictably) coming in for help on their assignments. The assignments are written out as a page or two of specifications and requirements. Some come in asking specific questions in reference to a bug, while others just give off that 'completely lost' vibe. And since C++ is a compiled language, it can be easy to go from a working program, to throwing your laptop out the window in a few short lines of code.

The first question I always ask them is: "Does your program compile?"
Their answer is typically: "No", or the "Well it did yesterday, but then..."

This leads me to the first "P" of Learning How to Code:

Bonus points for using alliteration?
Almost always I see students trying to read through the entire assignment and tackle it as if it is one big monotonous block. They code and they code one line after the other thinking they are painting a masterpiece. As the saying goes: "to err is human", and that is never more true than when you start coding.

I challenge them to change their perspective: that they shouldn't look at their code or their program as a Picasso masterpiece. Instead, they should look at it as a jigsaw puzzle. I couldn't tell you where to start on creating a Picasso painting, but I know damn well how to put together a jigsaw puzzle.

I like this analogy because it helps them take a step back and see that all code really is, is just a series of instructions. If you modularize a large instruction set into smaller and smaller subsets you eventually get a bunch of manageable pieces, just like a jigsaw puzzle.

So I ask them to do multiple reads of an assignment's specifications. Then, when they have a good grasp of what is necessary, start breaking down the whole and implementing a little at a time. Writing a few lines of code, verifying it's validity, and repeating the process is a surefire way to increase efficiency and save you all that frustration when it comes time to fix those errors!

For new students in my tutoring, I like to go with a Bank Account example. I ask, how could you break the concept of a Bank Account down into manageable chunks? What could you implement and test, one at a time?

Alliteration again!?
Piggybacking off the first concept, 'Pen and Paper' is exactly what it sounds like. Writing down notes, drawing diagrams, visualizing instruction sets, and all manner of blueprinting are incredibly useful for clearing up the mind. Doing this not only adds to, and increases workflow, but it allows the programmer to take a step back and conceptualize their thoughts.

Personally, this one took me a while to figure out myself. Now as a tutor, it took me all of 2 days for me to start harping on students to get a pen and paper out. I noticed that when they would come in, they would only have their laptops and stare at them; they'd be banging their heads against a wall trying to code themselves out of their problems. I say, "What're you doing? Do you have a plan? No? Then why not draw one up instead of coding in circles?".

Similarly, I don't tutor by showing them my code, I get on a whiteboard and literally draw diagrams and pseudo code for them. I draw out what's needed and box out what can be separated out as a puzzle piece. I even convey to them that coding is barely even about coding - it's about problem solving. Solve the problem first, then code your solution. And... boom, transition!

I'll take 2/3 on the alliteration.

Question: "What's a programmers best friend?"
Answer 1: "Google!"
Answer 2: "Stack Overflow!"

We all solve problems everyday, be it life problems or code problems. I remember when I saw my first C++ compile-time error. It was like reading hieroglyphics, I had absolutely no idea how to interpret it. This was a real challenge for me to overcome, a problem I had to solve!

Leveraging the first two P's, Problem Solving seeks to close any loopholes that may come about. With the assumption that the programmer has broken down a large task into manageable smaller ones, and they have properly conceptualize how to implement a small task, then any further problems should now be in their own independent, manageable state. This is where programmer knowledge, or of course the beautiful internet come into play; time to solve that problem.

If the first two P's are not followed, then Problem Solving can become a chaotic mess; a place where one error follows another, which follows another, and another, and then you spill coffee on your laptop, etc. Only by breaking things down and understanding can this force future obstacles to become less obscure, with exponentially less influence.

The cliche, 'nobody knows everything', couldn't be more true than in tech. The internet is the information age that we live in. It's out there, use it! Of course, if you copy and paste code you don't understand then you're only doing yourself a disservice - this will come back to haunt you!

Coding is hard by default, it's rewiring our brains into a new way of thinking. Lectures and videos are great, but they just won't teach you the way real practice would. We learn better and retain more information when we struggle. I am a big believer in exposure, exposure, exposure. Difficult concepts aren't meant to be mastered in a 3 month semester - it takes time, practice, and a dedication to drive on.

Whether you come from a CS degree, bootcamp, or self-taught background, this bonus P may just be the most important one!