Learning Programming

[Guest]

Hey, I'm, I guess, an itermediate programmer and I have a question about
learning any programming language. I understand that as a programmer you're
going to probably constantly be re-writing code and the best method would be
to save a template or other etc. I also know that it's ok to use other
people's code to help you do something, but wouldn't it be best to re-type
the code or study it until YOU learn how to do it and you actually understand
why you would use that code? This is currently my method and I'm fixing to
attend a college to study computer science and I was wanting to know this
ahead of time so I wouldn't waste time re-typing the code or I could study it
if needed.

 

[Scott M.]

I agree that while learning the language in question, typing from scratch is
a good practice, but consider this:

As long as you know that the code you are copying is correct, you can learn
the same (if not more) by reverse engineering what you've copied.

I learned to program in the 80's by taking the code from the video games I
played (written in BASIC) and searching for all occurences of the number 3
in that code. When I found a 3, I changed it to a 10. Why? Because I
wanted the game to give me 10 lives, rather than 3. By making changes to
existing code, I was able to figure out what those lines of code did.

Also consider that the first rule of professional programmers is: "Don't
type what you can steal!"

Good luck!

 

[tomb]

You may learn as you get deeper into this that much of the code that is
now included as libraries for a development environment actually were
things that the programmer had to code himself. So, in effect, if you
are utilizing these libraries then you are using someone else's code.
In C++ you can read through much of that code and learn from it.
Understanding what it is doing is extremely valuable.
To take the math example from school, we all learn how to add, subtract,
multiply and divide, then we turn around and use a calculator. But we
understand enough about what the calculator is doing that we can spot
apparent errors. That's what programming is like - understand what
these libraries and components are doing, then let them do the grunt
work for you.
Many times, I'll set up generic forms that I will include in new
projects and then modify for the actual need. But all my forms have to
have a small set of basic functionality. Class modules don't always
follow such an easy mold because they are more application specific.

Tom

 

[richardv2]

As a programming teacher, I've seen just about everything mentioned
here. What I'd like to say is that PROGRAMMERS WRITE CODE! If you can
write the code, then you understand the principle.

What I often do is teach the principle, then give a word problem
program (Write a program where the user enters numbers in each of two
text boxes, and when the "Compute" button is pressed, the sum of the
numbers shows up in a third text box.)
(A week or two later, I add "and check each input check box for valid
numeric input - show error message if either/boxes invalid)

This forces the student to convert an idea into code. I generally set
up ten to fifteen such word problems for a class. It bugs the students
at first, because the teacher can talk/teach for hours, but often the
student, when faced with writing code, is totally lost and can't seem
to get started. It is a process that takes practice. Lacking a teacher
or programmer friend who can give you some problems, make up your own.

Invent a program that uses what you just learned and try to write the
code. Or find a text that word-problem-type challenges at the end of
the chapter.

My experience with students typing in good code from the book has been
horrible! It might as well be a typing class - They don't get it!
Students who only type code don't read it, don't understand it and
can't even write the same code 10 minutes later.

Reading to understand and picking apart each section of code is good.

All ways of learning have value, but in my experience, solving word
problems is one of the most efficient, fast ways to gain mastery of
programming.

 

[Cor Ligthert [MVP]]

Michael,

I find this a very nice thread, all three contributors add something in what
I completely agree.

To add a little bit. There is so much intellisence now, that typing would
not help you. There are so many things where I don't know the exact property
or whatever for. A simple thing: I often have without intellisence a problem
if it the length of something is a "count" or a "length".

To start typing an "Hello World" program is of course one thing you should
do because otherwise you even don't know the features which help you typing.

Just my 2 eurocents

Cor

 

[tomb]

Well said!

T

As a programming teacher, I've seen just about everything mentioned
here. What I'd like to say is that PROGRAMMERS WRITE CODE! If you can
write the code, then you understand the principle.

What I often do is teach the principle, then give a word problem
program (Write a program where the user enters numbers in each of two
text boxes, and when the "Compute" button is pressed, the sum of the
numbers shows up in a third text box.)
(A week or two later, I add "and check each input check box for valid
numeric input - show error message if either/boxes invalid)

This forces the student to convert an idea into code. I generally set
up ten to fifteen such word problems for a class. It bugs the students
at first, because the teacher can talk/teach for hours, but often the
student, when faced with writing code, is totally lost and can't seem
to get started. It is a process that takes practice. Lacking a teacher
or programmer friend who can give you some problems, make up your own.

Invent a program that uses what you just learned and try to write the
code. Or find a text that word-problem-type challenges at the end of
the chapter.

My experience with students typing in good code from the book has been
horrible! It might as well be a typing class - They don't get it!
Students who only type code don't read it, don't understand it and
can't even write the same code 10 minutes later.

Reading to understand and picking apart each section of code is good.

All ways of learning have value, but in my experience, solving word
problems is one of the most efficient, fast ways to gain mastery of
programming.


Michael wrote:

 

[GhostInAK]

Hello richardv2,

I disagree. As a professional programmer I can say with authority that programmers
do not write code. Idiots straight out of college write code. Programmers
solve problems. It may seem here like I am splitting hairs, but I'm not.
I've known many so-called programmers that couldn't solve a simple business
problem. They could however take somebody else's solution and bang out code.
This type of fill-in-the-blank programming isn't helpful in the least.
This kind of mentality is the #1 reason I have new hires either fired or
transferred.

Instead of teaching people how to write code.. our educational system would
be doing them, and real programmers, a great service in teaching people how
to think for themselves, how to solve problems.

Second.. A programmer doesn't write code. A programmer drinks beer.. A programmer
reads documentation.. A programmer doodles in a notebook. Too many times
do I see a code monkey (I can't even call them programmers) get an assignment
and 10 minutes later they are at their desk bangin away at the keyboard.
How is one supposed to think if they are typing? How is one supposed to
design a system in code if they haven't even designed it in English yet?
It's madness, I say! MADNESS! So.. get your assignment.. grab a notebook
and pen.. go to your local pub and down a pint.. desgn the system on paper
and solve yer problems in ENGLISH. Once you have done that then, AND ONLY
THEN, is it ok to go back to your desk and write code. The point of this
rant is that Programmers spend at most 20% of their time writing code. The
rest is spent solving problems at a location where the most advanced peice
of technology is a juke box.

-Boo

 

[Guest]

i know what you mean!
i used to work for a small software house, where, if i was writing code the
secretary would never interrupt me, but if i was thinking - trying to come up
with a solution - she would start rabbiting about the weather or whatever -
because i wasnt doing anything - a good reason for going down the pub!