Musical Software Engineering: Christian Foster Howes

Christian Foster Howes majored in Computer Engineering and Musical Performance as an undergrad at University of Michigan. Fifteen years later and Christian has held VP of Engineering roles at startups as well as founding Little Mission Studio, a private music school in San Francisco.

He joined us for a conversation about the importance of develop your skillset beyond writing lines of code.

Topics include:

• why musical performance prepares you for working on a software engineering team
• what Christian’s evaluation criteria are for evaluating engineering resumés
• how to achieve redundancy in musical performance and software engineering teams

For the full text transcript see below the fold:

Audio:

Play in new window || Download

Video:

Max: Welcome all. The Accidental Engineer here. Today we have the pleasure of Christian Foster Howes joining us.

Christian is founder of Little Mission Studio, which is a music school in the Mission neighborhood of San Francisco. Christian has a serious background in engineering, Ex-VP of engineering at StarMaker a music start-up.

He’s worked in a bunch of different industries but at this point in his career is, as I said, founder of Little Mission Studio and still very much involved and intrigued in the software engineering field.

Christian: Doing work for various parties in that world as well.

Max: Indeed, and some of that educational itself.

Christian, do you mind sharing a little bit more about your background than I’ve given and how you found your way to engineering?

Christian: We can go all the way back when I was probably about the 8th grade, and my older brother was doing the SAT’s and the dinner table conversation was, “What do you wanna be when you grow up?”

They looked at me, I’m like, “I’m gonna be a musician.” The immediate reaction was, “No, you’re not. You’re not gonna make any money that way, and you should be an engineer.” And I’ve always enjoyed the math and science and all of that, and I’ve really enjoyed the music stuff but at that moment in my mind is when I decided to be a double major.

So I made it to University of Michigan, got my degrees in percussion performance and computer engineering, and have been lucky enough to do both throughout my life. I’ve worked software in telecommunications with time spent in Europe on customer sites, worked for a design consultancy for a period of time, several different startups.

I’ve helped [the businesses] get their footing, spent a big chunk of time at StarMaker which makes a karaoke app, but there was a change in ownership and it was time for me to move a different way. I’ve been an active performer and player of music throughout all of this. And three years ago now, opened Little Mission Studio with some friends of mine.

Max: Our audience has a huge and surprising overlap with music performance and a surprising number play instruments themselves. Having worked on technology software for music at StarMaker, what’s the intersection that you see the most between software engineering/programming/systems design and musical performance?

Christian: Some people approach an engineering problem strictly as a mathematical problem, like, “It’s right or it’s wrong.” Software is never that black and white. And there is an element of artistry in everything that you produce. When somebody talks about elegant code, well, your idea of elegant code is probably different than my idea of elegant code.

“Which way should I do this thing?” There’s probably five different ways. And one of them is more efficient, one of them is easier to maintain, one of them…right? So being able to look at all of these things, and bring that art, that creativity and artistry to your development is really helpful, and it gives you another…it’s a sense of perspective.

I think another area is audiences. A lot of developers don’t always think about their audience, who the customer is—being able to identify that you have a lot of different customers.

A lot of the work that I’ve done has been database and server back-end. I’ve done some front-end and some UI stuff, but my customers that I’ve had have been okay if I’m dealing with data–I’ve got customers of the actual end-user who wants the right data at the right time.

But then I’ve got the business person who needs to know what this data means and other engineers that care about how that data moves around–all of these audiences are like musicians, when you’re preparing a piece, and you’re getting ready to perform, and you put together a program, who is your audience? Who’s coming to see this? And often times it too is varied, and thinking about how do I put a concert together that everybody will enjoy at least part of it.

Max: One of the other parallels you mentioned to me about being a member of a group performance or a team–whether it’s an ensemble, orchestra, band, or software project–I was impressed at how similar teamwork in those two types of domains is.

Christian: Yeah, I think that in the software team sometimes you think, “I have my world. I just have to do my thing,” or, “Why can’t so and so over there finish their work? I’m waiting on them to do it.”

But when you have the experience of doing a live group performance and it doesn’t have to be just music, like theater–even film–any of those things, if so-and-so is not pulling their weight, right? If the actor with the next line doesn’t say their thing, where are you going? How are you getting it, right?

If the oboe soloist doesn’t play the solo, you’ve got a problem, right? One of the things you get into is realizing that everybody is a contributor and that everybody has to work together. The other thing that you get into with live performance: sketch comedy is a great example of this, is that somebody does something wrong and you have to keep going. You’re in the ensemble and the trombone player misses his entrance, that doesn’t mean that the orchestra stops, right?

Go down to your favorite orchestra–the game I love to play–maybe it’s because I’m a percussionist–I like to sit up in the balcony and watch and look for the time when the percussionist in the back of the orchestra stands up and goes over to an instrument, pauses for a moment, and then sits back down.

They had one note to play and for whatever reason, they missed that note. It happens and you can catch it once in a while, but the orchestra didn’t stop, everybody kept going, right?

How do we work together? How do we compensate for an issue? Soloist comes in and they’re 3 cents sharp, and there’s 100 cents in a half step—that’s enough that you can hear it. The whole orchestra will come up to match it. They will match it so that it sounds good together. Were they right? Were they wrong? We can argue for days about what the right pitch center is so dealing with those ways of coming together and compensating.

I think another area that I was reflecting on a little bit this week too, is recovery. How long does it take in the place where you work to make a decision?

Max: A lot, a long time rather.

Christian: I was brought up in the high school marching band–there’s two counts to recover, that was the phrase, two counts to recover. For all of you math nerds out there, a medium tempo is 120 beats per minute. A fast tempo is 180 beats per minute. Let’s go on the fast tempo from 180 beats per minute, two beats, two counts to recover when you’ve made a mistake is 666 milliseconds, two-thirds of a second, right? Imagine if the people in your engineering organization could make a decision in two counts.

Max: That’d be great!

Christian: Right? You’re in the marching band and a player makes a wrong move and runs into you. Your server just crashed. That marching band is gonna try for two counts, it might take them 10 but they’re gonna be back on. The server crashed and you got a bunch of people sitting in the back going, “Well, I wonder what happened. Is it important? Do we need to fix this now? What’s the right way to fix it?” And that experience in the music world is that “the show must go on.”

I think it helps us weed out alternatives very quickly: make a decision, make the wrong decision, who cares? The rest of the group is also anticipating and working with you, and you’re gonna get there.

That decision paralysis is a problem that entire organizations have and when an engineer is like, “Should I do A or B?” I’m like, “I don’t care.”

Max: Another example I can think of is redundancy. In an orchestra you have, I don’t know, 10 plus violinists?

There’s redundancy. But if a cymbal breaks…

As you go through a performance career in music, you learn painfully the realities of needing redundancy and being self-reliant with redundancy like playing a wind instrument if a reed breaks. You better have redundancy of reeds or else you’re out of commission for the performance.

Christian: Right.

Max: When you get into a tech or engineering team career, you need redundancy of people–if you have only one person with security credentials to access that server that’s down, you’ve got to plan for redundancy of that kind.

Same thing when you have a music gig and that reliable (or unreliable) trumpetist doesn’t show up to your gig, you’ve got to be able to call Joey or what-have-you.

Christian: A guy used to work with, Larry, called it, “We need to protect against bus error.”

I asked, “what do you mean?” From the ’80s, my computer would get the blue screen and it would say, “Bus error,” and it would shut off. And he said, “No, no, no. Modern bus error is Muni hits you while you’re biking to work. You get run over by a bus.” How are we protecting against that? How are we communicating and sharing our information, our designs, our thought process, our work in progress so that when an unfortunate thing happens you can go on vacation? Because somebody else can pick it up.

Max: Sheet music is a lot like code, it is what’s to be performed. There’s obviously deviations from that as we’re all human performers but one of the parallels I can think of with music and software engineering is commenting or annotating your sheet music or your code, although there’s less sharing of sheet music between people so people can see each other’s comments, I guess, but there’s a parallel there.

Christian: I would think of the sheet music more of like an architecture diagram, right? My notes are commenting on how I want to see this architecture through.

The New York Philharmonic has this online archive of marked conductor scores. You can see that like, “Oh, one of the conductors of the New York Phil marked this score this way.” It helped give that conductor what they needed to lead the orchestra–maybe another conductor can learn something from that. If you don’t put that comment out there and you don’t share it we get information silos. That’s what we call them in the tech world.

Max: Is there anything analogous to GitHub in the music world? How do you get ahold of the annotated copy of a score by Michael Tilson Thomas or XYZ Composer? The library?

Christian: The library usually doesn’t have that extra annotation, right. The library usually has clean copies.

So that becomes more of a cult following, how do you track these people down? How do you get a hold of that? Whereas we have the ability and the responsibility as developers to make that information available.

We’re not building job security by not commenting and not annotating and what-have-you.

I think, actually, one of the things I think it was David Keiras, one of my C professors in college said, “Each line of code that you write will have to be read and understood at least seven times in its lifetime, to fix bugs, to make enhancements about it, just maintenance.” And interestingly in my career, I’ve probably been the one who had to read it four of those seven times, right.

If I can do something today that makes me a year from now save 30 minutes…and it saved 30 minutes four different times, there is two developer hours coming from taking a moment now when I’m thinking through the problem and writing it down. When I’m learning a piece of music I take notes so that the next time I come back to it, whether it’s tomorrow or a month from now or whatever: “Oh, right.” That’s how I approached it.

Max: Is there a parallel of sorts to technical debt where there’s compounding costs from making mistakes early on in music composition or seeing music for the first time?

Christian: Sometimes the composer writes and says, “Okay, you need these 10 instruments,” and so I think, “Okay. Okay, I’m gonna arrange these instruments this way and learn the piece.” Then I put the piece on the shelf and a year later I come back and go, “How did I have those drums arranged?”

It’s taken me some time to learn, “Oh, wait. When I’m doing a piece like this, draw a diagram.” Actually, nowadays, “Take a picture,” and then figure out how to get that with the score. Come up with a way to keep track of that so that when you come back to it…if I’m learning something and don’t take good notes while I’m learning a piece of music, that’s my technical debt.

Max: Dialing back timeline-wise, do you mind telling our audience a little bit about how you got your first software engineering job?

Christian: I did one of the classic “I got an internship,” and then they let me come back for a second summer and then they hired me in. But what was interesting here was that I had sent my resume off to a handful of companies.

I had sent my resume to a handful of places that a mentor friend of mine suggested. And I think two of them ultimately responded and only one of them bothered to even do a phone screen.

But what was interesting here that I learned much, much later–I think it was after I was a full-time employee when my resume came through–the onsite recruiter passed it to the engineering team and the engineering team was like, “No, no, no, intern” But the QA team was like, “Yes, please!” And I got an internship on the QA tools team.

Max: Who was this employer?

Christian: This was CoManage Corporation. They don’t exist anymore. They were bought out many years ago, but they were in the telecom industry, and they had some products that were helping telecoms understand what hardware they had that wasn’t fully utilized. It was kind of cool, they helped Sprint. Sprint installed the software in one of their locations and found 10 times the cost of the software in unutilized equipment in the first day.

Max: Wow.

Christian: Because telcos are notoriously bad at keeping records. Phone services are constantly being changed and upgraded and moved, and the technician, goes in and finds an open port and plugs something in but doesn’t write it down.

Max: This is a common pattern we’ve seen, actually, with guests of ours is that first job isn’t necessarily as a software engineer but it might be on the QA team at a company that heavily depends on software or software product.

Christian: There are some people who poo-poo the QA team. And they’re like, “Ah, they’re just the QA team.”

They are more important to me than the development team sometimes—they protect me as a developer, right. They make me look good by finding the crap that I wrote before it gets out in the world.

Max: And for our audience that doesn’t know QA, QA is “Quality Assurance” so that gives a lot more context to what Christian is saying.

Christian: Right. Yes, they’re helping me as a developer make sure that my code is great. But the other thing that I think working on in a QA department is it further gives that perspective of taking great pride in not handing off code that I haven’t validated.

My least fun late nights almost always involved cursing out another co-worker who committed code that they clearly didn’t run because it either doesn’t compile or it crashes on launch.

Having dealt with failed performances, having worked in a QA department and really understanding that it is my responsibility to make my code solid is always a tradeoff.

Max: Starting your career on the QA tools team, did you find that as you moved on in your career and encountered more teams that you were a member of, that you had an advantaged perspective in knowing all of the various tricks-of-the-trade for QA and being able to deliver–relative to your peers–a more reliable output as a software engineer?

Christian: I guess the question in my mind that I’m thinking is, how much of the testing and verification mindset comes out of having experience there, having experience with auto-graded coding assignments in college, or having experience with failing at performing.

Somewhere between those three things I think being involved in QA and understanding some of the how’s, probably was helpful in putting those to practice.

My level of OCD, I’ll call it, probably started a long time before then and my parents tell me all the time, I would take everything apart and then try to put it back together. I think that that mindset from being a six-year-old still exists, that I take my code apart and put it back together.

At the same time, I feel like I have learned how to take it apart and put it back together pretty quickly and that’s one thing too, is that I don’t get lost in it. That’s another area that some engineers have a challenge with: “Well, of course, I could write better code but you didn’t give me enough time. I don’t have enough time for that. No, I can’t write it that fast.”

Almost never is that true, and that is a skill and it takes practice.

“It’s never done, it’s only due. “

I performed a piece two weeks ago. I’m still practicing it because I’m not done with it. I can perform it better perhaps the next time. So my piece of software, it has a due date. How good can I make it for that due date? And what is it that I did in the past that I can leverage to write better tests?

Max: Having been a hiring manager, is being a musician a criteria that you pay attention to with job applicants?

Christian: There’s a blog post Rands in Repose—he has a blog post called “A Glimpse and a Hook.” A friend of mine pointed me to this blog post about how he reads a resume and I’m like, “Oh my God, is he sitting behind me right now and just writing down what I do?”

I’ll read the first line [of the resume], and then I go to the bottom, and then I come back to the top. I don’t necessarily look for, “Are they a musician?” Give me three resumes that are identical except for the bottom and that’s going to make a difference.

What do you do outside of engineering? What do you do that makes you a whole person? Because as we said at the beginning, there’s the artistry of engineering and that artistry is important to me. And whether you get your artistry because you are involved in something that’s literally the arts or maybe you’re really into some sort of a sport or something outside of engineering really just that that is there.

Max: So is that an important part to people’s resumes–that last few lines of a resume hinting at people’s extracurricular interests?

Christian: It is to me. Now, I’m also not your… I don’t know that that’s advice that carries to other people.

I also do not anymore do live coding interviews. I don’t do it. It’s not real. It’s not real, right. What I want to know is can you solve a problem.

I have done take home [assessments] because nobody does well when you look over their shoulder.

Max: Proctoring is really rough on the process.

Christian: Yeah. I also don’t believe in an eight-hour interview.

I would rather have you meet multiple people in a group setting–which some candidates probably found intimidating–but I try to warn them. I’m like “we’re gonna only have you in the office for two hours but you’re gonna meet eight people, right? You’re gonna meet four people, and then four people, and maybe you’ll have a couple of one-on-one moments in there.”

But meet a bunch of the team, and then instead of sitting here for another six hours talking about things, I’m gonna send you home and say, “Don’t spend more than two hours on this. I do not expect a complete solution. But take a look at this problem.”

Max: We should definitely have an opportunity to give you a chance to plug what you’re doing at Little Mission Studio and your personal practice as a consultant of software engineering.

Christian: Little Mission Studio, we’re here in San Francisco and we’re bringing high-quality lessons, group lessons and private lessons to people of all ages. What we have found that’s really interesting in our student base–we’ve been in business for three years so far and nearly 50% of our student base is adults. So I’m here saying hey, the creativity and the artistry and these experiences and recovery and being able to put a performance on–they all relate and I think they relate to more than just engineering. I think they relate to many aspects of life.

What has really been encouraging is that there is a population in San Francisco who sees this and says, “As an adult, it is important for me to pursue creative things. To pursue things that make me think in a different way than maybe my day job does.”

Then in my engineering world, I’m working some with a friend who he’s based out of Chicago right now. I’ve done some work with him in the past and he’s doing restaurant management software.

Max: But by and large people can get a hold of you via the internet. We have a comment section which I’ll forward any comments or questions you guys have for Christian.

Two things I wanna plug real quick myself are: sign up for our mailing list, which you can do on our website. Subscribe to the YouTube channel and by all means, comment on our interviews. All of our guests that we have are happy to answer you guys’ questions and whatnot!

Thank you for joining us, Christian!

Christian: Absolutely.