[Tutor] Learning to program, not code.

[Dave Angel]

On 12/20/2014 08:16 PM, Brandon Dorsey wrote:
>>
>> I'm 28 years old, currently unemployed and not in school until fall of
>> 2015 as a junior.  I picked up python a little under a year ago, with the
>> hopes that I could make a career out of programming - when I finish school
>> that is.  So, as of right now you could say it's a hobby, however, I
>> figured that I would jump the gun and learn it now, on my own, with widely
>> available resources we have today.  Currently, I have a solid foundation of
>> how data structures and how OOP works, but the problem lies within having
>> analysis paralysis.  I have a tendency to over analyze everything, and with
>> programming - as we all know - there are a million ways to accomplish the
>> same task.
>>

Why do you quote your own remarks, instead of just writing them?  And 
why were they at the beginning of the message instead of following the 
context you were actually quoting?

Now that I've figured out which part of the message was yours, I can 
respond.

You don't say what your major is, nor what you have been actually doing 
to develop your skill at Python.  My guess is that you're picking 
too-ambitious tasks, and that you have not actually worked through the 
beginning problems of whatever tutorial you've worked on.  There's a 
reason my college required homework to be done and turned in, in most 
classes, at the more elementary levels.

It's easy to think you know more than you do,  I don't say that to 
offend, but to try to help you get perspective.  If you've been jumping 
ahead, perhaps that's the best way for you to learn, but it's not for 
everyone.

Pick a simpler problem, and fully chase it down.  Do NOT try to get the 
perfect algorithm, try to get a complete working implementation of the 
entire problem.  Analysis is fine, but start by decomposing the problem 
into pieces you can solve exactly, then plug them together to make up a 
complete program.

And if you've picked the right boundaries for the decomposition, you 
could then go back and optimize individual pieces, in various ways.  But 
for many problems, maybe even most, it just doesn't matter.  In real 
life, you'll find that there are just a few places where things have to 
be reworked for performance, and until you've got a lot of experience, 
you'll always guess wrong what those will be.  Once you have a lot of 
experience, you'll merely usually guess wrong.  That's why it's 
important to solve the whole problem before trying much to optimize any 
particular piece.

If you think there are a million ways to solve a task, then the task is 
too big to consider as a whole.  Decompose it into pieces small enough 
that there are only a dozen for any one of the subtasks.  Then pick one 
of the dozen, and get it done.  Do it in such a way that it can be 
described on its own, tested on its own, and maybe even shipped on its own.

So enough for generalities.  After you've picked a task, and divided it 
into subtasks, try to solve one of those subtasks, and show us what 
you're trying, what you've done, and what you don't like about it.

You'll get lots of advice, some of it very good.  Just remember that 
many of us love to prematurely optimize (it's fun),, and you're at the 
wrong stage to be doing that.  So go ahead and write loops instead of 
list comprehensions.  Worry more about whether the variable names make 
sense, whether the functions are trying to do too much, and whether 
you're making too many untested assumptions about the outside world.

-- 
DaveA