Tag: Programming

on by

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.

Photo credit: Nancy Morla

What is your current programming and musical life?

→ I’ll start a front-end bootcamp next week. Aiming at cybersecurity once I have enough web dev experience.
→ I was a studio musician on occasion before the pandemic. Nowadays I’m a music reviewer, curator and marketer at a record label, and I play my instruments in my free time.

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?

→ Viola. I started at 16, but had been playing the violin since I was 9.
→ I started taking piano lessons at 17 and kept at it throughout my college years.

What was your experience of learning a musical instrument, and how did it differ from your experience in learning to program?→ My learning process for musical instruments wasn’t that self-aware in the beginning. The meta-cognition required to make practice sessions more efficient started developing at about 17, but only consolidated during my college years. At that time, I learned things like:

• Documenting and tracking my progress.

• Working in sync with my body and mind, and not against them (best times of the day to practice, the importance of rest, mental practice etc.)

• Approaching challenges/errors as a laboratory of problem solving instead of mindless repetition

That very meta-cognition was a game-changer when I started learning to program. Making progress tangible is a great way to cope with frustration. Things feel difficult, but doable.

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

→ I was 26 and really interested in electronic/algorithmic composition. So I chose to do my master’s degree in those fields. There was a natural need for automation in them, so I learned languages like Pure Data, LISP, and SuperCollider.

Do you have any specialisms in your musical performance?

→ Not really. I was an orchestral musician back in the day, but I decided to focus more on composition.

Do you have any specialisms in your programming?

→ I’m still a beginner in web dev, so I haven’t specialized on anything yet. A lot of focus on JavaScript right now, though.

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

→ Bachelor’s in both viola performance and composition. Master’s in composition.

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

→ Playing in ensembles and orchestras gave me team skills that I’ll probably make good use of as a professional programmer.
→ Things like discipline, patience, and tolerance to frustration are inevitable parts of a musician’s life. They’re transferable to any career, but programming needs lots of them.
→ Algorithmic composition has a good balance of creativity and logical thinking. In a way, I was already thinking like a programmer before learning any languages. But programming really helped me develop my own style as a composer.

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

→ Foreign languages
→ Salsa dancing

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

→ If you’ve developed the mental toughness to become a professional musician, you already have a lot of what it takes to be a programmer.
→ Your brain is probably more trained to think like a programmer than you realize.

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

→ Don’t freak out so much about the math part. Everything can be re-learned through the meta-cognition tools you developed as a musician.
→ Don’t wait so much to take the leap. You’ll never be “100% ready”.
→ Find a community as soon as you can.

More Info

on by

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 Platform.sh 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

on by

Pair programming is a hot topic these days — everyone knows it leads to better code — but it’s also one of the most difficult things to do. At Makers Academy, where I learned to code, we only did pair programming , so here’s my two cents worth of advice for being a great pair partner.

For newbies to pairing, the most important is to understand the driver/navigator roles. The driver is the one typing the code, the navigator sits back and researches, proofreads, and maintains a global view of the code and the project’s direction.

1. Recognise that pairing is hard
Pairing is an intense relationship, summoning all your powers of ingenuity, communication, humour, and code. If you find it hard, or even just tiring, it’s because it is hard and tiring sometimes. But you can also make it easy with the right person and the right set of practices.

2. Listen more than you speak
I guarantee if your focus is on listening more than you speak, the result will probably be a 50/50 split. Most of us love to focus on our own ideas without really being present to the person next to us.

Listen actively: listening doesn’t mean you’re silent but inattentive. It’s a very powerful act requiring your full attention and presence to take in what the other person is giving you.

Exception: if you are very quiet generally, you may in fact need try to speak more than you listen to get that 50/50 split.

3. Ask questions — don’t command
Bad: ‘Assign that variable to equal “potato”.’
Good: ‘What do you think that variable should point to?’

Questions make your pair think and open a dialogue. Telling them the answer just makes you look superior.

4. Switch roles every 25 minutes
This is probably the most important skill! It’s easy to be a keyboard hog, and it becomes really annoying for your pair to have to request keyboard control. Every 25 minutes is a fair split, and it will keep you from getting in a rut.

5. Take regular breaks
And make them good breaks! Play music, meditate, go into the garden…do NOT code without your partner in the breaks! You’re in this together.

5. Give feedback
Ouch. This is hard. But so worth it. Full disclosure: I’m bad at giving helpful and kind feedback, so I’m not going to offer much advice here. But a good one to start with is 1) what went well 2) what can we improve for next time

6. Don’t pair 100% of the time
Like I said, pairing is intense. You’ll need some alone time to code so make sure you get that too.

7. Don’t interrupt
Interrupting == you weren’t listening. I don’t mean the kind of interruption that takes the other person’s idea and enthusiastically expands on it. I mean the kind of interruption that abruptly changes the topic of conversation. This says that you don’t value your pair’s opinion.

8. Say yes
In the time it takes to discuss whether it’s worth trying something, you can often just do it. Saying yes creates a positive atmosphere where your pair is respected. Arguing about it is just, well, arguing.

9. Be mindful of your body language
Is your back to your partner? Is your computer screen angled away? Do you never look at them? You want to create an atmosphere of inclusion so your pair feels respected and welcome to comment.
​​

​
10. Give high fives
Just completed a mother of a mission? High five! You go through the lows together — make sure to celebrate the highs.

Have some more suggestions for great pairing? Comment or sent a tweet my way!

​Keep your eyes peeled for a post on remote pairing!

And want a little laugh? https://www.youtube.com/watch?v=dYBjVTMUQY0

on by

10/7/2017

Pair programming is recognised as a way of writing great code, but can remote teams do it?

Absolutely! I did my entire Makers Academy course remotely and I paired remotely everyday. It definitely has some benefits over in-person pairing and I think it’s a great way of working.

If you haven’t already, read my article 10 Tips for Great Pair Programming — this post assumes you’ve read it. The most important tips from that article? Swap driver/navigator roles every 25 minutes and listen more than you talk.

The main difference with pairing remotely is that you have to be a bit more intentional about your communication. Here are my 5 tips for communicating well virtually.

1. Use your camera
The major drawback of pairing is that you lose body language communication. You can in large part make up for this by turning on your camera and making sure your pair’s camera is on. I like to use Zoom for pairing as the screenshare/camera work well together.

2. Check in with your pair
Before you start working, make sure to ask your pair how they’re doing — the same way you would in person. Maybe even have a virtual cup of coffee together in the morning!

3. Take good breaks
This is one of the major benefits of working remotely — you’re in your own space so on your breaks you can easily meditate/pop outside to the garden/do your laundry.

4. Create a dummy branch
Swapping driver/navigator roles regularly is critical for healthy pairing. If you’re concerned about pushing experimental code to git, create a dummy branch that you can push to in order to swap your possibly embarrassingly rudimentary code — then you can start using the real branch when you have passing tests.

5. Virtual high fives
Totally a thing. The key is to slap the camera (almost) with one hand and slap your thigh with the other to get the sound. If you want a slightly ironic high five, you can facepalm at the same time.

on by

Re-“Makering” Your Life

7/14/2017

I had a great chat yesterday with the new Makers Academy remote cohort, discussing feeling inadequate, strategies for learning, how soon to send a CV to employers, and myriad other topics. This morning I found myself reflecting on how I used Makers not just to learn to code but to reset my life.

A bit of background: my previous job was as a professional violinist. I was doing a lot of international touring, working as a freelancer. This was stressful because of the constant travel (between November 2016 — January 2017 I was in ten countries on 3 continents), the uncertainty of a freelance income, and the inability to plan downtime.

The intense experience of Makers forced me to look at my life and understand where I received sustenance; to make sure I was getting enough sleep; to develop patterns that made me a good coder but also a joyful human being. So I decided to seize the opportunity to use my Makers experience to set healthier boundaries between my work and personal life. ​

Here are six things I did that helped transform my life:

1. Resist peer pressure to overwork
I remember vividly coming back from a five-minute pomodoro break and asking my pair how his break had been. He said, ‘Oh it wasn’t much of a break — I spent the time researching.’ I’d gone into the garden and smelled some flowers. Guess which of us was better prepared​ for work? As the course went on, my cohort challenged each other to take healthier breaks: play music, take photos of bees, read Stack Overflow’s programmer jokes page.​

2. Ask yourself what’s the best thing you can do for your learning
For me on the course, if it was during lunch or after 6pm, the answers included:

  • Go to the gym
  • Take a walk
  • Call my friends/family
  • Go to the pub
  • Read some fluffy fiction
  • Colouring-in​

Only on two days during the course, both at the final project, did I do any code in the evening. And to be honest, one of those nights I was just sitting watching my teammate code because I wanted to be social.

And one memorable morning my pair and I were too knackered to do the diagram workshop, so we did a hip-hop Bollywood dance workout instead.

The answer to this question will be unique for everyone but it’s really important to ask it and understand that the answer may very well not be ‘write more code’!

3. Don’t compare yourself
Rather than looking at what the other people in the course have done, ask yourself these two crucial questions:

  • Am I a better developer than I was yesterday?
  • Am I having fun?

If the answer to those questions is ‘yes’, then you are doing just fine.
​
A great way of being able to figure out the answer to those questions is to use the pomodoro technique and at the end of each pomo, write down what you did. You will be surprised and happy to realise how much you’ve learned, even as you’re struggling and frustrated.

4. Ask your coach or Dana if you’re worried about your progress
One of the most difficult things for me, especially at the beginning of the course, was not having much awareness about what I didn’t know and how I was progressing. Was I learning enough, not enough, pushing myself too hard? It’s impossible to know this as a newbie coder, but as adult beginners we are keenly aware of a vast skills chasm.

So talk to your coach if you want to find out how you’re doing — but be warned, have specific ideas (i.e., I struggle with ‘attr_readers’ and ‘instantiating objects’). The act of having that conversation with yourself is in fact a really valuable part of learning, reducing the terror from ‘Oh my god, I don’t know anything’ to ‘Here are three specific things I don’t know and can I get some help learning them’.

If you’ve done that and you’re still full of anxiety, talk to Dana. She will help — and not by patting you on the head and saying you’re great but actually by helping you discover these thoughts that are tearing you down and realising that the reality is a lot kinder.

5. Be kind to yourself
I can’t say enough how brave you are for doing the Makers course. Taking three months off work is difficult! You will struggle. You will be frustrated. But that’s such a good thing — it means you are being stretched, that you’re growing. Lots of people talk about making big changes in their lives, but you’ve actually had the courage to go for it. Remember that, and be proud of yourself when the going gets rough.

6. Ask yourself what’s the bravest thing you can do in that moment
Maybe it’s meditating instead of smoking. Maybe it’s shutting off the computer and reaching out to a friend. Maybe it’s admitting your vulnerability. Maybe it’s asking the ‘dumb’ question that’s actually on everybody’s minds. Maybe it is writing more code! The answer will look different for everyone, and will change frequently. And if you’re really comfortable with your pair, you can ask them this question too.

And if you feel like sharing, tweet me at @FiddlersCode with #BraveMakers and let’s all celebrate these moments!