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
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
