What Software Can Learn from Bluegrass
entrepreneur.com
entrepreneur.com
Also, heavy African American influences - a lot of music historians source the banjo to Africa, and African American string bands were very common and were a big influence on bluegrass and what we call "old time". If you're into bluegrass and old time, check out the Mississippi Sheiks. For something more current, the Carolina Chocolate Drops are pretty awesome.
Oh one other thing (man, really don't mean to seem too critical here), imperfection is very tolerated in a bluegrass group ;) You don't have to pass on a solo if you're worried you'll make a mistake, go for it. Better to go for it than hold back too much.
Just don't play over other people, be cool, listen a bit. You should have a basic competence, if not, probably practice a bit more and join a beginner or slow jam for a bit. But especially in a casual jam, seriously, take your break, it's cool.
I don't think we should give this article a complete pass. I think the author is using something the target audience thinks is cool but knows little about to make assertions for his favored development ideology. Also, I think a more detailed and nuanced analysis is instructive.
From the article: Studies show teams in which members have an equal voice and a chance to be heard perform far better.
That's not the complete story of how Bluegrass and Old-Time sessions work, in my understanding, at least not all of them. There is often a leader, ranking highest in some combination of talent and age, agreed upon tacitly, who gets to tell people when to take a solo. Irish sessions often work somewhat like this, with the leader telling people to start a tune instead of take a solo. Such leaders can establish a feeling or a culture for the group.
As in jazz, bluegrass music often contains unplanned elements. Because the musicians are experts at their discipline, they can quickly make alterations to the song while it is being played.
This can even happen in Irish music. However, most often there is a corpus of well known tunes and a structure worked out ahead of time. This also goes for Bluegrass and Jazz. In my experience, whether or not unplanned elements work has more to do with the expertise of the players and their relationships with each other than anything else. I think that is the most valuable takeaway from this analogy. It's not enough that everyone has a chance to be heard. There needs to be a culture of people who are collectively motivated to create something great together who are tuned into a mutual give and take. Sessions can also break down into unproductive competition.
Irish music is both easier and harder in this regard. You can get away with not improvising at all, but I find the tunes are complex, played in unison, and often at high speeds. There's no moment where all eyes are on you and you have to improvise, but there's nowhere to hide if you don't know the tune, either. Adding additional challenge is the minor variances in tunes that occur between regions and jam sessions. You really do need to build up a very substantial repertoire of music to be able to drop into an Irish jam and be able to play along for most of the session.
(Yeah, I know, I'm responding to a minor point, and going off on a tangent, I just like the subject).
In one session I used to play in, there was a player who could play any Irish tune after listening to it just one time through, so long as someone else kept playing it.
There's an Irish flute player in the Bay Area who I love playing with and listening to. He's 100% variations all of the time, all the way through, but he does it right and everything fits.
Adding additional challenge is the minor variances in tunes that occur between regions and jam sessions.
TBH, many North American players just fluff those. Often, it falls to more capable players to match up to the others.
Correct. It's not always a formally-assigned role. In experienced jam groups, the next soloist is decided with looks and is much more democratic. It's often not a fixed role; the person singing the song often takes that conductor role and nods or calls.
I'm an experienced jammer, but I regularly encounter folks who need to be shown the basics (lead vs backup, how you know when to take your turn, how a song is chosen, etc.). Surprisingly few classes teach this, preferring instead "this is a G chord, etc." Probably the best national resource is Pete Wernick method classes: https://www.drbanjo.com/new-jammers.php (I have no financial interest in saying this, just a selfish interest in having more sensitive jammers :)
As a mandolin/guitar player who plays bluegrass music with other people at least once a week, I'll ignore the many misunderstandings in TFA (for instance, a "breakdown" is entirely different from a solo known as a "break" in BG parlance). But if we're going to make an analogy between bluegrass music and software development, your comment that I quoted is probably a good one. When it's an instrumentalist's turn to step up (their "break"), everyone else is there to support them to make the soloist sound as good as possible. It is not everyone else's time to show what they know; calm down, your turn will come, and then it's everyone else's turn to make you sound good. And I think that's where the author was trying to go with this: in software, we all play different roles at different times in the process.
I will differ with you on imperfection. Sure, imperfection is tolerated, but an expert player who can improvise a solo with just about any song that's thrown at them, whether they've ever heard it before or not, can be a joy to have at a jam. Not just because of their expert solos, but because when they're not soloing they can really help to make the other players sound good when it's someone else's turn. Likewise, the expert developer is handy because they have good chops, but they're even more handy when it's time to help test figure out how to properly cover that gnarly piece of code, or give PM some options on how to handle the corner cases on that feature.
Mainly, though, bluegrass is a "team sport". I can pick at home alone and have fun doing it. But bluegrass is a style that's really meant to be played as an ensemble, with everyone doing their part at the right time. With that, I shouldn't even have to draw a parallel to software development. :-)
the jams also serve a second purpose which is that they are a pretty good way of communicating everyone's musical skills to each other. it doesn't tell you everything about a musician, but its a good gauge of overall maturity, interests, and sound. this means that likeminded musicians find each other quickly. festivals are interesting to watch, because you see that by the end of 4 days or so, people have often created informal jam groups that are quasi bands at that point.
tech meetups seem to be a really shitty quasi jam. open source projects seem to be a better format, and though i havent really been part of it, demoscene, defcon, chiptunes, infosec... strike me as communities that are a little more mature about the whole thing. i dont know them well enough, but i get the vibe anyway. they seem to have stronger sense of community.
i think that really good software teams are almost certainly the product of something resembling a jamming environment. the key is that all the members of the team have independently decided that they respect all the other members and want to be on the team with them. i think this is not fully understood and institutionalized in software management practices. i think that now the focus is too much on "here is the problem we want to solve, lets find the people that are skilled in this area". i guess im saying that good teams will create themselves and management is kind of a crutch. i get that there are real world constraints etc blah blah. but sometimes i wonder about this: money does not help creating good music, and i kind of think that might be more true of software than we think too.
I remember this being covered in software engineering books from the 80's and 90's like Peopleware. Really, it's the most important factor. It's the factor that really can be like a secret sauce. It's not the easiest "secret sauce" to sell books about, however. It's not a clickbaity "One Weird Trick."
Wow, yeah, I agree. I think this is such a misunderstood aspect of software. A lot of institutions seem to think it's like biotech, where a huge investment in gleaming buildings and dedicated lab space will make all the difference.
I'm old enough (and grew up in SF) to remember when software development was not the monied, gentrifying cultural enemy it's often made out to be nowadays, but a creative pursuit that naturally took place in funky, artistic neighborhoods, for the same reasons everyone else was there. It was the right environment for this sort of activity.
Money does of course help for software development in that you do need to live, and it takes a lot of time. I read this interesting quote about the Galapagos project (an arts collective moving from NY to Detroit)[1]: "You can’t paint at night in your kitchen and hope to be a good artist. It doesn’t work that way."
Now, counter examples abound, I am sure of that. And most creative folks do need to do something to make ends meet. But in the end, if paying the rent means you have to be drained from a corporate job by the end of the day, it does make it harder to create good music, art, and yeah, software. This is one reason I have to wonder if SF can continue to be the locale where this sort of creativity, including even software, will come from in the future.
Not sure I agree. Lots of Bluegrass players, even the some of the best ones, favor speed over clean execution. Maybe another commonality with SW development.
I don't know if it's still a thing, but I've met lots of Bay Area 20-somethings who seem to try and impress you with how many keystrokes a minute they can pull off in front of you, regardless of how it helps or hurts communication about what they are doing. It's as if they're enacting a TV drama image of what a hacker is supposed to be like.
There are some parallels, though. Bluegrass music was primarily a male-dominated genre, but that is changing. Early pioneers like Lynn Morris, Hazel Dickens, etc. opened the door, Rhonda Vincent and Alison Krauss pushed it open, and Molly Tuttle, Sierra Hull, and Sarah Jarosz have come through. There's little doubt in mainstream bluegrass now that women can be spectacular (Molly just won IBMA Guitar Player of the Year), though there are plenty of conservative pockets left and even prominent successful women still encounter sexist attitudes and behaviour.
Another is the presence of a thriving indie subculture. There are thousands of small bands achieving modest regional amounts of success. Two examples from tech: Clive Thompson plays in the Brooklyn 80s covers band The Delorean Sisters http://www.deloreansisters.com/ and I play in the New Zealand progressive bluegrass band The Pipi Pickers http://pipipickers.com . There are plenty of side projects of software developers, small pet projects that will never be "the next Linux" but which achieve a modest following and serve the purpose of being intellectual stimulation for the developer. The jump from hobbyist to professional is a big one, though bluegrass lacks the paychecks in tech. "Get good at it, and you can make literally tens of dollars playing bluegrass."
My favourite comparison though is the headspace of developers and musicians. Both struggle to explain their inner processes, both crave flow state, both need a lot of practice and competence to reach that stage. Part of me suspects that a 10x developer, if such a beast exists, is mostly a function of having absorbed the language/framework/os so deeply that they aren't constantly losing flow state by hitting StackOverflow. Similarly, to play in the pocket and improvise fluidly requires hours of practice and the internalising of the physical actions required to make a given sound. Anyone trying to figure out on the fly where a D note is, is not in that flow state.
Neither seems at risk of being automated away. Deep Learning is making inroads into styles and genres (e.g., https://arxiv.org/abs/1801.00887) but little sounds like it could replace musicians and composers any time soon. And while deep learning systems are being used to tune deep learning systems, we're still far away from software being generated from problem descriptions or specifications. (Please throw links at me if I'm wrong!)