Teachers! Want to learn about the Digital Technologies Curriculum? Need someone to teach you all about code? Code Breaker Education is ready to teach you, and support you along the way.
I have been worried for a long time about how Victorian schools can possibly skill themselves up to deal with the new Digital Technologies Curriculum. I know the idea of code is daunting for many people, but the new curriculum means teachers need to be able to program, but also to teach programming.
The most important thing in teaching programming, especially at Primary School level is not to know everything (who does??), it’s to be enthusiastic, and willing to experiment. So the key thing is to show teachers that it can be fun, and that it’s not scary.
I would like to introduce you to Code Breaker Education – a joint enterprise between me and alumni of the John Monash Science School Computer Science Programme. I have collected a group of my former students who know all about code, but more importantly are passionate about Digital Technologies Education. They know that programming is challenging to start with. They know where you’ll get stuck and how to help you get over that learning curve.
They are educators, communicators, and programmers, and they can help get you ready, and confident, to teach the Digital Technologies Curriculum.
I’ve watched them teach and I am so proud of their teaching skills, their passion, and their professionalism. This is the Professional Development you need.
Check out Code Breakers Education on Facebook, or on our website, and give us a call today to schedule your workshop.
I’ve just come back from seeing Hidden Figures. My brain is on fire.
The film tells the story of the first Computers – black women! – who performed the calculations that enabled the US to send men into space. Who not only performed those calculations, but invented them. Who solved fiendishly difficult problems that had never been solved before. It is a masterpiece of story telling, of film making, and of setting history right. Because these are stories we cannot tell often enough.
Despite the realities of history, we have allowed that story to be rewritten. We continue to believe a story that says that the colour of your skin, and the number of your X chromosomes, dictates what you can and can’t do. What you are, and aren’t, good at.
We have allowed the history of computing to become overwhelmingly white, overwhelmingly male, and overwhelmingly false. We have allowed the history of space to become the history of a few white men.
Hidden Figures shocked me in its all-too-accurate depiction of overt racism and sexism – and it didn’t even deal much with the violence, or the hatred. It made me realise how far we have come. But it also made me realise how far we still have to go.
We still have politicians telling us that your worth is dictated by your race. Or your religion. Or your clothes.
We still have teachers telling girls that computing isn’t really for them. That maths isn’t for them. That science is for boys. Most of them don’t say it outright now. But in a hundred tiny ways, girls are steered away from the “hard stuff”. In the questions directed to the boys, because the girls might not know the answer. In the career suggestions. In the level of support and encouragement.
But we know that women were central in the start of computing. From Ada Lovelace to Grace Hopper. From Mary Johnson to Anita Borg. Women have figured in computing every step of the way – and they have frequently had to overcome extreme obstacles to do so, while all white men had to do was pick up the opportunities strewn at their feet.
I still get shocked looks when I tell people I am a Computer Scientist. A PhD in Computer Science is still something women aren’t expected to have. And the numbers of women going into technical fields remain horrifically low, because we are constantly told it’s not really our kind of thing. And too many of us believe it.
So go see Hidden Figures. Take your kids. Take your students. Take your friends. And tell your students, your children, and everyone you meet, that the colour of their skin and the arrangement of their chromosomes tells them ABSOLUTELY NOTHING about who they are and what they can become.
The sky isn’t the limit anymore. We’re aiming for the stars.
Now that it’s school holidays I finally have time to think. Part 1 of my “Demystifying the dig tech curriculum” post went a little viral – as much as a post on a niche Computer Science Education blog can – and there were a lot of requests for Part 2, so here it is. Once again, all constructive feedback gratefully received!
It’s probably best to read Part 1 first, as I’m starting where I left off. This is the beginning of the next strand: Processes and production skills.
Collecting, managing and analysing data
Collect, explore and sort data, and use digital systems to present the data creatively (ACTDIP003)
Collect, access and present different types of data using simple software to create information and solve problems (ACTDIP009)
Acquire, store and validate different types of data, and use a range of software to interpret and visualise data to create information (ACTDIP016)
“F-2 Collect, explore and sort data, and use digital systems to present the data creatively”
This is another simple one, that F-2 teachers are already doing: Collect some data, like the hair colour of everyone in the class, or everyone’s favourite fruit. Then you can either graph it (simple pi charts, bar graphs etc), or draw infographic style pictures to represent it, like this (although you would, of course, include better labelling than this lazy Computer Scientist has! :):
This one explicitly says use digital systems to do it, so you would probably use a spreadsheet package like Excel or Google sheets.
“3-4: Collect, access and present different types of data using simple software to create information and solve problems.”
Another thing you’re already doing: collect some data, graph it using a spreadsheet program or some online tool, and try to answer questions like: What is the most popular fruit in class JB? Or better yet, incorporate it with some environmental sustainability and graph which class collected the most rubbish on Clean Up Australia day. And that’s a good one because you can graph it by weight or by piece count, or by rubbish type: wrappers vs bottles vs cans, for example. And you can then try to graph which class has made the most improvement to the environment – which type of rubbish is worst, and who has collected the most of it? Ok, I might be getting carried away here, but you can see how this goes. These types of activities always work best when they’re tied in with other things the kids are already doing, so that they can see the point.
“5-6: Acquire, store and validate different types of data, and use a range of software to interpret and visualise data to create information”
This is really the same as the examples above, but ramped up a little. The data above was all discrete, simple values that you can aggregate: 5 blondes, 4 brunettes, 1 redhead. Or 6 prefer strawberries, 3 prefer apples, and 1 prefers oranges. For 5-6 you could start collecting continuous data like heights that is a bit more complicated. If you graphed the heights of everyone in the class as a bar chart you would likely wind up with 25 different entries on the graph, so you need to aggregate them somehow, like 100-110cm, 111-120, etc. This is a frequency graph or histogram. You can still use a spreadsheet to graph this, or you can make it an art and communication lesson by getting them to draw pictures in drawing software like Paint on a pc, or drawing or whiteboard apps on tablets, that are creative but accurate – for example using relative size, or number of items to represent the different values.
Creating Digital Solutions by:
Investigating and defining
Follow, describe and represent a sequence of steps and decisions (algorithms)
needed to solve simple problems (ACTDIP004)
Define simple problems, and describe and follow a sequence of steps and decisions (algorithms) needed to solve them (ACTDIP010)
Define problems in terms of data and functional requirements drawing on previously solved problems (ACTDIP017)
“F-2: Follow, describe and represent a sequence of steps and decisions (algorithms)
needed to solve simple problems”
This is our first encounter with the dreaded A word: Algorithms. You’ve actually already met algorithms in the form of recipes, LEGO instructions (which are particularly interesting because they are largely visual, not text based), and any set of instructions you’ve ever followed. Kids will be familiar with these too, so you have a starting point. Next time you do a cooking activity, talk about the steps you follow, the decisions you have to make – like: is the chocolate melted yet? If so move on to the next step, if not, heat it some more. Introduce the word “algorithm” for the recipe, and boom! – This line in the curriculum is nailed.
“3-4: Define simple problems, and describe and follow a sequence of steps and decisions (algorithms) needed to solve them”
Here the kids need to define a problem, like “how can someone find my desk from the door of the room?” and then specify the set of steps that someone would need to solve that problem. Then they can follow each other’s steps and see if they work. This is a fun one because you tell the kids to follow the instructions as dumbly as possible, to find problems with the algorithm. For example, if the instructions say “Walk towards the back of the room until you get to my desk” they will walk into any furniture that happens to be between them and the desk if they are really following the instructions blindly, the way a robot would. Similarly, if the instructions say “walk through the door” and the door is closed, there is a step missing that could result in a very sore nose!
“5-6: Define problems in terms of data and functional requirements drawing on previously solved problems”
To be honest, this one seems a bit strange in this context. To me it makes sense in terms of software design, but for Grade 5/6 kids it seems a bit of a reach. For kids programming in Scratch, Snap, or other visual programming languages, you can only really skim the surface of an instruction like this.
So I take it to mean that you need to lay out the problem clearly before you start to write a program to solve it. Spell out what you are going to do, and what data you are going to do it with – for example if a student is writing a program to draw a spiral, they might ask for user input for the colour and size of the spiral. This is their data. And functional requirements simply mean defining exactly what the program is going to do – in the above example, the functional requirements might be “draw a spiral in a colour specified by the user, with as many layers as the user asks for.”
The other part of this one is to relate the new problem to previous problems. How is this problem similar to something you have solved before? eg drawing a spiral is like drawing a circle, but your line has to move outwards each time rather than finishing where it started.
The next row in the table has to come as something of a relief to lower primary teachers. 🙂 The good news is that it’s actually not hard for 5-6 teachers either.
Generating and designing
Design a user interface for a digital system (ACTDIP018)
Design, modify and follow simple algorithms involving sequences of steps, branching, and iteration (repetition) (ACTDIP019)
5-6: Design a user interface for a digital system
This step is not nearly as daunting as it sounds. In a Scratch program it simply means laying out how a user will use the program. So if it’s a game where you have to click on, say, balloons, in order to pop them, the user interface will be the start button, maybe a speed selector, and using the mouse to click on the balloons. Any interaction the program makes possible – any way the user can do something to change something in the program – is part of the user interface. So anything the user will be able to do – choose a pen colour, change the speed or size of an object, click on something to make it react – is part of the user interface and can be described before the program is actually written.
These goals are all aimed at teaching planning, as well as tech stuff. It’s really easy, even for experts, to just sit down and start doing stuff before they think about what it is they are trying to do. So here the curriculum is saying “let’s think about what we’re going to do, and even write it down, before we actually try to do it.”
5-6: Design, modify and follow simple algorithms involving sequences of steps, branching, and iteration (repetition)
Here we’re talking about algorithms, or recipes, not code. So this one is about being able to lay out the steps involved in solving a problem, using repeated steps (iteration – for example “keep beating until the egg whites are stiff”, “keep walking until you reach the stairs”, or “while there’s still LEGO on the floor, pick up a piece and put it in the box”), branching (testing to see if something is true, for example “if it’s dark, turn on the light”, or “if the cake is a chocolate cake, add cocoa, otherwise add vanilla essence.”)
Producing and implementing
Implement simple digital solutions as visual programs with algorithms involving branching (decisions) and user input (ACTDIP011)
Implement digital solutions as simple visual programs involving branching, iteration (repetition), and user input (ACTDIP020)
3-4: Implement simple digital solutions as visual programs with algorithms involving branching (decisions) and user input
Write a program in a visual programming language such as Scratch, Snap, or Blockly that has decision points (if statements, also referred to in the curriculum as “branching”), and user input. An example might be a program that asks the user if they want to draw a square. If they answer yes then it draws a square, otherwise it says “Bye Bye then!”
5-6: Implement digital solutions as simple visual programs involving branching, iteration (repetition), and user input
This is the same as the 3-4 version except now we’re including iteration (loops, or repetition). So the simple square program above can be rewritten to make the repeated bits simpler and just say “do the line and the turn 4 times” instead of spelling out 4 sets of lines and turns:
Once again this has become a little long and I’m not finished yet! So in the best entertainment traditions I am going to end on a cliffhanger (ok, maybe it’s less of a cliff and more of a small step, but work with me here!) and leave you keen for part 3 (I hope!). The good news is that Part 3 will be much shorter. If you find this useful, please share it widely.
These posts are also going to form the basis of a series of Professional Development workshops run by former students of mine (only for Victoria at this stage, but there’s hope for online workshops in the future), so if you’re interested in those, and/or coding workshops that are directly tied to your existing curriculum, please fill out the poll below (purely to gauge interest levels, no names or contact details will be recorded) and watch this space!
Just went to an awesome talk by Nvidia’s Will Ramey called Deep Learning Demystified. These are my notes – raw, stream of consciousness, and unedited. But interesting! (I hope)
Algorithms that learn have in the past used experts writing programs with classifiers to eg edge detect or look for particular features. First programmer has to conceive of classifiers and then connect them together in some kind of logic tree and characterise the features sought – eg wheels are round… so you get a system for distinguishing between cars/trucks/buses but it doesn’t cope with changes such as a rainy day or a foggy day. So you have to manually create new classifiers and work out how to make it work. Doesn’t scale/translate to new problems.
New approach of deep learning uses neural networks to learn from the examples that you give it. You don’t have to manually create classifiers, you can use examples in the data itself so that the network creates the classifiers. The major advantage is that it’s really easy to extend. If you train it on cars in the daytime and then want to use it on a foggy day you just provide more foggy pictures and retrain the network. You don’t have to create new hypotheses for what might work, you leave that to the network.
With GPU accelerators the process of training and retraining the networks as you expand the amount of data is relatively fast and doesn’t require a lot of manual effort.
Stunningly effective for internet services, medicine, media, security, autonomous machines etc
Deep learning is also being applied as a tool to understand and learn from massive amounts of data.
NASA uses deep learning to better understand the content of satellite images and provide feedback to farmers and scientists studying the ecosystem about how to manage their work and increase crop productivity etc.
How do you do deep learning?
Start with an untrained neural network. Deep neural networks have a large number of layers, but might not be well connected. There are known topologies of nns that are known to be good at image classification, or object recognition, or signals analysis, etc.
In its untrained state the network is just a bunch of math functions and weights that determine how the outputs of those functions are communicated to the next level. It can’t do anything. To train a NN to distinguish between dogs and cats we assemble a training set of images. We use a deep learning framework to feed the images through the NN one at a time and check the output. If we’re only trying to distinguish between cats and dogs there will be two output nodes with confidence levels – how confident is the nn that it might be a dog, and how confident that it might be a cat? The framework already knows the answer and will evaluate whether the NN infers the correct answer, and if so it will reward the neural net by strengthening the weights of those nodes that contributed most to the correct answer, and reducing the weights of the nodes that didn’t contribute. When the nn infers the incorrect answer it will decrease the weights that contributed most. etc. You keep showing the same collection of images over and over, continuing the training. Then the NN gets very good at it. It’s almost a skinnerian psychology experiment, but without electric shocks. Showing the dataset once is called an “epoch”. It takes many many epochs to train the network properly, and that’s the job of the deep learning framework.
This is supervised learning.
Now you have a trained network that can distinguish between dogs and cats. But nothing else. If you were to show it a raccoon it would probably give you a low probability value for both dogs and cats. The trained network still has all the flexibility you need for it to learn. But in most cases once you deploy it it doesn’t need to be able to learn anymore.
Colleague at Nvidia trained a neural net to recognise cats from a usb camera and setup a system to turn on the sprinkler system when there’s a cat on his lawn, to scare them away.
In some cases in the trained network there may be nodes that don’t contribute to the answer. The framework can pay attention to that and automatically remove nodes that don’t make a difference either way, or sometimes fuse layers to save time. And now you can integrate your optimised model into your application.
Deep Learning algorithms are evolving very rapidly, and it is challenging to keep up with them. Training NNs is incredibly computationally expensive, and you don’t necessarily know what the correct topology is at the start. So you might need to tweak it many times and train one, learn from that, and then explore different possibilities, which increases the computational needs and makes it more expensive.
Once again these are rough notes, unedited, taken during an invited talk at SC16. Some fascinating ideas in here, I hope the notes are useful to you.
Maria Klawe, Harvey Mudd College Diversity and Inclusion in Supercomputing
Why diversity and inclusion matters:
increasing supply to meet demand
access to great jobs
better solutions to the world’s problems
We can’t meet that demand without enticing more people into these fields. Big data and data analytics are changing every aspect of society today. Healthcare, climate change, clean energy. Big data, supercomputing, machine learning are going to be crucial.
If you want to make a difference to the world, if you want flexibility, travel, these are really great jobs.
When you have a diverse team working on a problem you get better solutions. It can be diversity because of country, race, religion, gender, sexual orientation – greater diversity means better solutions.
Harvey Mudd is a small college focusing on science, engineering and liberal arts. Every student believes it is their responsibility to help everyone else succeed. They emphasise collaboration and communication from day 1.
30-35% of their graduates go on to get a PhD. Second only to Caltech.
In 1996 Faculty and students were around 20% female. 2016 women are close to 40% of faculty, and 50% students.
Racial diversity is also increasing.
It’s not enough to get them in the door. You have to ensure that the experience once they get there is such that they can thrive. That the environment you put them in is one where they can do well.
Females weren’t having as good an experience as the male students, because, for example, all of the speakers were white males. Usually older white males, because the faculty were older white males and inviting their friends.
“They’ll never let me tell them how to run the machine, because they say ‘you’re a girl, you couldn’t possibly know how to do this!'”
These are small things, but when it happens over and over again there is a sense of lack of belonging.
Faculty racial diversity is harder to increase than student diversity, because of low turnover. So we are training our faculty search committees on how to find a diverse pool of applicants, interview them so they have a good experience, etc. But the moment we take our eye off the ball we hire all white males.
Hypothesis: If you make the Supercomputing environment supportive and engaging for all, build confidence and community among underrepresented groups, and demystify the path to success, a highly diverse population will come, thrive, and succeed.
Minorities, like anyone, love the chance to work in an environment where the work you do makes a difference.
Make sure that incoming students feel that they belong, regardless of prior experience. We have students arriving with very different levels of prior experience.
Passionate students with prior experience in CS scare other students off.
So separate incoming students by prior experience. But you will still have some students who just know more. So I meet with the scary students who answer all the questions separately, and I give them the chance to connect separately, so that the other students have a chance to contribute in class.
If you are a female mathematician or computer scientist you go through life with people having low expectations of your technical knowledge. Which makes us more reluctant to ask for help because it seems like we’re not as competent as we should be. This is also true for HM students and many adults at all kinds of levels. So we work hard to set the expectation that asking for help and hard work are far more important than any innate ability.
In our intro classes HM have a black section and a gold section. The gold section is for the kids with no prior experience. The black section is for those who’ve had a year of CS in high school. And there’s a 42 section for the ones who know heaps.
How do you get the gold students to the same level as the kids who’ve already taken a lot of CS. You’ve got to add some extra material to the black course, and it has to be interesting and fascinating, but it has to have nothing to do with the follow on courses, so that they don’t enter the next courses privileged over the gold students.
If you tell someone they’re going to be a great CS student, it doesn’t make it happen if they come from a background where that doesn’t seem likely. You tell them “just take the next course”. And then they start to find that they’re good at it. And you keep on doing that. You make each course engaging and supportive, and make it that they can work hard and be successful. It’s also very important to give early internship and/or research experience. They need to know that what they are working on will make a difference in the world. Then they are more likely to stay in the course.
HM typically takes 40-60 students to the Grace Hopper Women in Computing conference. They take students to conferences with diverse communities to foster that sense of belonging.
They build community – clubs – and ensure access to role models – faculty, speakers, mentors from industry.
Suppose you have a very rigorous, challenging, graduate course. And suppose your students talk about it as “that’s the course where you find out if you really belong in this discipline or not. It’s a really tough course.”
That’s the worst possible way to frame a course. Because you weed out the people with low confidence.
Instead you frame it as rigorous, exciting, and interesting, and you make it clear that if you work hard and ask for help you can do well. Because anyone can do that!
You don’t need to demystify the path to success just for minorities. You need to do it for everyone. To ensure that it’s not just the dominant group who get all the tips and advantages and who therefore succeed.
Best ways to attract diverse graduate students:
Recruit diverse undergraduates for summer internships (research and industry) (start early!)
Engage diverse faculty in recruiting to PhD programs.
Recruit at institutions with diverse students.
Include D&I reports on grant applications. Funding agencies to start asking for info on the diversity of the student body and what the institution is doing to increase it. The single easiest way to get institutions to change is to tie funding to progress. So we need to do this for research funding as well.
Include diverse speakers at every SC conference. Members of program committees. Videos that you make.
(Author aside – on a personal note I would say ban your show floor companies from using women in high heels and tight clothing to interact with the crowds!)
Having a really positive experience early on makes them much more likely to do a PhD.
Numerous studies have shown that we are all biased. There was a study that showed that scientists in Biology with equal faculty gender split were given two sets of resumes. Identical except for first name – Jonathan vs Jennifer. Both male and female faculty rated Jonathan higher than Jennifer, and were willing to pay Jonathan more.
Faculty members at MIT trying to recruit would call other faculty at other institutions to ask for recommendations of PhD students, and both male and female faculty would come up with white males. But if they were then prompted for women and people of colour they would come up with several extra names. It’s not evil. It’s not deliberate. It’s completely unconscious. It’s just part of growing up in a culture where, eg all doctors are male so you tend to think that doctors are male.
So you don’t just post an ad someplace, you actually reach out and ask people, and you ask explicitly for diversity.
It’s illegal in North America to ask about partners, marriage, and plans to have children. You need to make very sure that your recruiters know they can’t ask those questions.
“It gets really tiring to be the female who’s arguing for women. If you’re black it gets very tiring to be the black person. But this is the responsibility for everyone, not just the members of underrepresented groups.”
One of the big obstacles to diversity in computing is that people don’t see its relevance to them. They can’t picture themselves as part of the field. They don’t really know what the field looks like, but they have vague images of spotty youths in darkened basements with endless supplies of pizza and coke.
That could not be further from my experience of computing, and of computing professionals. Everyone has a different story, and well over half of the people I talk to never actually intended to go into computing. In fact I was one of those people. I confessed at a school assembly recently that I actually wanted to do medicine, but I didn’t get in. I played with computers a bit in school and thought they were fun, but I never saw myself as a computer person.
I took Computer Science as a fill in subject in first year, and was rather surprised to find myself doing all CS by third year. I was even more startled to find myself in honours, and the PhD came as a complete shock. I certainly never intended to become an academic, and teaching was not on the agenda at all. You may have noticed I suck at predicting my career path.
So my path into CS was not normal, but it turns out that not normal is quite normal where CS careers are concerned. No two stories are alike.
Among the many mind blowing things I did today, I was slightly startled to find myself participating in a user experience test. But conferences are full of surprises and unexpected connections. Having a background in usability myself, I couldn’t say no to the opportunity to pick holes in someone else’s software.
User experience tests are interesting. You get given a task – not a set of instructions, but a goal to complete – and set free on the system to see how you go about solving it. Is it easy or hard? Which features of the system help you, and which ones get in your way?
The User Experience guy who conducted the test, Craig, could not possibly have been nicer, and he went to great lengths to explain that it was the website on trial here, not me. “You can’t do anything wrong!” he told me. I was relaxed, and comfortable, and interested in the site. It looked like being a fun experience.
But an interesting thing happened. Despite a constant flow of reassurance and encouragement from Craig, I began to get stressed. There were… let me be tactful… some issues with the website. I couldn’t complete some of the tasks. If I’d been hooked up to any kind of physiological monitor you’d have seen my heart rate skyrocket. My breathing became rapid. I began to sweat.
Why? Because I couldn’t complete the tasks. Tasks that were a test of THE WEBSITE. Not of me. But a little voice inside my head started to say “I’m going to look stupid because I can’t figure this out.”
“Someone smarter would know that bit of jargon.”
“It’s probably staring me right in the face, but I just can’t see it. I’m so dumb.”
Over and over Craig told me how helpful this was, how I was doing great, and how it was so useful to see the issues I had with it. He told me that they could never have figured out the problems without me. He was lovely. Honestly, you could not pick a nicer, less scary person to conduct the test. But because I was having a hard time using a website that I knew there were issues with, I was judging myself.
That’s why usability matters.
Because when a piece of software is hard to use, crashes, or does something unexpected, even people with a PhD in usability blame themselves. People work with complex systems all the time – laptops, tablets, sound systems, even televisions. And in subtle (and not so subtle) ways those systems tell us that we are dumb. That we are too stupid to figure them out. That we make mistakes all the time.
As Katharine Frase pointed out, we try to learn to use fundamentally unusable systems, when those systems should actually be learning to work with us.
So next time you struggle with a piece of software, repeat after me: I’m not hopeless with computers. Computers are hopeless with me.