He took a long gulp of coffee, then went back to staring at the résumé on his desk. His lips parted again, just wide enough that a monotonous "So, you're in college" could slip out. "Yes," the young man replied, uncertain if it had been a question or a declarative statement. From the waist up, he was calm and collected, though his foot bounced up and down nervously. "And you'll be graduating in a few months," droned the hiring manager. "Yes," chirped the young man. "Listen, I know you think you know what's what, but you don't. None of the stuff that they taught you in school has anything to do with the stuff that goes on around here." A brief pause. The hiring manager made eye contact with the young man for the first time. "With that in mind," he continued, "how do you think your experiences have prepared you for this job?"
The young man's foot stopped bouncing.
----
In a recent interview, legendary guitarist John Petrucci discussed the connections that he had observed between musicianship and athletics:
"I enjoy weightlifting, and I've been doing it for several years now, and I've always noticed a total parallel between athletics -- anything that requires a mindset and a conditioning mentality -- and guitar playing, or drumming, or whatever. Total parallel. Everything that you need to do to become a great athlete, you need to do that to become a great guitar player. You can really transfer those things. Weightlifting, it's about technique, and form, and how you build, and it's a progression, and you have to be strict, and you have to be consistent. Same thing on guitar. If you're a gymnast, and you're working on routines, those routines are performances and you have to get them perfect and you have to break them down to the smallest elements, and if there's one element you can't do, you have to figure out why you can't do it. Well, maybe my shoulders aren't strong enough, so I'll do presses. Well, it's the same thing on guitar. Why can't I do that? Well maybe because this pinky stinks, so I'll work on that."
When it comes to the discipline required to execute particular techniques correctly, I definitely agree that there is a solid connection between athletics and musicianship. Martial artistry is the only thing I've ever done voluntarily that even vaguely resembled athletic activity, and the parallel is readily apparent there: drill the techniques until you can do them without thinking so that when it comes time to execute them in an actual [concert / jiu-jitsu match / fight to the death against lizard demons], there's no chance that you'll make a (fatal) mistake.
However, when it comes to the songwriting process, I see a much stronger connection with computer science. During my junior year of high school, I taught myself how to write programs on my TI-83 calculator. My magnum opus was a rudimentary turn-based combat game called "Fight a Nug-Nug!". I approached the coding process linearly: I would think "What is the first screen that the user will see?", write that code, test it, and then move on to the next screen. I just assumed that this was the way that all programs were written: code is written sequentially in the order that it will be relevant to the user.
Last year I took my first computer programming course with the curiously-named Olin Shivers (not an eskimo, I promise). In addition to touching upon a wide variety of programming concepts, the course emphasized a method of writing code that was referred to as "the design recipe": First, make a wishlist of all the functions that you think the program will need. For each function, write a "contract", which lists the types of data that the function will take in and put out, and a "purpose statement", which explains in words what the function will do in the context of the program as a whole. Next, we would write specific examples of how the function should behave when given particular pieces of data. Only after all of these steps had been completed would we move on to writing the actual code. Our final project was to design a Tetris program; here's one snippet of code from my submission:
;; tetra-shift : tetra string -> tetra
;; moves a tetra left or right
(check-expect
(tetra-shift (make-tetra (make-posn 20 20)
(cons (make-block 20 20 "fuschia") empty)) "left")
(make-tetra (make-posn 10 20)
(cons (make-block 10 20 "fuschia") empty)))
(define (tetra-shift t wurr)
(make-tetra (make-posn (cond [(string=? wurr "left")
(- (posn-x (tetra-center t)) cell-size)]
[(string=? wurr "right")
(+ (posn-x (tetra-center t)) cell-size)])
(posn-y (tetra-center t)))
(bset-shift (tetra-blocks t) wurr)))
While this may look like gibberish to most people, one important thing to point out is that this piece of code calls the functions "bset-shift" and "tetra-blocks". Whether or not these functions had actually been written yet was often irrelevant; by strictly adhering to the design recipe, we could insure that our code would work correctly once we were done with everything. This made writing long programs much easier: instead of stressing out about everything all at once, we would just make an outline, assume that we would eventually be able to get each component to work correctly, and then fill in the code one function at a time.
So where's the connection with songwriting? In the past, I would always write a riff, perfect it, make sure that I could smoothly transition to it from the previous riff, and then move onto the next section. Now I often find myself viewing riffs as functions to which I can apply the design recipe: when I write a particularly challenging passage, I'll just assume that I will eventually be able to play the passage and the transitions perfectly, then move on to writing the next section. This allows me to sustain the momentum of the songwriting while the creativity is flowing strong rather than getting caught up in all of the tiny details right away. Once I've got the entire piece laid out, I'll go back through and smooth out the rough patches using the gymnast mentality that John Petrucci mentioned.
----
After taking just a fraction of a moment to gather his thoughts, the young man launched into his answer: "Well, sir, I would agree that in many cases, what I was taught to do and how I was taught to do it will be largely irrelevant. However, the ways that I was taught to think about problems affect everything I do. Will I ever need to prove that a subgroup is cyclic in the real world? No, but I will need to apply rigorous logic to supply my arguments with irrefutable evidence. Will I ever need to write another polymorphic accumulator function in Java? Probably not, but I will need to break problems down into manageable chunks and keep track of how they all relate to each other. My abilities to analyze new situations and efficiently formulate solutions are directly related to the thought processes that I was exposed to at school, even when the skills that I'm using are completely unrelated to my degree." The hiring manager, who had gone back to staring blankly at the résumé, blinked.
"So, when can you start?"
----
Week 14 total: 26 hours
Grand total: 346.5 hours
Required pace: 269 hours (+77.5)
No comments:
Post a Comment