Accidentally in Code

Tag: Programming

4 Hours to Smash the CS Stereotype and Create Something Beautiful

Ali and I will presenting our paper 4 Hours to Smash the CS Stereotype and Create Something Beautiful (pdf) at the upcoming CICE Education conference in Toronto.

Christine Alvarado of Harvey Mudd college came to Google last month to gave a talk on how they’d brought female enrollment in Computer Science up to 42%. The talk is called “Three Promising Practices”, and one of those practices was a redesign of the CS1 curriculum (you can watch the video here, it’s over an hour long).

They dived into the feedback about the old curriculum, and what they found was that people who were already into CS loved it. And those that weren’t, their minds weren’t changed after a semester of CS.

Credit: flickr / Caro Wallis

When I TA’d a mandatory CS course for business students, I was so frustrated by what I saw as a missed opportunity. We had these students, who were bright, and tech-savvy by virtue of when they’d grown up and we had this space where we could educate them about what CS is, and why it’s awesome… and it was wasted. This course didn’t just not make the students want to study CS, it make them actively dislike it. They hated it. And honestly, I sympathized with them. So the Harvey Mudd talk was fascinating to me, because I think it shows how big an opportunity we miss by not creating curriculum designed to engage students who hadn’t planned on taking CS already.

And I think this is a huge problem. I actually work for Google now, and I was trying to explain what I do to someone who isn’t really technical and she said, “oh, you work for the internet”. I wasn’t quite sure what to say to that! But what is true is that collectively, computer scientists, software engineers, we’re building this digital future. And I think it’s important that that group of people is as diverse as possible.

At uOttawa, we had the opportunity to create a curriculum for a four hour workshop that’s run for high school students, at around the time they’re thinking about what to take at university. This build on work that I’d done in my previous curriculum, in terms of visual honesty.

The most interesting aspect that drove the design was just throwing out any expectation at the start that the students had any interest in, or experience of, CS. This was our opportunity to sell them on CS, to smash that stereotype.

Feedback from post-workshop surveys suggests that we’ve had some success with this, despite the short time frame of the workshop. Because the curriculum is open source, we hope that it will be able to be used elsewhere as well.

I’m going to talk about the design decisions we made, and why these were important.

1. Entirely Visual

One of the things that we’ve observed students to get frustrated by is lack of visual honesty in programming. Often in problems we pose to students, it’s a case of inputs in, outputs out. The program is a black box, and when the wrong answer comes out of this black box, students often don’t understand why, or how it’s going wrong.

When we cerate visual programs instead, it’s so much clearer. The line is not where it should be, or the circle is smaller than expected. It becomes a lot clearer what kind of mistake they’re looking for.

2. Activity Based

Credit: xkcd

Don Norman wrote about activity centred design in terms of remote controls (amongst other things). It’s a plea to designers to design for what people want to achieve, rather than how to do it. We’ve taken that approach here. Rather than following the traditional path of thing to learn, followed by contrived example, we present things they may actually want to do, and then explain how to go about doing them.

We’re not expecting students to go away with a thorough grasp of the constructs, so it doesn’t matter if they master if statements but not loops. This means that we’ve made it so that the modules are stand alone as possible. We’re not telling them what to do. We’re asking them what they want to achieve.

3. Open Source

We deliberately chose to make the curriculum as open as possible – in every sense. We use the open source software Processing, which runs on Mac OS, Linux as well as on Windows. The curriculum itself is also licensed under creative commons.

This has the big benefit of reducing as much as possible the barriers to students continuing at home or at school – the software is free, and compatible with whatever operating systems they use.

4. TAs

Credit: flickr / Xpectro

We were extremely selective about hiring TAs. We aimed for a ratio of 4 students to each TA, as being stuck and having to wait for someone to help you is so frustrating to students, and we wanted to keep that as minimal as possible. In hiring TAs, we were looking for strong problem solving and coding skills, and as importantly, excellent communication skills. We were looking for TAs who were fun for the students to interact with, who would be role models. Our TAs are potentially our biggest asset in smashing that stereotype, so it’s really important that they are awesome.

5. Self-Directed

Credit: David Baird, http://www.geograph.org.uk/photo/775326

The low ratio of students to TAs allows us to give students the freedom to work at their own pace, on what interests them. Students with prior programming experience will often skip to the more advanced modules, and students who are less comfortable can take a slower pace, or focus on more math-based activities, such as fractals.

6. Inclusive of Interests and Levels

We provide a mix of modules, ranging from complete beginner to more advanced and students are welcome to come up with other things to create, or find more information on the internet. Often students want to make games, so we facilitate that with a pacman-like framework (we’d like to add Brick Breaker soon), but we also have several fractals, for more math-loving or artsy students.

The students are challenged to “make something beautiful”. It’s always interesting to see what they come up with! This open-ended approach means there are always extra challenges – for example, animation! Students have also started to explore Processing’s 3D capabilities.

We take a very open approach, encouraging students to look things up on the internet, and even to share things they create on social networking sites like Facebook.

Overall

We’ve found our experience tremendously rewarding. Curriculum development is a design activity, and approaching it with some different constraints has been interesting. We’re very encouraged by the success of our program, and other curricula designs in attracting different types of students into CS and we hope to continue our work further, by partnering with other universities and organizations to bring the curriculum to them and expand it further.

April 1, 2011
Simplicity and God Objects

Credit: flickr / Stinging Eyes

There’s an anti-pattern in Object Oriented programming called “God object” or “God class”. An pattern is a design to follow. An anti-pattern is something to avoid. A God class is a class that knows and/or does too much. Breaking a problem down into well-defined units of limited scope is part of writing good code that can be updated later by someone else, and hopefully reused elsewhere.

Three things happened last week that got me thinking about simplicity in general.

Physical Simplicity

My boyfriend hung my art and I finally finished unpacking. I am in love with my space, how open and clean and uncluttered it is, and the pictures from my travels filling my wall space.

I’ve been throwing stuff out, and trying something where I don’t buy anything in February. I mean, I buy things I run out of (soap etc), I bought picture frames, hooks for hanging them and the two bamboo plants that frame my window. And I bought Kindle books and a TV series on iTunes (weirdly, these did not seem like purchases due to lack of physical objects and I only realized afterwards). But, having this mentality that I shouldn’t buy anything has made me interrogate what I would bring in without thinking, usually.

My policy is that if I wouldn’t take it with me on a move to another country and I’m not using it regularly, I should get rid of it. I hope this month’s awareness will stay with me because it’s apparent that to keep the empty space and lack of clutter is harder than accumulating things. It means interrogating every purchase and saying, “What will this add to my life? What will this replace?” – and it’s a constant project to decide what I’m no longer using and should get rid of.

Simplicity of Reusable Code

One of my colleagues made a reusable component, that I also was to use in my code for a particular button. I wrote the code around it on Monday, thinking I would have to change one method. On Wednesday, I got his component which worked differently than I expected. What I hoped would be a short fix took much longer, by the end of Wednesday I had it working – but only when the image part of the button was clicked, the spacing around didn’t work. There’s a long and complicated reason for this, but basically we were using two different types of buttons.

Thursday, I returned to my war with the button and by the end of the day it was working wherever you clicked. But in the process the reusable component had become a tangled and horrible mess that I was not going to submit. Initially it had fitted my colleagues purpose a little too well. Now, it fitted both his purpose and my purpose a little too well.

A good night’s sleep later, I’d stepped back sufficiently to be able to have an idea of how I should redesign it. By the end of Friday, I’d reworked the class so that our individual code was a little more complicated, but the reusable component we both called was much simpler. Hopefully someone else will be able to reuse it, even!

It is so easy to think that your use case is the same as all that will follow. Everyone I work with is really smart and the design of this component had been discussed and thought through. My use case was similar enough that it didn’t seem like it would be a problem – until I started to try and use it. This component is really very tiny, and yet it was able to know too much and do too much.

As an aside, I wouldn’t submit code that hideous anyway, but the code review process really removes any temptation because it would get – rightly – torn to shreds.

Simplicity in Organization

Someone said to me that I was trying to add an excessive amount of structure to a rule-free organization. They were right, I was asking a lot of questions and suggesting a lot of ways in which we might quantify and/or measure what it was they were proposing to add.

We have something very simple. Everything in it has clearly defined responsibilities and purpose. It’s easy, and it’s clear. What they are proposing changes that somewhat, but I don’t think we should use that simplicity to add extraneous things – that’s how we’ll end up at something complicated.

Fight to Keep it Simple

I may or may not manage to keep my apartment clutter-free. My design may or may not work for the next person who wants to use it. I may or may not win the argument over complicating organizational structure.

My friend says, why do you need to get rid of things you wouldn’t take when you move, now? My colleague asked why didn’t I just use the thing that the reusable component uses. My friends ask, why do I care about the argument – I can just walk away from it.

And it all comes down to the same thing – I think you need to fight to keep things simple. So I’m not going to say, “I’m just not going to bother with this” without first attempting to make the case – via code or via argument – for a simple, reusable way.

February 25, 2011
Building, Not Destroying

Credit: flickr / Diamondduste

When I was 5 or 6, the school thought I had learning difficulties because I couldn’t read. It transpired that it wasn’t so much couldn’t – as wouldn’t. I refused to read the nonsense little books about Little Jonny Red Hat. Clearly my aversion to things that I find pointless started at a young age. Once I discovered there was a world of interesting books, I was hooked.

So hooked that my mom worried I had social difficulties because I read so much.

I loved reading, but never wanted to be a writer. My friend in primary school though, she was going to be the writer. I was going to do something math-based instead. The degree of pigeon-holing is quite amusing now, I remember her winning a writing prize two consecutive years… for the same story.

High school, 11 or 12, I read much faster than my peers. We were to study Jane Eyre, and had to read it mostly in class. I loved this book, and devoured it 3 times whilst the rest of the class slowly ingested it. It was my new favourite.

Then we came to analyse it. It felt like we deconstructed every sentence, every motivation. All this hidden meaning was extracted from it. I thought then – and still do – that Charlotte Bronte was probably just trying to write a good story.

The book was destroyed for me, and I never read it again. About a year ago (so over 10 years later) I watched the BBC TV adaptation. It is, a great story.

I still read a lot, but mostly online and non-fiction. Business books, programming books, professional development books. I don’t take them to bits and analyse them. I read a lot of academic papers. My goal is always the same – what can I learn, how can I apply it?

I read code. Sometimes to understand it, sometimes to mark it, or improve it. How can this be written better, or more clearly? One of my favourite things to do as an instructor is to highlight some X lines of code and say, “you can do this in 4 lines instead”. I don’t discuss their motivation in naming their variables (names should be meaningful, that is all), or what the ordering of their methods within the class means in terms of their psyche.

It’s all about building. How do we build this, period? What is the best way to build it? What are our options, and the trade-off’s associated with them?

I used to think that I wanted to be an accountant, probably because that was the math-based career I knew about. But I can’t imagine being as happy with a profession where I didn’t get to build things. Where I solved problems I had fabricated rather than genuine ones.

I hated English because I had to deconstruct something I loved into a bunch of pieces that no longer made sense to me. I would hate to do that all day. I can’t find these deeper motivations. Trying to write a good story, find a beautiful turn of phrase, that’s all the motivation I see. People deconstruct politics, and sometimes I wonder if some decisions are made because someone didn’t have their coffee yet and was too proud to back down. Years later it’s analysed as part of a deeper geopolitical picture, and they become a hero – or a villan. Working in environment, or charities, it seems like the problems are just too big to make a dent it.

So let me build you something. I can solve that problem, and make your day a little brighter. Just – don’t deconstruct my motivation. I just want to build things – that are useful, or beautiful, but sometimes, that holy grail… both.

Originally posted at CompSci Woman.

November 24, 2010
Experimenting with a Visual, Activity-Based Curriculum
When I left Ottawa, I had to find the new me to run my Processing Workshop. His name is Ali and he’s awesome. He’s had the idea to write up the ideas into a paper, so we’re working on that at the moment, but it occurred to me that I didn’t write much about it here.

I will definitely post more as this project progresses, but for now I’m going to write up some of the design decisions that I think make this different. Comments welcome – it’ll help us write a better paper – or decide it’s not worth the effort!

Entirely Visual

This started when I was teaching programming in the US. Kids taking the other courses were taking home video games, even 3D ones, and so my little programmers weren’t overly excited by the idea of taking home a text-based hangman – and, well, who can blame them?

So we came to an agreement – we designed something together and I coded the GUI and each of them coded their own back-end. I developed more such frameworks the following summer and eventually got asked to develop the curriculum for all of the US.

There, I introduced early concepts using Processing (a language and editor for teaching and artists – makes it really easy to create visual applets) as a library within Eclipse. Some students would code their final projects in Processing, but they had the option of a (Swing) framework. I negotiated my contract such that whilst they owned what I wrote, I licensed them the code I wrote (and retained the IP).

The latest curriculum is designed for one day workshops. Eclipse is an extremely complex and powerful program and has a steep learning curve. The Processing editor is very simple and easy to use and removes some of the syntax necessary to create an applet, so we use that instead.

Every exercise has a visual outcome. Students can compare what they have produced to the one in the instructions. This provides visual honesty that is lacking in text-based programming applications. By working visually, we turn the program from a “black-box” where the student often does not understand the relationship between the input and output… into a colourful one.

Activity-Based

I remember learning to program, and I noticed this pattern:
1. Introduce concept
2. Provide contrived example.
I’ve taught like this too. But – why? That’s not how I code. That looks more like:
1. Evaluate problem.
2. Apply solution, that I know/look up/invent (for more complex problem).
Contrived examples are 1) boring, and 2) patronizing. Instead, we present things that the student might want to do, for example – repeat things, or sometimes do one thing, sometimes do another, and provide code with an explanation.

For a one-day workshop, we cannot expect the students to memorize concepts and it seems unreasonable to expect them to be interested in doing so. Our focus is on showing them how we can solve problems using code and why that is fun.

Open Source

Everything about our workshop is Open Sourced. The content is licensed under a Creative Commons Attribution-NonCommercial license. Similarly, the Processing library is licensed under the LGPL. So students and teachers can distribute their code without concern, but more importantly – students and their teachers can download the software at home or at school free of charge, and continue to explore the modules in their own time.

TAs

A low ratio of students to TAs (4 students to each TA) was a key part of the strategy for the workshop. Being stuck, and having to wait, is extremely frustrating to a student. Also, more one-on-one help from a TA makes it possible for students to tackle more challenging projects.

I was extremely picky about TAs and interviewed them with technical questions, not just experience questions. I was looking for fast problem solving, and good clear communication of their solution (and in general).

With the short time available for the workshop it was really important that the TAs could fix problems quickly. The key was to keep students moving through the content and feeling like they were progressing – the number one purpose of the workshop was to inspire them to take computer science, rather than to memorize concepts.

Communication was really important – firstly, because a more effective communicator will teach students concepts faster. Secondly, to break the stereotype of CompSci students as socially inept and not fun to hang out with. I was really looking for people who I felt would be good role models for the students. This included not restricting TAing to graduate students, who often code infrequently anyway. For the first workshop, I hired 4 graduate students and two talented undergraduate students as TAs. They were all fantastic. Our second workshop was organized with less notice, but rather than compromise on the quality of TAs we had a slightly higher ratio (5-6 students per TA). Ideally, we will go with the lower ratio but this ratio was workable.

Self-Directed

Related to the low ratio of students to TAs, was the self-directed nature of the workshop. Because the curriculum is available online, there is no need to share printed copies, or wait for the instructor to explain things. Whilst the first couple of modules were necessary to give students familiarity with Processing, students with prior programming experience could quickly skip ahead to more advanced examples. Where possible the modules were written to be stand-alone, so no specific path was necessary. Having a good selection of modules meant that students didn’t have to work on the same “final” thing as their friends, if they didn’t want to.

Inclusive of Interests and Levels

Processing is designed as a tool for artists, and there are several modules involving creating fractals and showing students how to create patterns. Creating games is often used to engage kids and teenagers in wanting to learn to code, but by allowing this alternative, artistic track, we hope to broaden the reach of our workshop. But, if they want, there’s a framework for a simplified game of Pacman. We plan to add more games, such as BrickBreaker, over the next few months (subject to funding).

Some students come with prior programming knowledge, and others do not. We will sometimes run a workshop for multiple schools simultaneously, and we don’t know what background knowledge the students have. This is in addition to the usual issues of different abilities! We have a mix of modules of varying challenges; for example, the most tricky parts of the fractals and patterns is the math, so students less comfortable writing code can work on those. An open-ended attitude means that there is always additional challenges, for example – animation! Students with prior knowledge of programming will often define their own challenge, or even look elsewhere on the internet and explore the 3D capabilities of Processing.

Overall

Honestly, I think computer science tends to be really appallingly taught. I don’t pretend to know how we should do it, but we need to do better. It’s great if people want to use, or critique what I’ve created, but the big thing is – I think it’s important that we have a conversation about how to make CS more engaging, whilst still teaching the skills that students need. They need to be able to code, not just write Java with the help of Eclipse.

You can find the workshop here
November 10, 2010
Being Dispensable

Credit: flickr / pixn8tr

I heard a horrible story the other day – someone had been off work because they were seriously ill, and a week before they returned to work one of their colleagues called all her clients and said she was never coming back.

Shocking, right? Bitchy! Horrifying. Disgusting behavior. Hurtful. The last thing you need. If my friend hadn’t come back and her clients had needed to find someone else… surely that is the last person they would have chosen, right?

You’d hope so. It’s hard to be sure though, and I too have been on the receiving end of something bitchy lately. Disparaging comments behind my back – to my friends! So of course they made their way back to me. And then this person decides that she wants something that I would be in a position to help her with, but instead of suggesting coffee and straightening out these “misunderstandings”… a passive aggressive strategy was employed.

I hate feeling like I’ve been backed into a corner and if I go one way I compromise my values, and if I go the other I get cast as the bad guy. I hate it. And so I debate what my strategy will be, discuss it with a friend, and go for passive aggressive in return (I’ve come to the conclusion that this is the only way to deal with a passive aggressive, but I still hate myself for it). But something else happens, and it seems like she’s getting what she wanted and I’m annoyed. And frustrated – because when you could get everything you wanted by being nice why, why, why would someone choose the route of the passive aggressive?

And then – I relax. Good things are happening, and anyway, I’m leaving. And really, I can dislike this person’s strategy, I can question her integrity, but – I have to acknowledge, that if I abstract to a higher level – we have the same goal. I want X to continue when I’m gone and that means someone to keep pushing it along. She is clearly interested enough to be that person – probably resents that I was doing it in the first place. Fine. I’m not going to be on her side here, but nor am I going to obstruct. So it’s likely that she will get what she wants.

Really what it comes down to is that I’m dispensable, and I’m OK with that. I handed over WISE to someone and I know that she’s committed, but she has a different skill set than me, and maybe she’ll come to have a different vision. That’s OK – I can mentor her, I can encourage, I can advise. But now – it’s her call, not mine. I give up control, but that means I get to move on to different projects.

Maggie and I just launched CompSci Woman. We have an initial strategy, we have some ideas, but the long term success of it means that we will be dispensable. We will need other people to help us, and we will welcome that as an opportunity to learn, and grow. We don’t want to build a small, steel and concrete structure that we can have complete control over! We want to build something organic that will grow. That means accepting a certain amount of chaos, it means accepting that the path might diverge from what we intended – it’s a compromise people make in order to be able to move onto the next project, the next adventure.

My manager, a while ago, asked me “how did you come to be you?” – at the time, I wasn’t sure if this was a complement or not. I’ve come to think that it was genuine interest from someone who’s had to learn to be an extrovert. At the time, I answered slightly flippantly, “I don’t know? Two years of boarding school?” – but here is the truth. I am the sum of the people I’ve known, the places I’ve been, and the experiences I’ve had. I have many more people to meet. More places to go. More experiences to have. The freedom of being dispensable allows be to go chasing them.

I think you can apply this to other things too – as a programmer, you can create job security by building something so complex and poorly documented that no-one else can maintain it (here’s how). Or – you can document, explain, write simple-as-possible, beautiful code and create – if not job security – career security through being visible, and awesome and having learned as much as possible along the way. Doing this properly, you become a multiplier – your effectiveness makes other people effective, and you’re responsive to being multiplied by others, as well. Of course, there may be a risk that you become a sequential prototyper – and I’m aware of that for myself – so as much as industrial research appealed to me when I looked for a job one of my criteria was, working somewhere where something I build will be deployed.

I don’t have a goal in mind, I’m not trying to build a solid structure – I’m trying to create a path. This blog is my trail of breadcrumbs, if you will. Disappointments are just obstacles, and so I find an alternative route.

I’m not an expert, rather an explorer. I don’t aim to control, I attempt to instigate. I don’t construct, I assemble and add water.

And then – I move on. Being indispensable is a cage that I don’t want to live in.

Credit: flickr / Stahl und Glas – steel and glass

September 14, 2010
The Story of a Girl Who Tripped, Fell, and Ended up in CS

Credit: flickr / bitzcelt

You’ve probably noticed, but our theme for September/October is – “How Did I End Up In CompSci?” – it’s a question that interests me, because for the first three years of university it was something I asked myself a lot.

Not in the way, “Wow I love what I do! How did I get here?!” – rather in the way “How did things go so terribly, terribly wrong?”

I’d ended up there after a blip in my tempestuous affair with chemistry – what I was originally supposed to be studying at university – the adventures that left me covered in acid one day (bye bye lab coat), that dyed a small corner of our brand new chemistry lab pink (ahh potassium permanganate), and created the toxic green goo that I still remember fondly ended at the end of first year. My boyfriend at the time tried to kill himself over winter break and I missed some exams as a result. Time came for the retake, I thought I was late, bottled it, and didn’t manage to walk into the examination hall.

It’s strange how you can look at the path you took, and see those moments – the ones that changed everything.

But perhaps, CompSci was always going to be more suited for me. For starters, I’m a complete klutz and destroyed an inordinate amount of glass stuff, and left that lasting pink stain on the lab. But also, I learned HTML at 12 or 13 and loved it. I went to boarding school at 16 – in large part because the teaching of computing (in fact, “IT”) at the high school I attended was so appalling. There I learned C, and coded a tic-tac-toe with a smart strategy. Then at 17 the course changed tack and I became shamefully proficient in MS Access (a skill that resulted in 2 summers gainful employment, not that that eased the pain). Perhaps that was what drove me away from CompSci. And, having an amazing chemistry teacher who was also my tutor, my passion became chemistry instead. Chemistry is everywhere – but then in the 21st century, so are computers. Anyway, I chose Edinburgh because I wanted to study three different subjects. And, because Imperial College gave me a BBB offer which I didn’t think was high enough for me to deserve to go there (to think, if they’d offered me AAB I might now have a joint degree in Chemistry and Law. I should write and thank them).

My Director of Studies (like an advisor) at Edinburgh signed me up for CompSci as an elective. Mid-way through the semester, I went to him and said “I hate it”. He bribed me to stay, promising to get me into Economics the following year. In another twist, I ended up in Economic History instead because neither of us knew what the difference was. It turned out, that Economic History is all the dull parts of Economics and all the tedious parts of History. Barely having studied History at all (and not since I was 12) I did not do terribly well at that, and a broken computer + death of my friend’s mother + blonde moment attaching an assignment to an email nearly meant that I had to resit second year as a result. Luckily it was resolved and I switched to Mac and moved onto third year.

I don’t remember what it was that made me hate CompSci so much – was it all the odd boys who washed so infrequently? In general, CompSci lecturers don’t explain things well and I remember one saying – like it was a revelation! – that you couldn’t expect students to show up knowing already able to code and install Linux. I remember struggling with the concept of Object-Oriented, I could explain it, but I hadn’t internalized it. I remember feeling like an oddity. In first year, I was a size 4 with a penchant for short skirts and cute hats. I did not look like the other compscis. I could not debate the merits of the different Unix installs. I did not play video games. I liked to be awake during daylight and leave the lab by 9pm. I drank caffeine, but it wasn’t my life-source. Nor was junk food. Luckily I had an amazing friend who was older than me and a PhD student at another university. He taught me basically everything I knew via MSN, and was sympathetic when I cried because I didn’t think I could do it.

Having made it to third year, I took more math-based courses, including functional programming. My friend and mentor was an amazing functional programmer and that was his area of research. With his help I really got functional programming and, apart from one disturbing night when I dreamed I was a recursive function, things started to improve. Once I’d made sense of functional programming, OO started to make sense too. I learned about JUnit and unit testing. Moving to Eclipse and abandoning the terminal meant that I picked typos up as I went along and no longer had those horrible moments when I’d compile and have 100+ errors. I was offered an internship for the summer, and that was awesome. I worked on an R&D project and coded a share tracker for cellphones using J2ME and J2EE. I spent my summer writing code and figuring stuff out with the help of the other interns – who were all really nice and normal. I started to feel less inadequate. At the end of the summer, I realized that I wanted to be a programmer; I just wasn’t quite ready to start the rest of my life yet.

Towards the end of third year I’d actually started to make friends with people in CS. In fourth year there were a group of us and I stopped hanging out with geography students quite so much and we stuck together. We’d hang out and drink, complain about our workload and profs, play Sonic the Hedgehog (my inadequacy at video games stopped being something that excluded me and was instead amusing to us), and Scrabble, and poker. I finally stopped feeling like I was the worst at everything, and surrounded by people who were less arrogant and disparaging I started to enjoy it. Sometimes people even asked me for help! I even ended up TAing because the first year course started with functional programming and I actually had experience in that. The bitchy comment some guy made about “why was [I] TAing” was easy to ignore, because the first years liked me. And I knew I was a better TA because I remembered finding it so hard and I sympathized rather than patronized. In all, fourth year was hard work, but awesome.

But when it was done, I didn’t find a job. I left. Perhaps because I felt I’d been studying to the exclusion of everything else, or perhaps I just bottled joining the real world. I went adventuring. Taught programming in the US, trained in martial arts in China, wondered around Europe, qualified as a ski instructor in Canada, went back to the UK and worked for an admin department at a University, helping them transform a collection of spreadsheets into a database – that was when I realized that I could do stuff with data, and answer questions that no-one had thought to ask. Eventually, I applied to grad school because I didn’t think I knew enough to join the real world, and only banks seemed to be hiring.

Started grad school. Got offered a job developing programming curriculum.. Realized I still didn’t know enough, and grad school wasn’t the place to learn it. Felt lost. Read a lot of books. Resuscitated WISE. Started blogging. Took control of my research and loved it. Got offered a summer job teaching programming in Shanghai. Took it. Read more books. Came back and continued researching. Had something I wrote go viral. TA’d in French and my students liked me. Started doing public speaking. Kept reading books. Developed another curriculum. Got offered a place on Extreme Blue. Instigated Awesome Ottawa. Had an amazing summer at IBM.

I reread what I’d written here a number of times, feeling like I should make it shorter. But perhaps it’s fitting that I have a long, slightly rambling story. It’s taken me a long time – 9 years since I started learning C! – to get to this point, and my search for, what? Self-acceptance? Self-confidence? Has taken me across 3 continents, at least 12 countries and included non-CS career aspirations from patent lawyer to ski instructor.

And so I leave you where this – the prologue to my career – ends. A rainy August evening in Amsterdam. An international phone call. An amazing job offer. Your protagonist, finally at peace with her trip down the rabbit hole, exclaims, “Wow I love what I do! How did I get so incredibly lucky as to end up here?!”

Credit: flickr / Rob Sheridan

Originally posted on CompSci Woman.

September 9, 2010
Programming Toolboxes and Functional Hats

Credit: flickr / Thomas Hawk

Much to the entertainment of my teammates and mentor, on Monday I punched the air and exclaimed:

YES! I am a <long product name> NINJA!

We’re exporting some data from this product (let’s call it Product X) and I had fixed a 3-4x expansion in the number of records it was producing. This made me pretty happy! Even happier, when my solution was deemed the neatest (as it skips an intermediary table with an extra column) by a master engineer and is now the answer on the forum.

I really don’t aspire to be a Product X Ninja, after mastering MS Word with my 400 page undergrad thesis (yes, I know, I should have written it in LaTeX) I intended to become a ninja of some programming language instead of proprietary software, even if it takes 10 years.

Anyway, what did I do? Essentially, I sorted the records in such a way that it gave me a property I needed – I could decide whether or not to keep a record n solely from information in the record n-1.

I have some ideas about becoming a competent programmer. I aim to know something of: an Object-Orientated language (Java), a scripting language (Python), a functional language (Haskell), and have done enough C to understand something of why it’s such a painful language to code in. I theorize that this is a toolbox, which is makes it possible to hack in other languages that come my way.

However more than that, I’ve realized that being happy to code in these different kinds of languages gives me different modes of thinking. I’ll solve something from a functional perspective in a very different way from how I’ll solve it procedurally, or in an OO-context.

And whilst I need to stop trying to program functionally in Java (it invariably ends badly), here putting on my functional programmer hat was really helpful.

Of course, in functional language I wouldn’t have the extra conditional because of the bizarre API design that deals non-intuitively with null values.

But that, well. That’s a story for another day.

July 22, 2010
Geeking Out and Getting Happy

Credit: flickr / Rob Sheridan

You might have noticed that last weekend, I overhauled the design on my blog. I felt that it was time for a change, and it’s one that is related to a change in attitude that I’ve had of late.

One of the things I’ve changed is my tag-line. It’s now:

Cate extends Human implements Programmer

Good coding practice would suggest the use of generics here, so:

Cate<T extends Profession> extends Human

Or, better, through dependency injection – because I don’t think Programmer is determined at instantiation, and also for reasons of testability. But, well, that’s a lot more code. And as entertaining as this debate has been with my geekier friends, that’s not what this is about.

Here’s what it’s about. I’m a geek. And I’m OK with that. I’m done pretending that I’m not. I have subscribed to xkcd, and I don’t always get it, but mostly – I do. It’s hilarious and adorable and awesome.

For years, I’ve been pretending that I’m not a geek. It started in my first year of uni when I was in computer science by accident and it seemed like the compsci boys (many of whom were very much like the stereotype) discounted me for being a girl. I preferred to be feared than patronized. Rapidly I discovered the easiest way to scare a nerd. It is a short skirt or a tight/low-cut top. So that’s what I wore. Now I’m no longer 18, or a size 4, I tend to scare with high-impact sports instead, specifically kickboxing.

Anyway, I got sidetracked into this place where I thought not being geeky was what differentiated me. Not my programming skills. Not my work ethic. Not that I read widely, and voraciously. Not my creativity.

No, it was my fashion sense and my ability to pass for a non-compsci. Wow, that’s a low bar!

Instantiation would be: Cate cate = new Cate(). By Programmer not determined at instantiation, I mean that I don’t think that’s the only thing I could be. I don’t necessarily think I will be a programmer forever – maybe I’ll go into Project Management, or User Experience, or maybe I’ll become a Data Scientist. The thing is, I don’t know. And that’s OK. It doesn’t matter that I don’t know what I’ll be doing in 5 years, that I don’t know what I’ll be getting excited and passionate about. Hell, I don’t know where I’ll be living and horrifying as that may seem to some people – it’s absolutely fine by me. It’s part of the adventure.

What I do know, what I’m 100% clear on, is what I want to do next. I want to code. I want to create. I want to program a smarter, and happier planet – one line of code at a time. I want to be part of a team that makes software that makes people’s day a little brighter, a little easier – a little better. I want to inspire other girls to want to do the same.

Lofty dreams. Big goals. I may not meet them, but hey – I’m a dreamer. And a geek.

Credit: xkcd

I’m really sorry if you happened upon my blog on Sunday – I had to disable caching and made a number of alterations to the theme, it might have looked a little random! If you subscibe to my RSS, I’m really sorry about the old posts that were sent out again on Sunday – this is because they were originally imported from my old blog so when I had to make some minor modifications to work with the theme they got sent out again. I’m going to try and work out a better way so that I can make the adjustments I need without spamming people – if anyone knows how to stop this happening, please let me know!

My friend Chris Olson created a new header for me, which I’m really happy with. Check out his site for more of his design work!

July 15, 2010
Back to Feeling Like an Imposter

Credit: flickr / -Snugg-

Ages and ages ago, I wrote about not having imposter syndrom anymore. I wrote about how being a programmer was an accident, but a happy one. I give talks (one next week in fact) on how great it is to code.

But this evening, I was trying to prep for this interview I have coming up next month, and I sucked at a question about binary search trees and… I cried.

I totally cried. And, in fact, had a complete meltdown over my poor friend Dig. And contemplated canceling the interview and just not going for it. Because I felt so completely inadequate.

I don’t feel inadequate at grad school. From time to time in Extreme Blue, but mostly not. But this interview is freaking me out. It’s really intimidating me. The company, the fact it’s a 2-hour technical interview that getting through means going back again for an even longer second round.

How could I not freak out?

Tomorrow morning I’m headed to the wilderness. The other day I wrote about needing to leave my comfort zone more – well I’m definitely doing that.

Here’s the thing – I love to code, but mostly so it enables me to create. I understand how to optimize, but don’t do it for the sake of it. I know the different data-structures, but see them as building blocks, not the be-all and end-all. One of my friends found me, mid-meltdown, and said that I might be a better programmer as a result of this attitude.

Sure, maybe, but this interview is geared towards people who like to take things apart. I’m a person who likes to put things together. That’s the kind of person I write for – my blog, and the curricula I create.

I don’t know how to be someone who takes things apart.

June 24, 2010