[Tutor] Learning to program, not code.

[Albert-Jan Roskam]

----------------------------
On Sun, Dec 21, 2014 3:30 AM CET Dave Angel wrote:

>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.


Don't postpone writing unittests (don't use doctest). They really give you focus and confidence (peace of mind!). If you also use version control, you can automatically run all tests before each commit.




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