Friends, family, and work colleagues all know that I have a passion for music, but rarely am I able to get across just how much the things I’ve learned through my musical adventures are directly applicable to my career and everyday life. I’ve written on such topics before (links at the end of this post), and today I have a fresh (to me) perspective to ponder with you.
I’ve just gotten back from what is turning out to be an annual vacation to a week-long singing workshop led by Bobby McFerrin and 5 of his long-time associates (Rhiannon, Dave Worm, Joey Blake, Christiane Karam, and Judi Vinar). It seems that I tune in to some different aspect of vocal performance each time I go. This year, one of the things I noticed has a lot to do with one of the main foci of the workshop—the nature of improvisation.
Improvisation is simply making things up (musically or otherwise), but it is rarely as simple as that. To improvise well, you’ve got to have a firm grasp of the “language” you’re improvising with, and the structure of the kind of improvisation you’re doing. In music, that means things like scales, rhythms, chord progressions, meters, longer-scale forms, and different varieties of improvising formats. Perhaps the analogues for web development are the code languages (HTML, CSS, jQuery, PHP), design competencies (color, typography, layout), and design/dev tools (Dreamweaver, Photoshop, WordPress).
But improvisation also needs a certain sensitivity and discernment. Something along these lines: “…here’s a musical moment coming up. Given all I know about this kind of music, I can imagine these options for what I can make up to add to it. Which do I pick?!?” Perhaps there are several musicians improvising together; how do you know when to jump in, when to lay back?
This is the particular aspect that I keyed into while away. Once you get over the “oh-my-goodness-I’m-doing-something-new” jitters, you learn to pay attention to when it feels right (or, conversely, feels forced/false) to jump in, or to leave space open for others; when to do a quick scale pattern in a normal mode and when to hold a weird note for an unexpectedly long time.
And this has something surprisingly relevant to say about life as a web designer in a busy international development office at a major land-grant university.
A Day Like Any Other
No web developer’s career is quite the same. You’ve got your freelancers doing work for multiple local small businesses; your freelance specialists who focus on front-end or back-end or some other aspect, and partner with complementary specialists on medium-sized projects; your enterprise-level corporate development teams; your ad agencies with their web person (or web department); your start-up app developers working solo or on teams large and small. Those, and everything in between and beyond. The “rhythms” of the career-lives of each of the above are going to be quite different.
Although I have many co-workers here at OIRED, as the web development specialist I’m still very much the kind of “one-man shop” that many freelancers are. I think of most of my co-workers as clients, and I have upwards of about a dozen projects (i.e. websites) that are in-development or under-management.
My day typically starts with high hopes that I will be able to focus on one or more projects that are in development. Currently, I’m porting a couple of large websites over to a web-based content management system, plus there’s one website that needs an initial design vision created, and then a single-page “site” based on that design.
I log in, I check email, and there are any number of routine requests for me to attend to for the websites under management. Here’s a document to make downloadable on Site A, and link from a page in the site. Here’s information about the discussion series, to be posted on Site B. So-and-so’s title has changed, can you change it everywhere it appears on Site C? By the time tasks are prioritized and addressed, sometimes it’s 9am. Sometimes it’s 11am.
Meetings are another variable. I don’t really mind them; in our office, meetings are generally called to do meaningful, productive work, and often I go back to my office with some tasks to do that will really help someone accomplish something useful. Or mentoring—occasionally, someone being funded by one of our projects needs help in a technology-related area, and comes to me for advice on how to do their own web development. I enjoy that work too.
And there’s the occasional non-project task that comes up that takes a bit of time, and adds value in a more general way. Hopefully these blog posts are somewhere in that neighborhood.
None of my days are ever quite the same.
Sometimes, though, I need to read the rhythms of my work and know when it feels right to shut the door, postpone routine site-maintenance requests for a day or so, and focus on making some progress toward one of my project goals.
A Cloud Passing Overhead
A great vocalist and improviser—guess who?!?—tells a story about a friend of his, a great cellist, who was traveling in Africa to learn about improvisation. He asked a village shaman to sing his rain song, so he could write it down. The shaman sang something like: “nah-meeeh-doh-WEH-dah, di-nuuu-BOI-de-wah.” The cellist wrote it down, and then said “I think I’ve got it, just sing it again so I can check it.” So the shaman sang something like “meh DOH di nuuu wah, weh nah DI DI boi weh dah,” something completely different.
“Wait,” said the cellist, “that’s not what you sang the first time.”
“Of course it wasn’t,” the shaman replied. “The first time, a herd of antelope were over there in the field, and a cloud covered the sun. Now the antelope have gone over there, and the cloud is passing.” For the shaman, the right music for the moment changes based on, well, the moment—the prevailing conditions at the time the music is sung.
Days can be like that, can’t they?
For more musings on the intersection of music and daily/work life, see Teams; or, Singing Together as Metaphor for Inter-Personal Action and Build the Right Thing: Client-Focused Development.