32.2. Best Practices: Learning To Code¶
32.2.1. Traits of Good Programmers¶
Curious. Good communicator. Creative. Detail-oriented. Persistent. Problem solver.
These are some traits that successful computer programmers share. People come to computer programming from all different walks of life and previous job experiences. But the things they have in common are that they like to solve problems. They can both imagine (or invent) the "big picture" as well as pay attention to the "little details". They can express their ideas and listen attentively to the ideas of others. Finally, they are persistent--they don't give up!
As you'll soon discover, coding is not easy. It is interesting and often fun (especially as you get more experienced in it), but it is rarely easy. You'll often run into difficulties that you need to work through and solve more or less on your own. So while we'd like to say that "anyone can learn to code", it is more accurate to say that "anyone who is willing to work hard and persist through difficulties can code."
Yes, there is homework, which consists of prep work, exercises, studios, and assignments.
Only the assignments count toward your final grade.
You do not have to do the ungraded homework, but you absolutely SHOULD.
32.2.2. Practice Makes Perfect¶
I hear, and I forget. I see, and I remember. I do, and I understand. - Chinese Proverb
Experience is definitely the best teacher. You could read pages and pages
for loops, which will give you a handle on the vocabulary. However,
until you actually construct your first working loop, your understanding will
Effort = Outcome
Let's take a look at a sample coding task: "Prompt the user to enter a number, then print 'Even' if it is divisible by 2, otherwise print 'Odd'."
Now let's take a look at an imaginary student's attempt at solving this problem:
1. 2. 3. 4. 5.
Hmmm. A blank answer space. What might be the reason?
The student did not understand how to solve the problem.
The student knew how to solve the problem and decided to skip the task.
The student tried to solve the problem, could not get the program to work, so deleted the code.
The student ran out of time when trying to complete the prep work before class.
From a teacher's perspective, ANY of these reasons could be valid, and we have no way of determining which is true. This prevents us from knowing how to best help the student. Where would we begin?
For the student, a blank response provides no benefit because the necessary practice was either ignored or incomplete. Students gain only as much as they put in. SO:
Even if you have no clue how to approach a task, MAKE AN ATTEMPT ANYWAY, then ask questions.
If you know how to solve the problem, COMPLETE THE TASK ANYWAY, because practice makes better. Also, you could use your code to help answer a classmate's question.
If you tried to solve the problem, but your code did not work, DO NOT DELETE YOUR ATTEMPT. Ask a question. Showing your work to your teacher, TA or classmates will give them a clear idea about your thought process.
If you ran out of time, GO BACK AND FILL IN THE BLANKS LATER. Practice makes better. If you neglect one set of skills, then the tasks that come later and depend on those skills will be more difficult.
32.2.3. Job Success¶
Imagine you land a sweet tech job, and on your first day your boss says to you, "Implement a recursive algorithm to flatten our data structure." If your entire prep for this job was reading with very little coding, you might understand each individual word, but actually accomplishing the task would be a disaster.
Now imagine your prep involved using recursion and constructing algorithms over and over again. You would not only understand the words, but also have a strong idea of how to convert those words into working code.
32.2.4. Best Practices¶
Here are some bits of advice:
DO try every exercise, studio and practice problem.
Repeated practice helps master the basic syntax quirks for a given programming language.
DO experiment. Once your code correctly solves the given task, feel free to tweak it. Great fun can be had if you ask, "What if I try ____," and then go and do just that. For example, if a problem asks you to sort a list alphabetically, can you order it from z to a instead?
ASK FOR HELP when you get stuck. We've all been there, and there is no shame in seeking advice. Use your instructors, TAs, classmates, Stack Overflow, and Google as the brilliant resources they are.
The only "dumb questions" are the ones that are not asked.
The rubber duck method works. Sometimes just describing a coding problem out loud (to your screen, a co-worker, the wall, or a rubber duck) sparks an idea about how to solve it.
DO NOT copy/paste answers. There are plenty of websites where you can find complete code posted. A simple copy/paste into the assignment box will give you a correct result, but you have completely skipped your learning opportunity.
DO make a running list of things you've learned and watch it grow each class.
And don't forget:
Learning takes work, and you need the practice. Do your homework.