On Sun, Jul 20, 2014 at 6:26 AM, <mathias....@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. :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
