Female programming dream that’s gone off the Rails

I've been meaning to blog this for a while but needed to let my feelings settle down a bit…

BBC MicrocomputerThe first bit of code I ever wrote was a simple program in Basic on a BBC Microcomputer back in 1984 in the tiny school computer room next to the tuck shop. It did very little but ask me questions in a never-ending loop about my answer strings but I did think: ‘Blimey, that’s pretty cool. I got a machine to talk to me!’

I was rarely out of the computer room after that and told everyone I was going to be a computer programmer – and more likely a systems analyst! – when I grew up. (Pretentious, moi?)

However, my gender got in the way of such ambitious plans.

King Edward Camp Hill grammar school for girls only housed the computer room. The ladies of the fourth form couldn’t actually take a qualification in computing; only the boys from the school next door were allowed to do the coveted computer O’level.

So my mother and I booked an appointment with the headmistress: “This is the 1980s! We should have equal access!” Miss Percival, who spoke with a plummy Margaret Thatcher voice, just crossed her tweedy arms and fobbed us off… the lady wasn’t for turning. (Note: sometimes, when teenagers stamp and whine that it is so unfair, it genuinely is.)

***

site screenshot

Thirty years later – I’m re-igniting my schoolgirl dream. I’m a freelance digital content creator, sitting in a wifi café in Moseley and creating an Apple Developer account so I can download what I need to bash my way through the free online book, The Bastards Book of Ruby.

I get so far with the book – which is written by Dan Nguyen, a journalist in New York, and pretty accessible to me as a former journalist myself – but coding requires a very different headspace and I need a proper block of time to get to grips with it.

For anyone who hasn’t tried coding, it feels something akin to going from being an interior designer to a construction worker: you’re both building houses but the skill and mind set is completely different.

***

Rails Girls Ldn ticket

Rails Girls come to London – It’s a year later, April 2013 and I’ve landed a competitive place on a day-long crash course for interested beginners to learn to code using Ruby on Rails. Having only got to chapter two of Ruby on my own efforts, this was perfect. Rails Girls London’s idea was to put developers in a room with female, semi-beginners like me in order to learn the techy thing and create stuff in an environment supportive to women.

A fine idea – despite it ending in tears and anger.

I probably took the wrong turn at the first group divide. When the organiser asked for people with some experience, ie, “Have you ever used the command line to say Hello World?”, I put my hand up. Later I discovered that some of the other ‘beginners’ in my group were actually doing degrees in this stuff or had been playing around with different programming languages for years. Getting into the wrong group probably set me up for a fall from the start.

We started with an hour of online tutorial in Ruby – it was the equivalent of learning the building blocks of a language. Which was fine, and although I’m good with languages, I can only remember so much vocabulary so after 50 minutes or so, I realised I was just mindlessly doing what the tutorial told me to do and not really retaining anything. My brain was full and there were still seven hours to go.

Then it was on to the Rails bit – this is where it gets to be more fun my team’s mentor assured me. But that’s where things started going really wonky.

This may be because I’m the kind of person who asks ‘why’? (A lot. I do that for a living when people try to get poor web content past me.)

I couldn't get a grasp on the actual framework of how all the different coding windows worked with each other. I asked my mentor for some overview or context or an analogy to help me ‘get it’. But he couldn't think of one. So he passed me on to the organiser, who was really helpful but had to go and run the event, so he briefed another developer to pick up on where I was having problems.

I then spent another few hours one-to-one, going through theory and a few practical things – but again it ended up as the human equivalent of an online tutorial, with me just typing what I was told without really having any understanding of what I was doing.

***

When this happens, I tend to soldier on in the hope it will come right, but really the ‘you can’t do it’ voice is getting louder, and I can’t seem to quell the rising sense of failure/panic/tension. After that, it’s a quick hop to wobbly lip city. So when my mentor left me with a coding task, while he took a smoke break, I tried a few things but soon realised the whole thing was incomprehensible and really I’d rather be just about anywhere else where I didn’t feel so completely and utterly stupid.

I felt very alone. All around me the other groups seemed busy and looked as if they knew what they were about. The girl next to me, for example, had somehow created an app that scraped all the Twitter conversation from #railsgirlslondon and sent it to appear on a web page. Which was cool.

And the devs were obviously great at what they do – I couldn’t understand why I wasn’t getting it.

Don’t get me wrong, Rails Girls was a fantastic event for many of the attendees who did ‘get it’ and I met some very nice ladies there in the social bit of the event. Having not being able to code because of my gender, I am very sympathetic to the set-up that gives women the space to succeed as most did – or fail, as I did.

However, it’s a salutary tale and one I’m blogging about because I’ve recently started training and doing workshops in my own specialisms. And I find myself questioning how to check that my trainees have understood what I’m telling them, or how much to repeat so they get it (seven repeats is usual says my sister who is a teacher), or how many visuals vs text vs discussion vs exercises to put into a presentation.

Good teaching is HARD.

***

If I learned anything that day it’s the truth of ‘those who can do, can’t necessarily teach’ and the expectation the event engendered of beginners being able to code in a day left me feeling bruised. I came out upset and unsure of whether to continue – which is the very opposite of the outcomes those running the event were trying to achieve.

I think I still want to learn to program but I’ve lost my coding mojo. I guess it’s back to teaching myself. Which, being self-taught on all things digital, is something I’m frankly getting a little tired of.

Typing this out a few months down the line, I’m reminded of similar meltdowns I’ve had when failing in other scenarios.

One was learning my basic motorbike training and feeling let down when the only people who were permitted to go out on the road at the end of the day were those who had ridden before and had come with their own bikes. No one else had passed the day’s training. I never did follow up on my training.

But the worst was when learning to Scuba dive in 2007. My first dive out of PADI training was run by a guy who took me 5m deeper than I was qualified to dive, against a strong current, where I went through an out-of-air experience due to over-exertion. It was an experience that put me off diving for five years until I finally re-did the training and started all over again.

So this is partly about me, how I learn, how I cope with failure and whether to get on the bandwagon again (I'm not looking for encouragement by writing this by the way). But it’s also about the value and skills of teaching and being able to meet learners where they are at and understand how they learn. Because if you get that wrong at an event or training session, the consequences can be debilitating, and even crush a schoolgirl’s dream.


Hire/commission me: fiona [at] fionacullinan.com


14 thoughts on “Female programming dream that’s gone off the Rails”

  1. Thanks for this honest account of your experience. I knew you had this on your mind since you mentioned it to me at the workshop.

    The Rails Girls events are learning experiences for everyone, including the coaches and the organisers. For example, perhaps my asking people to decide their own experience level was a mistake. We had a few mismatches as a result of that. We did self-selection in the second workshop, but based on different criteria.

    If we could re-do your workshop experience, I think I would have tried to have more coaches on hand so that you could have spent the entire workshop one-on-one with a coach. We had those numbers for the second workshop.

    I really hope that you continue to work at programming. I wish you lived a little closer to London so you could take us up on our Weeklies, which are well-attended by students and coaches, and result in close to equal numbers of coaches to students.

  2. Thanks Damon for responding. I'm glad to hear the filtering is sorted. I think Rails Girls is a great idea on the whole and this is hopefully more a point about the art of teaching being undervalued. Eg, I once got a temp job teaching English abroad because it is my first language, one that I'm employed to write in… And yet breaking English down into constituent parts was something I didn't know how to do. What was a modal verb? How do you explain tenses to kids who only have one tense in their native tongue? I remember losing it when trying to explain the "if I had xxxx then I would xxx' tense. I guess I'm saying that sometimes the trainers need training so they know how to deal with problem kids like me.

  3. It seems to me like it would be really, really hard for someone with little coding background to get much of anything valuable out of a daylong Rails event. I have been working with Rails for almost a year, professionally, all day every day, and I came to it with a stronger programming background than you did, and it still took weeks for me to be able to usefully modify existing rails apps (except in really trivial ways). Much less do stuff like what your classmates were doing. I'm guessing that speaks to their strong, preexisting familiarity with similar technologies, and it would be awfully hard to create an event that is useful for both folks with that kind of background and for novices.

  4. Hi Some other Damon – I agree. I play guitar – it was a helluva lot easier for me to pick up the ukulele from that background. I've been thinking since Rails Girls that I would like suggestions of an easier place to start. Any suggestions welcome…

  5. I found this post quite disturbing to read and really feel for you, Fi. I am sympathetic to the demands on trainers to provide training to suit what was always going to be a broad spectrum of backgrounds but this is a profoundly negative experience which could have been avoided.

    … And I am pretty sure that it must have been a miserable experience for the trainers also.

    I don’t want to be judgmental here. I have taught for over 25 years with a broad range of young people and adults. I also work with digital content, so I have a foot in both teaching and digital camps. I am eternally surprised by the individuality of each learner and am always having to tailor my approach for each one. And this is where the planning comes in: What to teach is straight forward. How to teach it is not and requires informed planning.

    Why is this crucial? Because the one thing I have watched with abject dismay – horror even – is when a teacher/trainer ends up making a learner feel worse about themselves than before the learning session started. Example: Am currently teaching 3 students who were absolutely fine in their maths until a change of teacher last year made them feel they were ‘hopeless’ or ‘failures’. It can take up to a year to redress this implosion of self-confidence. So real damage can be done by inadequate teaching/training.

    The bigger picture is that 21st century learners need to be lifelong learners: equipped with a mindset that is open to new learning experiences throughout life, if they are to future-proof themselves during the accelerating rate of change in the employment landscape. Learning isn't an add-on anymore; it's an urgent survival strategy.

    With this in mind, let us consider that all teachers/trainers – whether offering a one hour or a one week course – have a primary responsibility to their trainees to nurture, rather than damage, their future capacity to learn:

    1) Baseline assessment
    If trainers don't start at the point where people are at, then their learners can't learn.
    Strategy: Assess this before starting and deliver accordingly.

    2) Plan meaningful learning
    If trainers don't attach meaning through context, metaphor, examples etc. then their learners can't learn. It won't make sense. The brain rejects the information.
    Strategy: Plan for this.

    3) Plan for range of learning styles
    If trainers don't allow for the fact that people learn in different ways (preferred learning styles etc.), then they are probably just going to teach in their own preferred learning style. Easily done and we've all done it.
    Strategy: Plan to include visual, auditory and kinesthetic activities for maximum participation. Add online, interactive, social and individual experiences.

    4) Assess throughout
    Don't assume that what has been taught has actually been learned. Assess throughout session. Eg: ask trainee simple questions, set 1 minute activity, ask for recall, ask them to prioritise top 3 facts they have learned. Etc. Etc.

    If this is patronising, it wasn’t meant to be. To me, learning is the key to human life. It enables survival, empowers the powerless, future-proofs the unemployable, and transforms the meaningless.

    And it’s bloody good fun. We know that 2 year olds love to learn. We call it play. They are intrigued by constructing their world as they learn through play. They concentrate intensely as they explore new concepts and celebrate successes with unrestrained joy. Adults’ brains work the same way! We trainers/teachers maybe just need a friendly reminder sometimes.

  6. That sounds rubbish.

    The hardest part for me as a trainer is to "unlearn" everything. It's almost impossible for a long-term coder to think like a newbie. It's a really good exercise for a trainer of *any* subject to try to create a tutorial which assumes zero prior knowledge.

    As a minor plug, I'm trying to write Python tutorials for kids – using short stories. https://github.com/edent/PythonPals

    It's *brutally* hard not to just wave one's hands and say "That part is magic". Which, of course, leads to confusion.

    Good luck on your future studies and Illegitimi non carborundum!

  7. Hey Fiona,

    Echo what Damon said, thanks so much for bringing these experiences out. I think it's important for the whole community to acknowledge that the curriculum or format are by no means perfect and we should always strive to get better. That's why feedback like this is so valuable.

    I think one of the guiding principles of Rails Girls is that you by no means learn Rails in a day. You get your first experience in building something that interacts (the same feeling when you first modify something in HTML) and there are certainly areas that remain "magic". But at least you now have a familiar face within the Ruby community who you can go and ask from. When I was first learning, I strived to get this first feeling of accomplishments as soon as possible and for me building something half-blind was a good way to tinker. This is probably why the curriculum is as it is today – but it's far from being universally good way of learning.

    We've started to include more teaching tips in the curriculum for coaches and will hopefully offer more templates on how to organize follow-up events. As this is entirely a grassroots movement, the changes might not be immediate 🙂 But please don't lose all hope – Ruby community is amazing and you will find the right learning path, even if Rails Girls wasn't a great first experience.

  8. Hi Linda,
    Thanks for the comment. Actually I'm just looking at your 'What every girl needs to know about programming' video. http://www.youtube.com/watch?v=_rkkFdQeBlA&sns=em

    It's good to see Rails Girls taking off around the world. I hope that my story does help you guys develop a Plan B for the 'non-geddits' because I think my asking questions derailed the whole training – perhaps if I had gone through the app from concept to completion as the event intended I would have some overview.

    Looking at your video slides, I realise I didn't even get onto the Bentobox concept, which may have helped with a framework to hang understanding on. I think this is the coach's job – to check attendees are on track with the programme. Having three different coaches meant going off the script so I didn't know what was happening. Felt quite singled out as a result. :/

  9. I was really saddened to read of your difficult experience – there are few things as horrible as being all out of your depth at something like that and knowing you're struggling and feeling bad for taking up trainers' time, realising it's not really going in, all of that stuff. I thought you brought out the issues for all trainers really well, and I'm so glad reading the comments that the organisers of the event have taken them on board in a positive and constructive way.

    I hope you won't give up with the coding. As someone who started out typing in endless lines of BASIC from computer magazines and did a few of my own very basic programs, I wouldn't dare try to learn one of the modern languages, but I will watch your journey with interest.

    Matthew, my other half, asked me if you'd tried working with the Raspberry Pi computer thingy as you can use Ruby with that. He's got one but he hasn't done anything with it yet. Just throwing that in there!

    Keep up the good work!

  10. Hi Fiona – I really feel for you in that situation, I really do. I've experienced that wobbly lip feeling on training courses as you feel everyone else around simply 'gets it', while you're still figuring out which application to open just to start the exercise.

    One was Talis' "Introduction to the semantic web", which turned out to be a half-day discussion about the open web and a half day presentation on the SPARQL language syntax. Nobody asked what the end result looked like and why it was interesting. Another was UCL's 1-day "Masterclass in data visualisation" which consisted of academics presenting their case studies and 30 minutes at the end of the day for trainees to experiment with the Many Eyes tool. No training or masterclass of the sort. Both events left me with the impression that the fields were deliberately fenced, "this is where the magic happens" and they assume attendees learn like the trainers do.

    Data visualisation is a topic I'm keen on and will need some programming skills to progress any further with it, though I'm confused by training courses which either pretend you don't need to know how to program or assume prior knowledge of programming tools and frameworks. I wrote a summary of a chapter on using Python to scrape weather data from Visualize This and pulled out the points where the author assumes technical knowledge of the reader – in the book's first exercise. These were things like knowing how to open a command prompt or change directories on the command line.

    I'm rambling, but I think three are three things at play (in my view) for non-programmers learning a programming language:

    1) What the end result looks like, so you have something to aim for
    2) Learning the language syntax itself
    3) Understanding the frameworks, infrastructure and tools which make 1 and 2 possible

    To start 2), you need to understand 3) – some of it as basic as "what application do I open on my computer to start typing?" or "how do I save and preview my work?" Existing programmers understand this; newbies may not. It's like showing a class of programmers the principles of colour, repetition, proximity, alignment and then asking them to design a poster – and assuming they already know how to use a layers-based drawing app and how graphics in print need to be prepared differently to graphics online.

    Trainers of new programmers should also show interesting end results to try and answer your understandable "why" questions. Typing commands into a prompt with no knowledge why you're doing it or without seeing a tangible result is unsatisfying and doesn't reinforce learning.

    I also feel that trainers offering 1-day courses should be realistic and clear about what can be achieved in one day and what prior knowledge the course assumes.

    Like you, I've gone back to teaching myself rather than expecting courses to provide the right level of training. I've just started using Codeschool's online tutorials; they're impressive.

  11. Don't give up. Chances are you *can* do this, but you might have bitten off more than you can chew on that first course.

    I suspect that trying to start programming with a high-level web framework like Rails is actually a bad idea. (I have zero experience with Rails, but have used Django, which is a similar approach for Python.) There's just too much going on under the hood with Rails (or Django) for you to appreciate what the framework is doing for you. Combine that with the fact that you might not have a solid handle on programming fundamentals (functions, loops, logic, etc.), and I'm not surprised you had a hard time.

    Here's a wild, crazy, and untested idea: go old skool. Write a very simple little web app using nothing but CGI scripts. If you are already familiar with Ruby, stick with that. This will force you to deal with HTML, CSS, forms, and server-side logic. Databases too if you get *really* ambitious. Make it *really* simple, like a pizza order form or a 4-choice poll. You will be surprised at how much work it is. But when you get it working, you'll feel like a star. I still do even after 30+ years of programming.

    After that, rewrite it using Rails. Then you'll see the point of high-level frameworks.

    Again: this is entirely speculative and a totally untested teaching methodology.

  12. Thanks for sharing your experience. It was very interesting to me as a coder and as a code teacher. I hope you've had more success since then.

    Fundamental to this problem is that knowing something well doesn't make you a good teacher of that thing. Not "doesn't necessarily make you a good teacher of that thing", quite logically actively hinders you from being a good teacher of that thing. If you have the choice between learning from a mediocre coder who's a good teacher or a brilliant coder with no teaching experience, always go for the first one.

    The other problem is the idea of "boot camps" themselves. I'm suspicious of the concept and the name. An actual armed forces Boot Camp reduces all participants to tears, and is a punishing, painful, humiliating experience which leads to a lot of them dropping out. By calling your event a Boot Camp, what message are you sending? By signing up for one, which rights are you renouncing?

    A better one-day learn-programming experience might start with a different name.

  13. When I started reading your posting, it felt very familiar. From the early experiences until the "thirty years later". Okay, for me it were only 25 years… when I finally found a programming language I fell in love with and grasped a few things which had previously blocked me from learning programming (although I tried many times…).
    1. Do not use an IDE, use a simple text editor and run your programs from the commandline. After all, you want to learn to program and not learn how to use a complicated software with many buttons and features you don't need at this point. Simplicity rules.
    2. Take a bottom up, one step at a time approach. Do one thing at a time. You want to open a file? Write the filename into the code and add the code for opening it. Add debug code to see if it works. If this works, be happy, have a cup of tea and try adding a file request dialogue. Then, next ministep…
    3. Don't be ashamed to simply copy code snippets. http://stackoverflow.com is a great resource for it. "How do I…" – you'll find lots of people with the same question you have and answers to it. (but try to understand what you've copied)
    4. was the most difficult one for me to understand: There is no "learning how to program". Programming _is_ learning how to do things (at least the interesting part of programming). So, when you're reading documentation, trying to find the right function to use and trying to get the syntax right, that's already part of programming. The guy at my side who is programming since he's 8, does actually the same thing as me, only at a higher level (f.e. while I'm figuring out how to get data from a config file, he's struggling with how to use a framework X to connect to database Y). I could ask him to solve my problem and he could probably tell me instantly, because he had this figured out 25 years ago, but whom is he going to ask with his problem? So I bite my tongue, read the documentation, fiddle with the example code till it works or till I am so frustrated that I am asking him for a hint. But asking a human is a last resort.

    Hope this helps… Don't give up.

Comments are closed.