In 2014, I started filming what I thought would be a short Youtube video. 6 years, 55 interviews, 145 hours, and 6.5TB (yes, Terabytes) of footage later, the Debugging Diversity project has become so much more than I ever could have imagined.
The reasons this project has taken (and continues to take) so much time are 2-fold. Firstly, me. I have a fulltime job and this is really a labour of love that I aim to work on every day but of course there are only so many hours I have spare. And more importantly because the film’s evolution has mirrored my own learning journey. Every discussion I have, every article I read and every interview I shoot I learn something new. In some cases strengthening the film’s narrative. …
Since working on Debugging Diversity I’ve often been asked why I decided to embark on the project. While most are supportive, many women have told me that their first response to Debugging Diversity is confusion; others frustration or even anger.
These reactions are completely understandable and in this post, I want to share my motivations for creating the film. Not necessarily in an attempt to change anyone’s viewpoint but simply to start a dialogue about why I believe a film like Debugging Diversity is important.
The journey started back in 2014 when I started a Youtube channel about coding and technology called CODR.TV. When brainstorming topics for the channel someone suggested I explore why tech is so male-dominated. Having been curious about this myself I embarked on creating a short video for the Youtube channel. …
After over 4 years of research and filming, we are excited to launch our Indiegogo fundraising campaign today.
The campaign will run from June 17th through to August 3rd in which time we hope to raise $24,000 (AUD).
We are thrilled to be launching our campaign on Indiegogo. While we did explore other funding options such as a corporate investor or a commercial network, we settled on crowdfunding as we felt it gave a good balance of flexibility and creative control. We also wanted to make sure that we could maintain an unbiased narrative throughout the film.
Funds raised from the campaign will be used for additional filming, equipment, location hire and post-production. …
I’m a software engineer — or what many refer to as a coder, developer or just a “dev”. In my almost 20 years working in the industry, I’ve have often wondered why engineers and coders tend to be white men.
In 2014, having developed an interest in film-making, I decided I wanted to explore the idea of making a short film about diversity in technology. Little did I know just how little I knew about this problem! In fact, this realisation began a journey of discovery and self-reflection that would span the next 5 years.
Fast-forward to today, and I still by no means have all the answers but I have learned a great deal. I want Debugging Diversity (both the film and this blog) to be a collection of ideas and lessons to help others champion change. …
Way back in 1994, I started learning how to code. I look back on those early days of experimentation with great fondness. My journey kicked off after a friend of mine showed me a program he’d written in QBASIC on his IBM 386 PC. I was mesmerised by the idea of being able to control the PC with lines of code.
With the help of a book and the Microsoft QBASIC help files on my 286 PC which I bought second hand for $200, I quickly started writing programs. It was delightfully carefree and my only goal was to create things that were cool or interesting. I had little understanding of the underlying concepts in the code I was writing. …
Non-coders might be forgiven for not truly understanding what a software developer does exactly — from the outside looking in it probably looks like black magic trickery combined with a scene from The Matrix.
However, after 15 years running software teams, I’m still surprised by how many developers themselves don’t truly understand their role.
“How could this be?” you might ask. After all, a coder’s job is to write code (it’s in the title!).
Well, let me offer an alternative perspective: a software developer’s role is not actually to write code at all. Code on its own, without a way to interact with it, without context or a clear imperative, is useless. …
If you’re a developer with a job, you’ve probably done a coding test but the take home test isn’t as valuable as you think.
I remember interviewing with a company in the US (I live in Sydney, Australia) a number of years ago who gave me a coding challenge. As I stumbled through it at some ungodly hour, 5 (yes, FIVE!) other engineers watched me type every line of code as I screencast my work on Google Hangouts. Even for an experienced engineer like myself, this was nerve racking and I absolutely did not perform at my best.
The issue with this sort of approach is quite simply that it’s unrealistic. If your engineers are as nervous as I was during a test like that on a daily basis you have bigger problems. When validating candidates you need to challenge them without having them turn into useless stress balls like I was during that early morning coding test. …
An open letter to the Morrison Government.
-----BEGIN PGP MESSAGE-----hQEMA5NjHU5k4/IIAQf/TIigoL4IDyaDvKSGVYh4r+3Aay6Ux7C6EliUgFwrPf+m
I’ve been coding for a pretty long time. Since 1994 if you include the early Q-BASIC programs I wrote as a teenager. I’ve always believed that if there were important gaps in my knowledge I could work to fill them pretty quickly. As the web development world emerged in the late 90’s this belief caused me to form the opinion that all web developers should be “full-stack”.
A “full-stack” developer (while a pretty overused term) is generally accepted to mean that the developer is capable of writing code for both the server and client (browser) parts of a web application. For many years, I considered myself a full-stack developer. …
Today I realised that you can curry functions in Elixir and it kind of rocked my world.
Why is this useful? Well imagine you have an arbitrary list of numbers and you want to multiply each element in the list by 5. You could achieve this with an enumerator:
Enum.map([1,2,3], fn elem -> elem * 5…