|
|
|
|
|
|
by dodecaphonic
5390 days ago
|
|
|
I was 14 and faced the same questions you do. I was surrounded by all these guys who could bend bits with their thoughts and had pointers and stacks for breakfast. They all used see and did stuff that seemed amazing to me at the time. Add to that the fact I felt more like a 'creative', in the narrowest of senses, so I was not sure how to reconcile both my interests, my friends were no help and I did not know much about the demo scene, nor of people like _why and the Processing guys. Somewhere along the way I found Perl, and the way from A to B was not paved with incantations. It took me a copy of Randal Schwartz's "Learning Perl" and a Christmas Holiday to get really hooked — the immediacy of thinking and doing and making mistakes and fixing them was paramount to my believing programming was not only for the initiated. While I second all the recommendations for having a mentor and working closely with knowledgeable people, I disagree with putting IDEs in the middle and choosing PROJECTS (more on that on a second). I sincerely think there's a great benefit to shortening the path between you and running code, and I believe dealing with compiler errors and linker spewage can be detrimental to the overall purpose of getting acquainted with code and thinking about programs. About projects: having something as a goal is definitely a must; I don't object to that, but to all the baggage the term _project_ carries. Have something around which you'll structure your thought, but allow yourself to tinker and to put it in the backburner if it proves itself to be not challenging enough or too daunting a task for your current knowledge level. If you're neither having fun nor being challenged, you won't improve. If you want specific tips on what tech to use, it would perhaps be better if you told us what you want to achieve. Do you want to code for the web, to take your designs to the next step, to code simple workflows? |
|
|