Digital Network Hackathons at the ABC

This post probably needs a bit of context before we dive in: I’m a Senior Developer at the ABC, and I’ve been working there almost a year.

I get to work on products that people use day-to-day, which is great, but I’ve also had the chance to pour effort into things I believe are fantastic for a development team: driving the ABC’s involvement in GovHack 2015, efforts in diversity, and the best part… not just one, but two internal hackathons to drum up some inspiration and build communication links within the division.

On the roadmap is an ABC Development blog, with contributions from various developers in the team. Unfortunately it hasn’t got off the ground yet 🙂 The blog would be perfect to talk about these hackathons, but since that space doesn’t exist yet, I’m doing so here.


Earlier this year, the ABC was undergoing a restructure of all its digital teams into a single Digital Network division. With the restructure, we really wanted to help bring together separate teams – who often sit on separate floors, and rarely get to interact – around a fun event.

Our main aims were to introduce people to others, and foster new communities within the dev team. It was also a great chance to let people flex their creativity muscles, and build prototypes for future products or features.

Our Challenges

The ABC has a lot of developers with different technology backgrounds, and we wanted to ensure that everyone had a fair opportunity to join a team and build something that interested them.

We also have many colleagues who work interstate. Facilitating teams and introducing everyone to each other was a bit of a puzzle, especially since we wanted to have team formation and idea pitches done before the day.

We’d also never run a hackathon at the ABC before, so we were given the chance to run a small-scale version in March to help us prepare for a larger, two-day event in June.

The First Hackathon

This was a one-day event held at the ABC in Ultimo. We invited 20 people from ABC Innovation (later Digital Network) and gave them 6 hours to build anything they wanted.


Seven teams produced a variety of hacks, surprisingly all ABC related, and had their demos watched by an audience of around 60 staff.




We got a lot of great feedback:

  • People really enjoyed meeting and working with others they didn’t know
  • It was fun working on something different
  • It was great getting the chance to build something you’ve wanted to for a while
  • Showing off the hacks to an audience was satisfying

We also learned what to improve for next time:

  • Attendees needed more lead time so they could prepare an appropriate idea, research what data they’d need, and explore what technology they might use to build it
  • Including a wider range of staff such as product managers and more designers would produce more diverse hacks
  • All attendees would benefit from guidance for hack presentations, including sample slides
  • The biggest challenge was team formation, especially considering the next event included interstate staff

The Second Hackathon

Our second event was much larger, with around 70 people hacking over two days at the Powerhouse Museum, just down the road from the ABC – complete with Angry Birds and Minecraft.


Given more time to hack, and more time to prepare, there was a big improvement in the quality of the hacks compared to the first event. It was also great to have all the teams from interstate mingling together in the same room.

Our main feedback (aside from faster wifi!) was still around team formation: teams had to be composed of people who didn’t work together normally, and were capped at 4 people. If someone hadn’t found a team a week before the hackathon, they would be allocated at random. Given how dispersed people are physically, it favoured people who already worked on the same floor, or knew other people socially. So, there are still things we can improve with this process.


For more coverage of the second hackathon, there is a complete rundown of the day, including summaries of the projects, photos and winners available on Storify in reverse chronological order. 🙂


Looking forward to the next one!

My love of travel (and London)

For a blog that is supposed to be about coding, cake and travel, there has been zero talk of travel so far. Mostly because it’s hard to distill something so complex and meaningful to me down to a series of words. 

I love travelling because you experience new things. You decide when you want that experience, and how much you’re comfortable spending on it, which means that a destination that’s two hours away by car can be just as meaningful as somewhere halfway across the world. New people, new foods, new vistas, new neighbourhoods and new languages present a different life that someone else gets the chance to live – and you could have it too. Change is good. 

I love travelling because it helps you realise your true personality by challenging you. When you’re dropped in the middle of a foreign city, you don’t speak the language, you’re lost, and you’re trying desperately to do something before a deadline, it’s amazing to realise how resourceful you can be, and how you handle stressful situations.

I love travelling because it’s freeing. There’s no schedule, except for how much you choose to put on there – whether it’s 14 hours of sightseeing, soaking up a neighbourhood by living local, or taking six months out to explore at your own pace. Nobody knows you, so nobody has any expectations of how you behave. You’re free to do whatever you’d like to, whenever you’d like to. 

Travel gave me my second home.

I visited London on a trip in my early twenties, and fell in love with it. 

One year later, I decided to move halfway across the world and settled there. It was the best decision of my life. I loved the culture, people, buildings, history, transport system, and the variety and pace of life, and I let it all soak in to my skin.

Most importantly, living in such close proximity to so many different countries in Europe was an amazing opportunity for someone who grew up in Australia. Every long weekend in the British calendar was eagerly planned in advance – will it be France, Iceland or Norway this time? Hiking, sightseeing, or wine country? No matter the destination, everything seemed just two hours away, and so easy to do straight after work on a Friday evening.

I gorged myself silly on it, visiting around 20 countries while I lived there, and some – like France – over a dozen times in an 8 year period. I’d kick off spring in Munich, cycling through gardens, drinking steins and eating giant pretzels. Then head to Croatia in summer, cruising from island to stunning island, devouring gelato and lazing in the sunshine. Then Switzerland in autumn, hiking through the riot of foliage colours and breathing in the crisp air. Winter would be France, boarding down a mountain of snow. 

I loved all of it, but I also enjoyed just being in London – the cozy pubs, delicious cheeses, Georgian houses and self-deprecating humour. And of course, the queuing. Living there was one giant, extended holiday where I grew up and learned things. 

Travel gave me a chance to learn who I am. 

I’ve taken three life breaks from my career to go travelling, without knowing when I would settle down and start working again. They add up to over two years of my life, and were completely worth it. 

Those breaks have shaped my existence. They’ve given me time to think about what’s important to me, and to take steps to make sure I can pursue them. They’ve let me experience things that enrich me as a person, and make me eager to come back and learn more.

I realise that I like learning things – whether astronomy, technology, experimenting with startups, or how to make giant food. I know how few possessions I actually need, since I’ve managed out of a suitcase for 6 months. I know that beautiful landscapes rejuvenate me more than the bustle of a new city. And I am grateful for the fact that I can afford to travel, both with money and time. 

Travel has given me some fantastic memories.

There’s an incredible list of things I’ve had the opportunity to do in the past ten years: driving over giant salt plains in Bolivia, visiting art galleries in Italy, tasting wine in Argentina, exploring Iceland with a car and a paper map, swimming with sea turtles in the Galapagos, gorging on pastries in France, staying in tree houses in Laos, sleeping under the desert stars in Jordan, hiking around glaciers in Chile, racing a dog-sled in Sweden, hiking the Inca Trail in Peru, exploring the amazing temples of Angkor Wat in Cambodia, photographing the wilderness of Scotland, partying until dawn in Barcelona, partying (slightly differently) in Amersterdam, marvelling at the opulence of the Moscow Metro, cooking up a storm in Vietnam, riding camels in Egypt, snowboarding powder in Japan, jumping around the USA like a kid in a candy store, and soaking up everything I possibly could in my surrogate hometown of London. 

Moving overseas was the best thing I’ve ever done. It made me realise that anything you want to do is possible, if you decide to do it. It also made me realise how adaptable human beings are, and that generally things will work out okay if you are flexible and recognise opportunities when they appear. And you’ll have loads of fun in the meantime. 

I found the draft of this post on my laptop, a year after I started it. I finished it on various planes and trains zipping around Europe, which I thought was apt. I miss you, London. x

Running Women Who Code

I’ve helped to run Women Who Code Sydney for about a year (along with Lucy Bain and Peggy Kuo), and it’s been a blast. We organise practical hands-on workshops for a variety of technology like Arduino, Golang, Sass, Scala and Swift.

Participants spend about 1.5-2 hours working through a tutorial or problem set on their laptops, and can ask volunteers for help if needed, so it’s slightly different to a typical user group: the attendees are expected to code at every event.  I know that I personally learn more when I’m forced to do something, as opposed to listening to someone’s experience, and after you’ve done the workshop, everything’s installed on your laptop ready to experiment more at home.

A typical event might be:

  • 6:00pm: Arrive and dinner, chat to others
  • 6:30pm: Announcements and introductions
  • 6:40pm: Speaker topic for the night (e.g. introduction to Reactive Extensions)
  • 7:00pm: Commence hacking
  • 8:45pm: Feedback forms
  • 9:00pm: Finish

Things I’ve learned while running a hands-on user group:

Have a target that people can aim for
Inviting people to “learn some javascript” where there’s no specific learning material makes for a confusing meetup, because there’s no target to aim for. People will ask a variety of questions from all different angles (e.g. “what does var mean?”, “what do you think of angular vs react?”, “can you explain promises?”). If you provide a tutorial or set of exercises, there’s a defined path that is supposed to be followed to learn something, which cuts down lines of questioning and also provides people with a goal.

Designing a tutorial from scratch takes a lot of work (and rework).
You’re not likely to get it right on the first go, so unless you’re aiming for something you can re-use, you are better off going with already published material.

Utilise existing interactive online tutorials
They’re a big win. The tutorials have already been tested by hundreds of people before you, and someone has put a lot of effort into designing them. They explain concepts step-by-step probably better than you will first time.

Always try out the tutorial first
It’s important to gauge difficulty and identify what prerequisites are required. Also, sometimes the instructions change and it’s not the same tutorial any more!

Give people the answers upfront
If you are writing a custom set of exercises or tutorial, give everyone access to the answers. When people start with a working solution, it’s a lot easier to break various bits to see what they do, rather than having broken code and trying to diagnose what needs fixing.

Have some helpers available to answer questions
This is the thing that people don’t have access to at home. It really helps.

Aim to maximise everyone’s learning experience
You won’t actually cover that much material in a two hour window, so try to pick content that people can try at their own pace – that way everyone learns something.

Select an audience for your meetup
Choose either beginners, or people who are already familiar with programming. It is very difficult to cater for both at the same meetup.

Clarify prerequisites
State whether people need to understand simple if/else statements, or something more involved like recursion. If people turn up to an advanced tutorial but only know basic programming, they might start feeling like they don’t know anything and get discouraged – that’s the last thing you want!

Limit the speaker’s time in chunks
A 10 or 15 minute window is a good amount of time to keep people’s attention (especially after they’ve done a full day of work). Talk for a bit, let people experiment and try what you talked about. Repeat. This is difficult to keep in balance with a self-paced set of exercises, because some people will be ready for the next section before others, but it keeps people focused.


Review of Coursera’s Algorithms Part I by Princeton

This is the first in a series of two posts about a study group I organised for learning Algorithms & Data Structures. This post focuses on the content of the course, which is Princeton’s Algorithms I on Coursera.

The course covers a variety of data structures and searching and sorting algorithms from a programmatic implementation angle (as opposed to mathematic proofs; more on that in my second post). Specifically, this one covered union-find, binary search, stacks, queues, insertion sort, mergesort, quicksort, binary heaps, binary search trees and red-black trees, and a lot more.

The course has multiple types of content to help you learn:

  • The major component is the video lectures, which form about 2.5 hours of content each week and present some algorithm theory
  • Detailed lecture slides
  • Exercise questions, which test you understand that theory
  • Assignments, which make you put an implementation of an algorithm in practice
  • Final exam (I haven’t done this yet, but I still have a few weeks.)

Officially, the course is 6 weeks long, and requires 6-12 hours a week of effort. I think most people in our group underestimated how much time this really takes from your life.

Good things about this course

The combination of lectures, exercises and assignments was a really good way to cover the material from different angles. If you appreciate structured approaches to learning, this will tick all the boxes.

Videos: All of the material is professionally shot and edited. The entire series is presented by Robert Sedgwick, who is a very good lecturer. There is a good level of detail and explanation for each algorithm, especially the animated walk-throughs of each sorting algorithm. You have the option of watching the videos at a faster speed on the Coursera website, and I chose to watch it at 1.25x most of the time, as Sedgwick speaks quite methodically but slower than I am used to. (If you download the videos, you can’t take advantage of this feature, and you also miss the interim quizzes in the videos). It’s very helpful watching videos instead of listening to a live person, as you can pause them and rewind whenever you need to.

Slides: The slides are great. Very detailed, well-laid out and with diagrams to illustrate various concepts. The only thing missing from the slides were the animated walk-throughs of how each algorithm works, but you can always re-watch the videos.

Interim quiz: at the end of each video, and sometimes in the middle, you have to answer a question about the content you just watched.

Discussion boards: The Coursera site includes discussion boards where you can post questions. They’re monitored by people at Princeton who are helping to run the course. It’s a great resource when you get stuck.

Auto-marking for assignments: Assignments are all auto-marked for each submission, and the results from marking are really detailed. Each submission is run though lots of tests, and it also analyses your usage of memory & time relative to input (i.e. are you using constant, logarithmic, linear, quadratic time, etc). I found this quite valuable.

Real-world examples: Discussions of practical implementations of algorithms, such as a physics engine for particles, or easily finding whether lines/objects intersect, were really interesting.

Credibility: Sedgwick is a professor at Princeton’s school of Computing Science. You’re hearing from one of the people who has spent a lot of their life studying and working with algorithms – he’s written several books on algorithms, one of which is used as a reference for the Coursera course (the content is available for free on a corresponding book site). He also found a more efficient variant of Red-Black Trees in 2007, which he discusses in the lectures.

Choose your level of participation: You can cut out various parts of the course if you prefer – for example, if you were to only watch the lectures and make your own notes, you could spend 3 hours a week doing this course and still get something out of it. The minimum I’d recommend is watching the lectures and doing the exercises, as the exercises force you to step through the algorithms and work out what they’re doing.

Language-independent: It’s possible to complete these assignments in different langauges, as our study group proved. We had people write solutions in Rust, Python, Golang, C# and Scala. However, the majority of them completed in Java to take advantage of the auto-marker for the assignments.

Things I’d change about this course

Assignments not geared for unit testing: The APIs for the assignments were quite strict – it was almost impossible to test using dependency injection, or trying to refactor one giant (public) method into smaller public methods so you could test them independently. I did write some tests, but I also ended up submitting assignments to the auto-marker to get feedback for some aspects. I’d prefer if the API was less strict so that you can package your own classes, and break things into smaller chunks.

The assignments vary in complexity. Some require only 2 or 3 hours; others could take another 10 hours just by themselves.

Course schedule: The start date and schedule of the course is advertised as fixed, and quite intense. When they say you need 6-12 hours, they do mean it (and more). In reality, all assignments and lectures have “hard” and “soft” deadlines, and can be submitted up to 6 weeks after the lecture is released.  If we had known, we would have built some catch-up weeks into our study group dates to allow people to keep pace. This isn’t Cousera’s fault, but some knowledge that the content would be around for ~3 months would have helped plan a better schedule for our study group.

Some content not as relevant: This is a personal preference, but the course covers a lot of different searching and sorting algorithms in depth; in reality only a handful of them are in use by major languages. I’d prefer to concentrate on the ones in use, and not cover the ones that have been superseded.


The course was intense, but I learned a lot and it helped connect some dots on how to solve particular types of problems. For me, the best moment was an email from Aidan, one of our study group members, in the last week:

I actually used a weighted quick-union at work yesterday! Im as shocked as everyone else.

Proof that it is actually relevant 🙂

As for Algorithms Part II, I’m sadly stretched working on various things in life, including this blog, Women Who Code Sydney and organising a variety of things with my work at the ABC.  However, Caspar Kreiger is continuing the second half starting this week, so get in touch if you’re interested!  I plan to pick up Part II in October when it is run again.

Study Group: Algorithms & Data Structures

Since doing a Javascript study group last year, I’ve been keen to organise a Data Structures & Algorithms study group (partly to brush up on interviewing).

I’m pleased to announce that the study group will start January 28th. If you’re interested and live in Sydney, read on.

What will I learn?

We will be doing the Algorithms I course by Princeton university.

It involves a series of lectures & quizzes you watch at home, followed by a group meeting every Wednesday. At the group meeting you can ask questions about anything you didn’t understand, and start to go through coding exercises.

The course material is presented in Java, however you can choose a language of your choice to complete the problems. If you would like Coursera to mark your assignments and final exam, you would need to complete the course in Java. (Note: Completion certificates aren’t issued for this course.)

If you are unsure of Java syntax, please read up on a quick syntax guide before starting the course.

Where and when do we meet?

Atlassian has kindly agreed to host our meetings. Their office is Level 6, 341 George Street Sydney. The building entrance is off Wynyard St.

We’ll meet on Wednesdays at 6:30pm (please be prompt).

The course is 6 weeks and runs from January 28th until March 4th. There will be an optional week after the course ends to practice answering technical interview questions.

How much will it cost?

The course is free if you attend 5 out of the 6 meetings. You can skip one meeting without a penalty.

Everyone will be asked to pay 6 x $10 per meeting at the first meeting, a total of $60. For every meeting you attend, you’ll be credited $10 back.

For anyone who misses a meeting, their money goes into a pot. At the end of the course, the pot will be divided among the people who attended the most meetings. Nerdery pays 🙂

This is mainly an attempt to identify the people who really want to participate, and to motivate people to stick with the group.


This is not a beginner’s course. You should:

  • Be able to code confidently in a language of your choice
  • Be comfortable with git
  • Understand the concept of a class, objects, functions, arrays, lists, sets, loops, recursion and the core types available in your chosen language
  • Understand what unit testing is
  • Be willing to discuss your approaches to problems, and demo code
  • Be willing to spend 4-12 hours a week watching lectures and completing code assignments

I’m not teaching this content, I want to learn it and would like other motivated people around at the same time.

How can I sign up?

The study group will be limited to 15 people. The first 15 people who contact me (@daphnechong) and bring a refundable $60 to the first meeting will be eligible.

See you there 🙂

Hello, Arduino

Last September, Women Who Code Sydney ran a Learn Arduino event. I’m generally not very keen on hardware, so I hadn’t bothered to investigate Arduino in depth, but this blinking green light from the workshop was one of the most exciting things I’d seen in ages. It was programming in physical form: I’d written the code, sent it to the motherboard, plugged in the wires and resistors to control the current, then seen something in my environment that I could actually touch and change.


Arduino has been around for a while. It is a small version of a computer with very simple inputs and outputs, and that’s what makes them really fun to play with.  There are lots of different input sensors you can use, like temperature sensors, movement, infrared, light.

It’s fairly inexpensive to get a basic Arduino kit, as cheap as $30 depending on where you get it from. Atlassian kindly sponsored our event and donated 20 starter kits which included the basic Arduino board, and a whole lot of extra sensors to play with.

  • 1 x 830pt Breadboard
  • 4 x LED
  • 2 x RGB LED
  • 1 x 9V Plug
  • 1 x 9V Lead
  • 1 x Breadboard Power Module
  • 4 x Tactile Switch
  • 1 x Small Slide Switch
  • 10 x Resistors
  • 1 x pack of jumper wires
  • 1 x Light Dependant Resistor
  • 1 x Small Plastic Servo
  • 1 x Buzzer
  • 1 x Linear Rotary Potentiometer
  • 1 x Ultrasonic Sensor
  • 1 x Hall Effect Sensor
  • 1 x 7 Segment Display
  • 1 x Temperature sensor
  • 1 x IR phototransistor
  • 1 x NPN transistor BC547

Our host, Natalia Galin did a phenomenal job preparing for the event, even down to these cheat sheets with components separated out and nicely labelled, which made it easy to work on our tasks.


First up was a crash-course on electronics, and how the Arduino’s breadboard circuitry works.


Then a series of programming tasks to connect up the wiring so that lights work, and using physical switches to turn lights on and off. It was addictive!

We were limited by how many kits were available, but we had around 25 people attend the workshop, and the atmosphere was great. A huge thanks goes to Google for sponsoring the venue and catering for the night, and Atlassian for the Arduino kits.