|
Just don't play over other people, be cool, listen a bit. 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. :-) |