Home > musing, open source tools > Coding is like being in a band

Coding is like being in a band

June 25, 2012

I asked my friend Nikolai last week what I should learn if I want to be a really awesome data scientist (since I’m an alpha female I’m sure I phrased it more like, how can I be even more awesome than I already am?).

Being a engineer, Nik gave me the most obvious advice possible: become an engineer.

So this past weekend I’ve looked in to learning Scala, which is the language he and I agreed on as the most useful for large-scale machine learning, both because it’s designed to be scalable and because the guys at Twitter are open sourcing tons of new stuff all the time.

That begs the question, though, to what extent can I become an engineer by reading books about languages in my spare time? According to Nik, real coding is an experience you can’t do alone. It’s more like joining a band. So I need to read my books, and I need to practice on my computer, but I won’t really qualify as an engineer until I’ve coded within a group of engineers working on a product.

Similarly, a person can get really good at an instrument by themselves, they can learn to play the electric guitar, they can perfect the solos of Jimi Hendrix, but when it comes down to it they have to do it in conjunction with other people. This typically means adding lots of process they wouldn’t normally have to think about or care about, like making sure the key is agreed upon, as well as the tempo, as well as deciding who gets to solo when (i.e. sharing the show-offy parts). Not to mention the song list. Oh, and then there’s tuning up at the beginning, choosing a band name, and getting gigs.

It’s a similar thing for coders, and I’ve seen it working with development teams. When they bring in someone new, they have to merge their existing culture with the ideas and habits of the new person. This means explaining how unit tests and code reviews are done, how work gets divided and played, how people work together, and of course how success gets rewarded. Moreover, like musicians, coders tend to have reputations and egos corresponding to their skills and talents which, like a good band, a development team wants to nurture, without letting itself become a pure vehicle to it.

Which means that when you hire a superstar coder (and yes the word seems to be superstar- great coders can do the job of multiple mediocre coders), you tend to listen more carefully to their ideas on how to do things, and that includes how to change the system entirely and try something new, or switch languages etc. I imagine that bands who get to work with Eric Clapton would be the same way.

I’ve been in bands, usually playing banjo, as well as in chamber music groups back when I played piano, so this analogy works great for me. And it makes me more interested in the engineering thing rather than less: my experience was that, although my individual contribution was slightly less in a band setting, the product of the group was something I was always very proud of, and was impossible to accomplish alone.

Now I don’t want you to think I’ve done no coding at all. As a quant, I learned python, which I used extensively at D.E. Shaw and ever since, and some Matlab, as well as SQL and Pig more recently. But the stuff I’ve done is essentially prototyping models. That is, I work alone, playing with data through a script, until I’m happy with the overall model. Since I’m alone I don’t have to follow any process at all, and trust me you can tell by looking at my scripts. Actually I wrote some unit tests for the first time in python, and it was fun. Kind of like solving a Sudoku puzzle.

The part I don’t think works about the coding/ band analogy is that I don’t think coders have quite as good a time as bands. Where are the back-stage groupies? Where are the first two parts of sex, drugs, and rock ‘n’ roll? I think coding groups have their work cut out for them if they really want to play on that analogy.

Categories: musing, open source tools
  1. June 25, 2012 at 8:37 am

    While I believe you’re totally correct about this, it presents a wicked problem. What to do with all of the autodidact coders out there who haven’t had real teamwork experience? The efforts that commercial software / design houses are putting forth to provide any training at all are terribly thin across the industry – few rise to the challenge. So is this why we have a logjam in the development world, with high unemployment on the outside and a desperate need for quality coders on the inside? Is this why bad software rarely gets better?

  2. June 25, 2012 at 8:54 am

    Enjoy your blog, I am engineer and a developer. I am working on understanding the big data after watching Watson on Jeopardy!
    Think about the origins of Scala – it did take a village to raise a child. The more open a community has been (example Apache vs.your prop. dev shop), the better the product has been. I agree with Nik in that being a part of a team and the community at large opens up use cases, applications and most importantly gaps in thinking.

  3. Eugene O'Neil
    June 25, 2012 at 10:15 am

    Saying that a great coder can do the job of multiple mediocre coders is like saying a great novelist can replace an entire room full of monkeys.

  4. bill maylow
    June 30, 2012 at 9:32 pm

    i am not too sure about scala being the best language choice … what about maple ? and others ? python is the equivalent of ruby so i guess ruby won’t do. well then the lowest levelwould of course be c++ but that’s reserved for the gods of gods.

  5. Emmett
    July 5, 2012 at 8:26 pm

    AGILE (the methodology) is the kind of fun, collaborative environment you refer to. With the right team. There are many wrong teams.

    Being a mathematician, you would probably also enjoy requirements management.
    I started life as a mathematician. I accidentally became a software minion.
    I’ve always worked in embedded code under FAA rules (DO-178).
    Waterfall development, layers of requirements, layers of testing.
    Hundreds of small modules, tight coding structures (and strictures), peer review but little collaboration.

    Most coders get to be happy when their modules do what they are supposed to, my job has been showing them all the things their modules can do they are NOT supposed to.

    Big projects require schedulers or even an OS, many products do not.
    I’ve made a good living for years, have yet to write any code. Script a little Perl and Python for testing.
    Read a dozen or so languages for tracing and review purposes.
    Reading and coding are NOT the same.
    Verification, validation and process employs 2 to 3 people for every coder on staff.
    (DO-178 rules require independent verification)

    (re Bill’s post) The gods write in ANSI C and ADA and do NOT use libraries.
    Object was invented to make coders lazy.
    The gods are grumpy,skeptical bastards.

    (re Eugene’s post) Superstar coders become architects and make decisions on how the entire mess will be structured before anyone starts coding – this requires a lot of been there, done that. Recovering from mistakes also requires superstar qualities.
    The very best coders deeply understand the hardware they are coding to.

    (re Brianvan) Rockstars code BSPs or development layers that talk to the hardware FOR the rest of the programmers. They also command their own compensation. Many are autodidacts started with hardware and learned to code. And your logjam is caused by HR setting a ten years experience bar on a language that has only been in use five.

    Companies are reducing training everywhere, but by the same token; we get fresh college grads who most code to OS (like Windows), don’t understand configuration management or revision control. Apparently these concepts moved to the Software Management curriculum?
    Who likes coding and shows up to college saying I want to do Software Management?

    If you really want to have fun with code, make a piece of hardware do something. Most board manufacturers have Developers Kits for cheap bucks http://www.ti.com/lsds/ti/tools-software/designkits.page

    • July 5, 2012 at 8:50 pm

      Nobody can accuse you of not having opinions.

      • Emmett
        July 5, 2012 at 10:06 pm

        I’ve had years to grow a few
        ; – )
        Of course my perspective may be skewed

  1. No trackbacks yet.
Comments are closed.
Follow

Get every new post delivered to your Inbox.

Join 1,553 other followers

%d bloggers like this: