In my spare time, I help classically-trained musicians like me transition to software developers. One of them recently asked me, “I don’t have £8k to spend on a bootcamp. Can I just teach myself to code?” Here’s my answer (disclaimer – I’m a bootcamp grad so this is not first-hand experience).

Yes, you can learn to be a developer without going to a bootcamp (or getting a CS degree). I know this, because people have done it. So let’s discuss what a bootcamp does, and how you can replicate that yourself.

A good bootcamp should give you two things:
1. A structured learning environment
2. A foot in the door at job interviews

Let’s talk about the structured learning environment. Writing software professionally generally involves working as part of a team. This almost always means using git, creating pull requests, reviewing code, writing documentation, and can also mean working in a sprint schedule, daily standups, and pair programming.

Because you do a bootcamp with other people, you have a built-in team. Different bootcamps do this in different ways – at Makers we paired daily and then had group projects in later weeks. This meant that we learned to use these critical software skills like git and were comfortable especially with pull requests and reviews.

The structured part is more obvious – you pay money to someone to create structure for you. Can you create the structure on your own? That depends on your own motivation and discipline.

I’m considering the course content as part of the “structured learning environment” and I won’t delve deeply into it here. But figuring out what to learn (as opposed to how and where) is its own challenge!

So let’s talk about job interviews. Bootcamps usually have relationships with companies and can get you past initial screening. This (in my opinion) is one of the most important things about a bootcamp – what sort of job can they land you afterward?

The good news is that you can network on your own as a developer by attending meetups, communities such as CodeBar, joining Slack groups devoted to topics you’re interested in and getting active on Twitter. (And in fact if you’re attending a bootcamp, you should do this anyway.)

And once you’ve learned a bit of code, probably the best way to build your portfolio, experience, and network all at once, is to contribute to open source projects. Find a project you’re passionate about, check that they have a good code of conduct, and dive in!

Good luck with your code journey 🙂

Whenever I’m stuck on a coding problem, my instinct is to turn to my (senior developer) partner, gesture at the screen, flail at the keyboard and say, ‘Make it work!’

Needless to say, this approach (and yes, I have tried it), does not work.

Knowing how to ask for programming help is a really tricky skill for beginners. For us musicians, we are used to individual lessons where a teacher knows us and our context very well. These teachers often tell us what we need help with and don’t leave space for us to self-direct.

So here’s a basic template (adapt as needed with experience) that you can use to ask for help.

What language and version are you using?

Where/how are you trying to run this code? (E.g. in the browser console, the command line, an interactive shell)

Which operating system (macOS, Windows, Linux) or browser if you’re running it in the browser (Chrome, Firefox, Safari etc) are you using?

What is the context? (E.g. this is a single function or it’s the final stage in a complex web app request or it’s an automated test.)

What is the expected output?

What is the actual output?

What have you tried so far to fix it? (It really helps to keep a record of this. I use a bullet journal.)

What is the critical thing you are trying to do? (E.g. select a random number, receive a 200 status response.)

Which method(s) is/are you using to achieve this thing?

Send code snippets / screenshots!

Send code snippets / screenshots!
Send code snippets / screenshots!

Quite often by the time you have answered all these questions, you will have solved the problem. Not all of it will be relevant to your specific problem but it’s good to know anyway! And if you haven’t solved your problem, this gives someone else really useful information to help you.

Got other questions to include? Let me know in the comments!

JavaScript edition:
Have you forgotten to include a return statement?

Me as a kid atop my brother’s car.

Originally published in April 2017.

Makers Academy day 1 of 60 (not counting weekends) is finished. It’s 8:45pm and I am in bed absolutely exhausted and very happy.

We had orientation this morning, learning about how MA functions. It was great to see their intelligent approach to learning and even better to hear from Dana, our Chief Joy Officer (meditation/yoga/life coach). I’m so glad MA encourages us to take care of ourselves!

Then I had a fantastic Alexander technique lesson over lunch, which really helped with some left shoulder issues I’ve been having.

And finally, spent 4.5 hours pair programming. It was an intense experience! Learning to work in close proximity with another human being is always a learning curve but years of playing chamber music have really helped to train me in listening and communicating. We both thought our pair session went really well, we had a good feedback session, and are going to chat on Slack tomorrow morning about what we learned.

The actual coding itself was pretty easy, which is good — the focus was on learning to pair effectively. Am looking forward to some deeper coding challenges!

As soon as we hit 6pm my brain just shut off. While I wanted to do another 5 hours and totally finish the week’s challenges on day 1 (afternoon 1 even!) all of the sudden none of the words on the page made any sense to me so I had to call quits on the session 🙂 .

I then went on a walk for an hour to appease the FitBit gods (while chatting on the phone to a friend, conveniently), came home and ate bacon and porridge for dinner (yum!) and now am struggling to stay awake till 9pm.

So what have I learned from today?
 — I need to read instructions, code, and error messages slowly. I read far too quickly and get away with it a lot, but what’s the rush? Where’s the race? Better to do it slower and more mindfully. Hm, mindful code reading…
– I am very much eyes on the prize — complete the challenge the recommended way before finding other ways to do it. I do think this approach is borne out by Bloom’s Taxonomy — master the apply stage before moving on to the analyze stage.

– I really can’t sit still. In 4.5 hours of pairing (including breaks), I moved from the desk to the floor to lying on the floor (not great for typing but ok for navigating), back to sitting on the floor and ended up at the desk again. I apologise to everyone I am pairing with that I will be roving around.
– I need to wear more comfortable shoes when walking.

​Bye for now!

Originally published in April 2017.

In the music industry, we have a saying: RTFS, which stands for “read the f***ing schedule”. It’s mostly used on tour, when you roll down to the hotel breakfast after a late night concert and ask your equally tired colleague, “When does the coach leave?” “RTFS!”

Well, I have a new version for myself in coding: RTFI, or “read the f***ing instructions.” 
I spent 90 minutes this morning working on a Code Wars kata. I skimmed the instructions a couple of times, and was pretty confident I knew what I was supposed to do. So I built my own TDD tests, and proceeded along my merry way writing the code.

Before too long, I had passed all my own tests and was satisfied with the code so I ran it through Code Wars. Failed one test, ok, no problem, can fix that. Then I failed another test. Now this particular kata had you build your own tests so I couldn’t tell what argument my code was being passed that caused it to fail in so many different and spectacular ways.

I thoroughly ignored the advice of my cohort pal (sorry, Rob!) who rightly insisted that the order of the elements in the array mattered, because I was convinced I understood the (in my defence, rather poorly written) instructions.

After more tests failed, I went to look at the instructions again and lo and behold, I had been building the wrong thing. Needless to say I was by now too frustrated to get any useful work done so I’m writing this blog post instead as a warning to future Paula:


A random photo of me in a cowboy hat.

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.