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?

6/7/2017

It’s week 9 at Makers, and I’ve noticed a recurrent theme: the importance of TDD (test-driven-development) and why people (i.e. me) struggle to get round to doing it.

So I’m going to write three blogs on TDD addressing why TDD is important, how to do TDD, and possibly most importantly, how to motivate yourself (me) to do TDD better.

So here are some questions about why programmers should bother with TDD:

1. Why not just write the code correctly in the first place?
Definitely a good idea to write good code — but your code will inevitably change. Example: I wrote a rails app a few days ago and used the Devise gem for user authentication. I wanted to style the forms, so I changed some buttons to a link. I was proudly showing off my beautiful creation to a friend when the buttons stopped working (good tip: rails forms default to a POST request and you have to specify if you want GET — I hadn’t done this, which is why my code broke). If I’d had a feature test, I would have known right away that my routes had broken when I changed the form.

2. Doesn’t writing tests takes away time from adding features?
But it gives you the time back in debugging those features later. Even if you manually inspect your site (for example), you still have to reload the server (depending on which server you’re using), possibly clear the cache, and run the tests yourself. Much easier to run RSpec (or whatever testing framework you use) and have it tell you the exact line of the error, and possibly even how to solve it.

3. Wouldn’t you rather be writing features?
Doing good work means sometimes you have to do something that’s less fun in pursuit of an overall goal. Violinists play scales, athletes do something athletic, programmers write tests. It’s part of the less glamorous part of our job that means we are way better at our job. And we want to be kickass programmers, right?

4. But doesn’t writing tests just make the whole process slower?
Not so much slower as break it down into smaller steps! The idea of sitting down at a machine, typing furiously for six hours, and emerging with your keyboard smoking and an amazing app fully developed is really sexy. But even if you manage to do that perfectly, your app will have to change — and possibly even be changed by someone else who may not have your brilliance and depth. Much better to code in tiny pieces, each new bit being tested so you can immediately pinpoint problems.

5. Is there anything else great about tests?
Yeah! They satisfy the XP value of communication: tests tell the next programmer maintaining your code what exactly it’s meant to do. I’m struck by how often my coach asks to see my tests — it’s a quick way to get an overview of what the code is meant to do. Also very importantly, tests demonstrate that you’ve accounted for edge cases — so think of them as an opportunity to show off how expansive your thinking is.

Ok, so that’s it for post one. Check out the next one: 5 Steps to Good TDD

5/31/2017

This is the story of a bug.

This bug was annoying and caused the coders a great deal of heartache and misery.

The coders were tempted to give up on solving the bug.

But they persevered, and the bug was fixed.

This is also the story of Makers Academy, encapsulated in this one small story about a bug.

On Monday 29 May 2017, my pair partner and I submitted a pull request for the front end we had built and styled using Ruby on Rails 5. We were quite proud of our design, and rightly so. It was a clean, elegant user interface, modelled shamelessly on Facebook (our whole-team project was to build “Acebook”).

Our coach asked for some changes, one of which being to fix a test that had mysteriously begun to fail (first lesson learned: run your tests again before submitting a PR), the second to restyle a button class according to Rails syntax.

The first failing test was relatively easy to fix: a stylesheet had been required twice. Turns out you don’t need to explicitly require your stylesheet as it will be automatically required as long as it’s located correctly.

Which led to the second error: ‘unable to find button “New Post”’.

This error would drive us round the bend.

We could see quite clearly on the page that there was a button; we could inspect it with the chrome devtools and see its lovely button classiness.

And yet Capybara couldn’t find it.

I Zoomed one of my teammates, and when he couldn’t find the error either, I retired in defeat for the night. When we resumed the next morning, I showed the error to my full team of four and no one could figure it out.

So we called in the big guns: our coach.

We then spent a good half an hour exploring differences between Rails 4 and 5 syntaxes (‘form_to’ vs. ‘form_with’ anyone?), changed a lot of things around, and eventually reset the test and code to a point at which it was working. We couldn’t figure it out.

Eventually our coach said, “Sometimes you just have to say ‘that happened’.” That sure did happen. But there was one thing I couldn’t understand: why the test passed when it said ‘click_link” when the code was clearly a button, yet failed when the code said ‘click_button’.

Then our coach got the light in his eyes that said, “I now know the answer, and I am going to leave it to you guys to figure it out.”

Needless to say, I was annoyed.

​I’d been plugging away at this error for a good three hours now, with several different teammates and lots of attempted solutions, and had gotten nowhere. I was at the frustrating stage where my code worked (I thought — I could clearly see the front end doing exactly what I wanted the test to do) but I didn’t how I had broken the test, or why it was working with the reset code.

At this point part of me still wanted to implement one of the two suboptimal solutions:

  1. Commit the test that passed mysteriously and hope no one asked us to explain it
  2. Reset the code back to its ugly, plain link/unstyled state with a comprehensibly passing test.

It was also lunchtime, which may have had something to do with my frustration.

I switched pairs to get fresh input and we plugged away at the problem and then all of the sudden it came to us in a flash — in fact, the bit of Rails magic was a link, not a button, which is why ‘click_link’ worked, even though this link had managed to get attached to a button class.

​​

Great, so all we needed to do was to change ‘link_to’ to ‘button_to’ and be on our merry way. Simple.

Have you ever tried editing code from one unfamiliar syntax to another unfamiliar syntax while it’s lunchtime and your brain is fried from a morning of debugging?

We reconvened after lunch (in my case, a nap) and in twenty minutes had sorted out the syntax, the tests passed, and the browser looked fantastic.

The End.


The evil bug was defeated because:

  1. Curiosity and a desire to learn drove the team to find the best solution
  2. Teammates kept pushing each other forward when someone was discouraged
  3. The team shipped outstanding code, which communicated its intent clearly to the dev who will work on it tomorrow, and which can serve as a template for future code. No replication of errors on their watch!
  4. The team also shipped simple, well-refactored code: 3 lines of ‘link_to’ code became one line of ‘button_to’ which also looked better on the UI
  5. The team respected the TDD process: even when it was a giant pain in the neck to have a mysteriously failing test, we still ended up with much better code because of it
  6. The team pair programmed really effectively to solve this problem, rotating the people working on the bug so there was a good supply of fresh input mixed with the knowledge of one of the devs who wrote the code

The whole Makers Academy experience is summed up in this bug experience: pairing, TDD, XP values, and rigorous code review. I’ve never been so proud to be a MA student as I was today.

With thanks to teammates Jon, Miles and Sandy, to the rest of the remote April 2017 cohort, and to the MA staff.

Read about the second half of Rails week: Paulamorphism: tales from Rails

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:

RTFI!

A random photo of me in a cowboy hat.