What Next After Python Basics

Chris Angelico rosuav at gmail.com
Sun Jul 20 03:29:44 CEST 2014

On Sun, Jul 20, 2014 at 6:26 AM,  <mathias.moe at gmail.com> wrote:
> But mostly, just code. Anything. For my studies, I get assignments to go through large bodies of text and sort them for some criteria, and while I'm given tools to do it, I try to make my own tools to get the job done. That is to say, if there's something in your day that you use in some way, and it's fairly simple, or its essential functionality can be copied, then that's something to copy.
> I apologize for the raving suggestions.

No, that's not raving. The way to get good at something is to do it,
and do it a lot. That's why I don't play lasertag, that's why I don't
butcher my own meat, that's why I don't write optimizing C compilers.
I don't have time to get good at any of those things. (Not that I have
a philosophical objection to any. If my circumstances change, I might
take one of them up at some point, but for the moment, I don't.) To
become a programmer, you need to write programs.

As a student programmer, you get very specific tasks: Write a program
that, given this input, produces this output; and use exactly these
tools (language statements, library functions, etc) to do so. There's
a definite "right answer" and a whole lot of "wrong answers". (And
it's really obvious when someone asks for help. When the problem's
that specific, it's bound to be homework.)

As a novice, you generally have fairly specific goals, but now you
have flexibility in how you implement it. Import this CSV file into an
SQL database, converting "25 Mar 01" into "2001-03-25" as it goes
through. You could do that with a preparse script, or you could import
into a temporary table and convert it in the database, or you could
parse and import in one step. It's fairly straight-forward to figure
out whether you've accomplished the goal or made a mess of it, but
there's no longer a "right way to do it".

An expert programmer has to cope with much vaguer requirements. Reduce
the number of data entry errors in invoicing. Adding something to a UI
that helps people notice errors earlier may not clearly and
demonstrably be working, until they've had a chance to get accustomed
to it and you start seeing that the error average per week is lower
than it was before the feature went in. (And even then, you can't be
sure; something else might have caused the improvement.)

(An expert will also sometimes get really clear goals. These are good
days. These are luxuries. These are the times when you profusely thank
the previous programmer for putting in such comprehensive unit tests
that the porting process is reduced to "make sure all tests pass, then
we're done". These are rarities, sadly, but they definitely do exist.)

Before you can handle the complex and less-clear jobs, you have to get
enough experience to know what you're doing. That means doing jobs
that have really clear requirements. Will they be boring? Maybe.
Derivative? Almost certainly. But pointless? Absolutely not. And maybe
you'll recreate something in almost the same way, but with one little
tweak that makes it now absolutely perfect for you. Or recreate
something in a different language, just because it's better that way.
(I did that myself recently - see http://rosuav.com/1/?id=1009 - even
though the old one was working fine.) Never useless, because of what
it does for you, the programmer.

It takes ten thousand hours of practice to achieve competence.
Fortunately, those hours will be enjoyable, if spent programming. :)


More information about the Python-list mailing list