This is part of a series getting to know the people in the MusiCoders Slack group who are both professional musicians and professional software engineers.

What is your current programming and musical life?

I think of my working life as a 50/50 split between tech and music. I clearly can’t do as much as a full-timer in either field but I find dividing my time interesting and refreshing.

I work for as a staff engineer, designing and writing web API services, scripts and tools (in Go and PHP). The company originated in France but it allowed remote working from the beginning, and has developers all around the world.

I’m also the second violinist in the Ligeti Quartet (since 2010) and I do some freelance work in and around London – mostly chamber music, orchestras and sessions.

What is your primary instrument and what age did you start learning it? Did you study any other instruments, either as a child or an adult?

I learned violin and piano from the age of 7, and violin took over at university.

What was your experience of learning a musical instrument, and how did it differ from your experience in learning to program?

Learning music was very structured. In music you often go to a 1-1 tutor every week from an early age – imagine if you had that for programming! Maybe people do these days. I learned code by writing it and looking things up every step of the way, first via books and later via Google.

How old were you when you started programming? Why did you start programming?

My dad taught science and computing in my school. So I started probably around 8, first doing silly things in BASIC, and then a bit later making websites in HTML and a bit of C or Perl, and later PHP. Many tables were involved. It was a hobby until late in my degree when I started doing it for money too.

Do you have any specialisms in your musical performance?

Contemporary string quartet music. The “contemporary” part is not a genre, it usually just means the composer is still alive, and rehearsals are often a collaboration or at least a discussion. “String quartet” is also not a genre but it does seem to be a particularly complex and rewarding occupation. I studied a bit of Baroque violin and I love that music but it hasn’t featured in my professional career.

Do you have any specialisms in your programming?

Backend web development. Mostly this involves designing and writing API servers and clients. I currently work in Go, PHP, a little bit of Python, a tiny bit of JavaScript, and plenty of shell scripts. Like any developer I enjoy new, greenfield projects but I have done a lot of work on preserving backwards compatibility for “legacy” APIs and tools.

Do you hold degrees in music, computer science, or something else?

An undergrad degree in Music followed by two years at a conservatoire.

What influence, if any, does your musical background have on your programming, and vice versa?

Musical work is often really independent, and I like to think that makes me a more self-directed programmer than I might be otherwise. I’m comfortable with not being able to understand something, and with learning by doing. In the other direction, I think the business and project management ideas I’ve learned from tech are quite helpful in music – what to do and what not to do. And it really helps in both fields to know how to use a spreadsheet.

Aside from music and software, what other hobbies or pursuits do you have?

I have a toddler and that’s plenty for now.

What would you say to a musician considering a career change into programming?

I still do both, so I might not be the best person to ask. I think getting into open source can help; it means you can learn how to collaborate with other developers before you even have a job, and those collaborative “soft skills” are the most important ones.

Both of my careers can be wonderful and really hard on different days. But the killer feature of the tech industry is the potential for ultra-flexible remote work.

And finally, what advice would you give your younger self when you started programming?

Slow down – take a little bit more time to design and research first, and write tests, and leave the code a bit later. But also, feel freer to venture into technologies you’re unfamiliar with, it never takes as long to learn as you think.

More Info

We’ve got an exciting year ahead of us in the Cambridge Philharmonic. Not only do we have a great season of concerts, but we’ve introduced a learning & development plan for the string section as well.

A blank notebook on a wooden desk.


  1. Improved intonation on tonic and dominant chords.
  2. Playing in the same part of the bow as the front desk

We will be releasing more video and written content throughout the year relating to these goals as well as holding special workshops.


We will also be releasing a series of eight short videos covering the following topics:

  • Introducing Goal 1: Tonic and Dominant Intonation
  • Introducting Goal 2: Playing in the same part of the bow as the front desk
  • Orchestral practise tips for busy people
  • No accidental bow noises
  • Whose fingering to use?
  • Quick page turns
  • Passing messages back
  • Essential stringed instrument maintenance


One of the techniques we have learned from the software industry is to have a post-concert retrospective where we ask questions like

  • “What went well?”
  • “What could have been better?”
  • “What should we do differently next time?”

The answers to these questions are then used to guide the preparation for the next concert.

What’s next?

Keep an eye on the YouTube DeskNotes playlist, this blog and social media as we will be releasing the videos Saturday mornings at 10am starting 7 September 2019.

Cambridge Philharmonic Twitter

Paula Muldoon Twitter


I’ve recently rocketed my music setup into the 21st century and I thought I’d share with you the tech I’m using now!

Tablet & Stylus

Essential for reading music. I use the iPad pro 12.9″ with the Apple pencil. 

  • Save the trees — no more printing music
  • Easy to mark up in different colours
  • Also easy to erase — no more residual pencil marks
  • Easy to read in dim light
  • Entire music library in one lightweight tablet (yes, they are light now)

Learning curve:

  • None, really


Must-have to turn the pages. I use the Donner (


  • No more difficult page turns


I use a midi keyboard to input notes into Musescore. Great for composing quickly! Doesn’t do rhythms but the pitch saves you a lot of time. Really portable as well — took it on a transatlantic flight iwth no problem.

I use M-Audio Keystation Mini 32 II, Compact Portable 32-Key USB/MIDI Keyboard Controller with Synth-Action Velocity-Sensitive Keys (


  • Easily plugs into MacBook
  • Draws power from MacBook
  • 32 keys but has a big range as you can hit the plus or minus button to move your octave around

Modacity — Practice App


I use this app every day with my practice and I think I’ve barely scratched the surface of what it can do. Shoutout to Andrew Hitz at The Entrepreneurial Musician podcast for introducing me to this!


  • Make practice lists
  • Record yourself easily
  • Metronome/tuner
  • Tracks time spent practicing
  • Tracks practice streaks

ForScore — for reading music

I got this app several years ago for reading music, back when it was half the price. Not sure I’d buy it now as there might be cheaper alternatives, but I’m very pleased with it nonetheless.

PiaScore — IMSLP app

Great for downloading music from the wonderful free IMSLP library.

Musescore — for composing

Like Sibelius, but free. I compose on my MacBook Air but there is an iPad app as well which I haven’t tried.

Originally published in April 2017.

The view from St John’s College, Cambridge — taking a tea break from a rehearsal

This week 3 blog is coming out in week 4 because I turned a corner in coding this week: it was the week I started preferring to write code over blogging.

This may not seem like a big deal, but it is — I LOVE writing and for the first two weeks, I would have much preferred to write about my coding than to actually code. Now it’s reversed, and although I still love writing, I’m actually kind of irritated that I’m writing now instead of coding.

But I think it’s also really great to document what’s going on, so here goes.

My week 3 experiences:
1. It was much easier than week 2 — I was able to put into practice a lot of what I’d learned in week 2 and it all made sense.

2. Each day is so full of new coding knowledge — I was looking back at week 2 programs and they seemed laughably simple. This is encouraging, because at the time, they felt hard.

3. I was pretty disciplined about not working too hard! I know the course is about to get intense, so I made sure to get all the work done that I needed to do, but I also made sure to enjoy walking around, getting time in the sun, and chatting with friends. All of this is really important to give my brain time to rest from all of the intense learning I’ve been doing.

4. My FitBit is still great — it’s making me walk more, and walk the long way round to things, just to get in all those steps.

5. My violin recital went really well! It was super fun to play my own piece (Yankee Doodle Variations for Solo Violin, which I wrote last summer after an ice cream truck drove by my house every day for two months playing Yankee Doodle) and, despite not having played a solo recital in a few years, I wasn’t nervous at all. My pianist Tim was great to play with and we’ll definitely play some more recitals. So it’s wonderful that I will still be playing violin for fun as I become a programmer.

6. Also in violin/book news, I did 8 hours of recording sessions on Saturday in London. My train was quite delayed so my planned 20-minute excursion to Daunt Books en route to Air Studios at Belsize Park had to happen in three minutes. In a beautiful meta-comment, I bought a book on split-second decision-making (“Blink”, incidentally the title of one of the scariest Dr Who episodes). The only problem is that I am now reading eight books simultaneously, all of which are fascinating. Need to focus!

Ok, now I think I have earned some coding 🙂


The lush grounds of Madingley Hall, where I played my recital and also had an excellent roast lunch.

I’ve been thinking about how my violin skills can help (or hinder!) my programming. Thanks to over twenty years of musical training, my brain is programmed to do the following:1. Search for patterns. 
2. Pay attention to minute details.
3. Process multiple streams of information​, mainly aurally but also up to about eight different written inputs, and also visual signals from a conductor (including deciding in a split second whether the conductor’s input is useful or not!).
4. Execute the results of the “program” (i.e. the written music) in a timescale, in a coordinated effort with up to 80 other people. Execution means a) choosing which of four strings, four fingers, and roughly eight positions (which I believe is 128 possibilities, but someone correct me on the math if not; and bear in mind there is generally more than one way to execute, so this split second decision also factors in stylistic and other concerns). Furthermore, I have to understand and implement the duration of a note, both in a strictly metronomic sense and also accounting for any flexibility someone else in the group may decide is expressive.

Consider the following piece of music, one which every violinist will know by heart.

​Lots of different rhythms, pitches, all sorts of variables to be executed rapidly, accurately, and in coordination with a large group of people. Seamless integration of all the different streams of information is child’s play to an experienced violinist at the top of her game. Even a less familiar piece rapidly sorts itself out into patterns that my brain recognises and executes.

Now consider this screenshot of the command line:

Two colours (different colours, but neither one uses colours to indicate anything)
Text reads from left to right and top to bottom (except when the command line lists files, which it does in columns)
Details make all the difference — a missed “ . “ in coding can stop a program from running while a missed “ . “ can mean an incorrect note length.

Command line has no timescale

When reading music, I observe the following sequence:
1. Glance over the whole piece to get an overview
2. Mentally note any difficult spots
3. Play the piece, reading each line from left to right while keeping my eyes at least one measure ahead of where I am currently playing (this requires short-term memory to be functioning!)

When reading the command line, I find I often forget step three. It’s frustrating how slowly I read code — I’m used to reading music very quickly — so I try to solve problems using just steps 1–2 without really going through each line. So my next challenge is to accept that for a while I’ll be slower at reading code but that the time invested in learning to be really fluent will pay off later.