I happen to deal with two fields in which people seldom practice. They are both relatively private fields so people aren't ever "on stage," but they are almost always expected to be performing when they are live. My two chosen fields are writing and software development. (That's a lie, actually. I happen to have experience in software development, but the field I'd hoped to choose was computer science.) In these fields, it's a little harder to distinguish between practice and performance because the product you produce always becomes so similar. However, there is substantial evidence to suggest that the two differ from each other dramatically. People don't tend to improve at programming very much through on the job experience. The best programmers are the ones who spend hours of their own time programming their own projects. The very best ones are the ones who have already spent much of their own time practicing, whether or not they still do. (Once a programmer founds a start-up or otherwise gets consumed in a particular project, I think it's safe to say that she has ceased to practice and instead switched over to performance full time.) In coding, I think there is actually a little more of a distinction between what people do for themselves and what they do in contribution to a major project than there is for writing. Software projects tend to get bloated and maintaining them or otherwise continuing to develop them becomes an extremely slow undertaking. Developers who successfully maintain bloated projects do so by ceasing to think about programming in general and instead focus on the particular problems of their particular project. You learn the tricks of coding around particular bugs and layout projects. You learn to optimize on that one particular bottleneck. Everything you study and everything you learn tends to be constrained to one narrow project that has practically no relevance for any future programming project you deal with. If you start from scratch on a project, you can be sure that the one bottleneck your new project will be designed to have absolutely zero chance of recreating is whatever one you spent dealing with the most on your last project. You've learned that lesson, and you will not do anything that risks repeating it. Another part of the problem is that maintaining an ancient project tends to be excruciatingly slow compared to doing new development. In new development, you learn from writing hundreds of line in a sitting, and running dozens of new tests. You try out many things you've never done before every week. In maintaining an existing project, you spend most of your time debugging, which means you spend most of your time reading code instead of writing it, and most of the time you spend reading code is spent reading the worst code in your code-base because that's where most of the bugs live. (The original computer bug was a moth. Since then, the rest have mostly been dung beetles.) Trying to learn about writing good code by spending most of your time reading code that needs to be debugged is like trying to learn to write great poetry by reading the lyrics of pop music. Just ain't gonna happen. I'd love to know who the Tennyson and T.S. Eliot of writing code are. Someone could presumably learn a lot by reading their code, but as a profession, software developers have very little sense of what makes code good code. In fact, for a profession as filled with brilliant people as software development is, the field has extremely idiotic views of quality. Most software developers are intimately familiar with a lot of very bad code, and the prevailing views among software developers about good code tend to be that good code is the opposite of bad code. "Considered harmful" articles tend to be what advocates of better coding practices reach for when they seek to improve the way people develop. Good is not bad negated. Good is a very narrow and improbable condition. As such, bad negated still tends to be bad. (My own "considered harmful" article is a tongue-in-cheek criticism of the general philosophy behind "considered harmful" articles, but it is worth noting that my experience of people presenting their views on how code should be developed is sufficiently dominated by "considered harmful" articles that my pattern matching tendencies, etc. suggested that the best way to write the article would be to write a considered harmful article. I should probably write a follow-up called "good code considered helpful.")
Then you have writing. As you can probably see, my natural writing style tends to contain a lot of parentheticals and quite a few asides. (By my natural writing style, I mean my stream of consciousness. I could just as easily call writing childish rhymes my "natural writing style" because it was the first writing style I really developed. I'd say my early stabs at writing poetry were on average more poetical than the lyrics of most pop songs, but not by much.) Asides aside, my stream of conscious writing style is clearly different from the writing style I would and do use when attempting to write for publication. But I do still have a question in my mind as to how much writing in stream of consciousness should be considered practicing writing. I think it probably counts, but I don't think that it's a sufficient exercise on its own. Writing in stream of consciousness is probably roughly equivalent to a musician doing ear-training. You can't learn to be a great musician without it, but you can't even learn to be a mediocre musician by ear training alone. Reading would be equivalent to listening to other musicians. Writing poetry would be equivalent to doing advanced fingering exercises, but I still can't figure out the basics. What does it mean to practice writing the way one would practice scales? I think that certain constrained exercises might have merits. For example, I have a tendency to say "I think" more often than I should. It doesn't typically add anything to my writing. I'm planning to write a little bit of code to help me score my own writing. I'm already running my blog through a small amount of code everyday to measure a few things, I might as well start to build out a system for measuring other indicators of what I would consider improved writing. I'm not sure that this type of thing is at all equivalent to practicing scales. I think it comes closer to practicing particular measures of music to work out the kinks, but I expect it to be a valuable exercise. I will continue to think about this subject in the back of my mind, and hopefully I will have something interesting to say about it at some future date.
Along the lines of the distinction between practice and performance, another valuable distinction that people often lose is the difference between playing to learn and playing to win. Valve has a documentary called "Free to Play" about the first DOTA 2 tournament. Dendi of NaVi as shown in that video is someone who understands the difference between playing to learn and playing to win. I don't know if any athletes make this distinction, but I know that many entertainers have. The Marx Brothers and the Beatles are well-documented to have taken this approach. Some performances matter more than others, and there are things that you can only learn in a performance that you cannot learn in practice. Great entertainers must learn to please a crowd, and to some extent they must learn how to do that by experimentation, so a typical performance should be done with some intention of playing to learn. You experiment and test things that might not work so that you can improve your ability to perform in the future. But then there are some performances there are some performances that are too important to lose by taking stupid risks. Dendi knew how to be patient, and he saved his patience for the tournament because it wasn't typically valuable. He could learn more by experimenting with stupid risks in his typical games than he could by playing with the intent to win, and winning wasn't mission-critical in most of those games, but he did know how to suppress that tendency when he played a game that mattered. The Marx Brothers experimented aplenty in live performances, but they knew to use only their best lines when they were in front of a camera. The Beatles produced plenty of garbage in their time, and even included a little garbage in most of their albums. All of it was highly experimental, but they also knew how to cut everything questionable when they were trying to produce truly magnificent albums, and they kept both Sgt. Pepper and Abbey Rode clean. "Glass Onion" would have ruined Sgt. Pepper. So would have "I Am the Walrus" or "Why Don't We Do It in the Road" and probably "Doctor Robert." (The Beatles openly admit that many of their songs are about drugs, but "Lucy in the Sky" is not one such song, according to them; it's a description of a picture a child drew.) Rubber Soul and Revolution are retroactively better albums than they would have been without Sgt. Pepper because they were clearly preparing material for Sgt. Pepper, but if those had been the height of the Beatles' psychedelic experimentation, they probably wouldn't be considered two of the five greatest albums of all time. Though it's hard to say, Bob Dylan never did learn to suppress his instinct for risky experimentation long enough to create a truly clean album. The Rolling Stones never pushed the kinds of boundaries that others of their era did. Jimi Hendrix is a little too abstruse. There aren't many musicians who have managed to be occasionally perfect while also innovating and experimenting enough to do something truly remarkable.
Those who achieve excellence, practice more than they perform. When they perform, they play to learn more often than they play to win, but they know how to play to win, and they sometimes do it. Most of the rest of us fail to even make the distinction.
No comments:
Post a Comment