What is your current programming and musical life?
Current programming life is as Senior Architect for Panther Protocol, which is a project to bring privacy and trust to the world of blockchain and DeFi (decentralised finance). This involves a lot of research and design, plus some coding in TypeScript, Solidity, and Circom which is a DSL for writing Zero Knowledge Proofs. Musical life is relatively quiet currently due to the pandemic, but recent/upcoming gigs include playing with the London Tango Orchestra, Classico Latino, and the Monika Lidke Band (jazz/folk crossover).

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?
Primary instrument is cello, and I started around 7 years old. I probably started tinkering with the piano around 4 or 5, since my mum is a piano teacher.

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

I also started coding at 7, in BASIC on a Commodore Pet 4000 at my friend’s house. I was immediately obsessed – difficult to know exactly why, but I guess it was the satisfaction of creating something new and seeing it immediately come to life, combined with the extremely rational mental models involved. Learning music felt very different at the beginning, and it probably wasn’t until I experienced ensemble playing that I felt a strong attraction to it.

Do you have any specialisms in your musical performance?

Music specialisms include being a multi-genre cellist (jazztango, Latin, folk, classical etc.) and having an excessively nerdy obsession with various aspects of music theory (especially harmony).

Do you have any specialisms in your programming?

Specialisms in programming include Free/Open Source, Linux/UNIX, shell, Python, Ruby, infrastructure software, virtualisation, orchestration, high availability, cloud, automation, git, Trusted Execution Environments, blockchain, digital asset custody, and Zero Knowledge Proofs.

Do you hold degrees in music, computer science, or something else?
I have a degree in Maths & Computation from Oxford, and a postgraduate in performance from RAM in London.

What influence, if any, does your musical background have on your programming, and vice versa?
My musical background probably infuses my tech career with playfulness, (probably an unhealthy degree of) perfectionism, and emphasis on collaboration.

My tech career arguably brings a more analytical and methodical approach to my music-making, or maybe I would have been that nerdy even if I only did music.

Aside from music and software, what other hobbies or pursuits do you have?
Other hobbies include tango dancing (hope to resume post-pandemic), running, cycling, swimming, yoga, meditation, travel.

What would you say to a musician considering a career change into programming?
To those considering a career change I would say, you can (and probably should!) take up programming without giving up your music! Both are incredibly creative pursuits which complement and enhance each other wonderfully.

And finally, what advice would you give your younger self when you started programming?
To my childhood self, I wouldn’t say much since I had so much fun programming! To my undergraduate self I’d say to ease off the video games, go deeper into computer science studies, especially the really juicy stuff like algorithm design, cryptography, protocol security… oh, and that social network website thing we built in 1996 or so? Definitely think about putting some more effort into that, it might attract a bit more interest some day…

More Info

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

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

Who is this post for: bootcamp grads who didn’t receive instruction on testing in their course
What does it cover: an overview of the types of testing you should know about, along with links to further resources

Congrats on graduating from your bootcamp! Just when you thought your brain couldn’t get stuffed with any more concepts or ideas, welcome to the wonderful world of TESTING. This blog post should get you started with some fundamentals. Good luck!

Before we dive into testing, there’s a mindset shift you need to make. When you are learning at a bootcamp, you are working at a very small scale. You don’t need to consider things like application load, test performance, pipeline execution time – you just want it to compile and run. But once you get into professional software development, scale is probably the biggest difference: we have over 4000 tests for our backend system alone. Test execution time is something we care about. Once written, an automated test can provide value for years. So part of understanding a good test strategy is understanding the scale and the timeline of an enterprise project. Now on to testing!

What is testing? Testing really means “automated” testing. Manual testing is something we avoid as much as possible because it’s not scalable or reliable (humans make errors). Testing is a critical skill for modern software developers, and most importantly, it’s often the differentiating factor in whether your tech test will pass.

What kinds of testing are there? Broadly speaking, there are 3 main types for you to worry about now. These types are in the testing pyramid below:

Pyramid of Automated Tests

Unit tests are the foundation layer. This is where you practice the famous test-driven development (TDD). We like unit tests because they are fast to run, don’t require complicated setup, drive good code practices, and give quick feedback to the developer. Not sure what to test? Start with normal, boundary, invalid and extreme testing.
Resources:
The Test Pyramid
TDD By Example by Kent Beck
Growing Object-Oriented Software, Guided by Tests by Steve Freeman and Nat Pryce
Secure by Design by all the Dans. This book is highly readable and will help you with design and testing.

Integration tests (also called service tests) test the communication between different parts. You don’t want to check details of logic here because these tests have a more complicated setup and are slower to run.
Resources
– Integrated Tests Are A Scam

Acceptance tests (also called end-to-end or E2E) tests for web apps usually through a browser (sometimes headlessly, sometimes not). They are attractive because you can see the interaction, and they are unattractive because they are SLOW and notoriously unreliable – if your network speed tanks, the test could fail because it looks for a button that hasn’t turned up. Basically you want to avoid these as much as possible, but they do have value.
Resources
Cypress testing framework

Bonus test types
As a junior developer, you probably won’t need to worry about these types of tests, but it’s good to know!

Load testing: how does your application behave when stressed, such as receiving too many requests at once or a request with a payload that’s too large to handle.
Resources
https://www.guru99.com/performance-testing.html

Penetration testing: this is normally done by a 3rd party security expert. They are looking for vulnerabilities in your application.

Image by Niek Verlaan from Pixabay

You’re a junior developer, you have your first tech test, and you want to impress the potential employer. Here’s how.

README
This is the first thing I look at. Your README should have:
– the specs (what the problem is you’re trying to solve)
– instructions to run the code (assume I will clone the repo – then what should I do?)
– any explanations you want to give for why you did things
– further refinements / features you would add given more time

Git Usage
While there have been other version control systems, git is industry standard now and I’d expect to see it on any tech test.

.gitignore
Even if it’s blank (and it won’t be if you are using npm packages or an IDE), it shows you’ve thought about what needs to be committed to a git repo and what doesn’t.

Commit History
This is a more controversial one, as looking at my own history, I see the occasional gem such as “3312: make code less manky”, and I’d hate for people to think every commit message has to be a work of art. However, a good commit history can show your thought process and your collaborative skills – what happens when you win the lottery and I have to take over your project? First thing I do is look at the commit history as a summary of what you’ve done and how you approached the project.

Code Analysis
I want to understand how you’ve thought about the code. In particular, I want to see:
– code coverage (SimpleCov for Ruby, for JavaScript use Jest’s built-in –coverage flag or Istanbul/nyc)
– linter (Rubocop for Ruby, eslint for JavaScript)

Testing
The first part of the code I look at is your tests. Poor test coverage is an immediate cause for rejection. In addition to 95% or higher line coverage (there is a law of diminishing returns so don’t worry about getting it to 100%), I also want to see:
– boundary test cases: if you’re working with numbers, have you tested one above and one below your highest/lowest number? Or if working with text, have you considered whitespace before and after the word/characters?
– error handling: particularly in dynamically typed languages such as JavaScript and Ruby, what happens if the calling code gives the wrong type of input, or no input, or too much input? E.g., if you have a function to multiply two numbers, what if one of the inputs is a string? (Side note, this is why I prefer statically typed languages, which specify a type and will fail to compile if the type is wrong!)

And finally, do yourself a favour and learn TDD. It will solve most of your test and code problems. Kent Beck’s book is a great place to start – it’s in Java, but you can translate as you go to the object-oriented language of your choice.

Code
The last thing I look at is for your code. And the first thing I look at is whether you follow Sandi Metz’s Rules for Developers. While they might not always be relevant in production, real-life code (although they often are!), there’s generally no reason that in the artificial environment of a tech test you can’t follow these rules. And in fact, you should also apply these rules to your test code.

Then, when I’m looking at your code, I’m thinking, “If there is a bug in this code on Friday at 4pm, will I be able to understand clearly what’s going on or will I be tearing my hear out?” In other words, does it communicate its intention clearly? Code does this by:
– short methods that do one thing only
– methods and variables that are named according to what they do (if you have a method that is called getResponseFromServerAndComputeFunction, that method is too long and doing too many things)

Immediate Rejection List
The following will guarantee you an immediate rejection from a lot of reviewers, myself included:
– no README. We are busy and don’t want to use a crystal ball to figure out what we’re supposed to do
– no tests or poor test coverage
– not using git or all code in a single commit

And finally, I want to clarify that this is my personal list, heavily informed by my training at Makers, coding best practices, and my experience as a professional developer. Not everyone will have this same list and I also try to approach each candidate with an understanding of their individual circumstances.

Good luck and let me know what you think in the comments!