It's not about technology for its own sake. It's about being able to implement your ideas.
It's an oft-stated goal in introductory coding books and courses: to get you to think like a programmer. That's better than something overly specific and low-level like "to learn Java." It's also not meant to be taken literally. A clearer, more accurate phrasing would be "to get you to break down problems in an analytical way." But let that initial, quirky sequence of five words--"to think like a programmer"--serve as a warning and a reminder.
Because you really don't want to think like a programmer.
It starts slowly, as you first learn good coding practices from the bad. Never use global variables; wrap all data into objects. Write getter and setter methods to hide internal representations. Use const wherever possible. Only one class definition per file, please. Format your source code to encourage reading and understanding by others. Take time to line up your equal signs so things are in nice, neat columns.
Eventually this escalates to thinking in terms of design patterns and citing rules from Code Complete. All these clueless people want you add features that are difficult and at odds with your beautiful architecture; don't they realize that complexity is the enemy? You come to understand why every time a useful program is written in Perl or PHP it's an embarrassment to computer science. Lisp is the way, and it's worth using even if you don't have access to most of the libraries that make Python such a vital tool. Then one day you find yourself arguing static versus dynamic typing and passionately advocating test-driven development and all hope is lost.
It's not that any of these things are truly bad on their own, but together they occupy your mind. You should be obsessing about the problem domain you're working in--how to make a game without pedantic tutorials, what's the most intuitive set of artistic controls in a photography app--and not endless software engineering concerns.
Every so often I see someone attempting to learn a skill (e.g., web design, game development, songwriting), by finishing a project every day/week/month. I love these! They're exciting and inspirational and immediate. What a great way to learn! The first projects are all about getting something--anything--working. That's followed by re-engineering familiar designs. How to implement Snake, for example. Or Tetris.
If you've embarked on such a journey, the big step is to start exploring your own ideas. Don't copy what people who came before you were copying from other people. Experiment. Do crazy things. If you stick to the path of building what has already been made, then you're setting yourself up as implementor, as the engineer of other people's ideas, as the programmer. Take the opportunity to build a reputation as the creator of new experiences.
And, incidentally, you know how to write code.
(If you liked this, you might enjoy Learning to Ignore Superficially Ugly Code.)
permalink February 12, 2014
I'm James Hague, a recovering programmer who has been designing video games since the 1980s. Programming Without Being Obsessed With Programming and Organizational Skills Beat Algorithmic Wizardry are good starting points. For the older stuff, try the 2012 Retrospective.
Where are the comments?