What did we do? #
Mimmit koodaa is an organisation based in Finland that aims to provide free training to women who are interested in programming. The need for this is clear - it's no secret that there is an incredible gender imbalance in the tech industry, and for this reason it becomes necessary to provide as much of a helping hand as possible in order to facilitate women's path into tech. So when we were given the opportunity to work alongside Mimmit koodaa to help give women take their first steps into tech, we were more than happy to obliege.
We wanted to show our participants that surprisingly little programming knowledge is needed in order to create a piece of software that has real business value. We also wanted to familiarise our participants with ecommerce platforms, as these are tools that we utilise on a daily basis with our clients. These two ideas converge with the help of Shopify, a popular managed ecommerce platform, and the ease in which it allows you to create custom elements for your online store - provided you know (or have someone who is willing to teach you) a little bit of HTML and CSS.
There's no near-horizon benefit doing this from a business perspective: we don't go into such events with a recruitment focus, we're not selling a product to potential customers, and I could probably have used this time to make more money for my company elsewhere. But, this highlights the fact that Futurice and Columbia Road both have a vested interest in improving the communities that helped us get to where we are now. We are all responsible for improving our environments, and that's what makes it special for me to get involved in such events.
From zero to HTML, CSS and Shopify ready in one day #
We started the day with the assumption that our participants knew absolutely nothing about web development, so this meant that our promise for the day was quite a considerable one: How is it possible to teach two very different languages (each of which being a product of tens of years of iteration and refinement), and a platform where they can be integrated together in a day? The answer is deceptively simple (and also makes for a great click-bait headline).
You don't have to actually teach the content. Just let people follow your lead and give them the courage to continue learning in their own time. It's that simple.
If we were to give a pop quiz at the end of the workshop on the days content, I'm sure many of the participants would score very little. This is totally fine, and we actually aim for this! There is no expectation for the knowledge of HTML elements and CSS properties to be immediately carved into your long-term memory at the first time of asking. The most important aspect of this is ensuring that participants are able to follow along, while understanding the reasoning behind each change that is made in the code.
After this is considered, it's not actually that important to give a step-by-step run down what was taught on the day. We told our participants details such as what HTML element attributes are, and how to make a CSS query selector for an element by class name, amongst other things. But, with each step that we took, our audience reciprocated, and we made sure that no one was left behind.
Ego-stroking phrases don't generate value - you do #
I'll say this upfront: the tech industry (particularly the more academic areas) have a fantastic affinity with over-complicating relatively simple concepts by throwing ridiculous arbitrary terminology everywhere. It's often not necessary, and it can even serve as a barrier to those wanting to get involved in tech. With this in mind, we set out to teach the basics of HTML and CSS in the most buzzword-free means possible.
An example - What does HTML/CSS stand for? Let me tell you a secret:
It doesn't matter - nobody really cares.
These points (to me) are so important to drive home, especially to newcomers. It doesn't matter what concrete definitions you're able to recite, what matters is the value that you create. Everything else is just a way to make it sound like you really know what you're talking about.
None of us know what we're doing and that's OK #
On the day of the workshop, a participant mentioned to me how relieved they were that we kept reinforcing this idea that we are constantly googling everything. Whilst this was certainly intentional, it still reinforced this idea for me that many people must assume that developers are somehow magically able to retain all of the knowledge that they use on a daily basis, without the need for constant referral from the internet. Of course, this isn't true. On the day of the presentation, we aimed to push the participants to solve their problems by looking on the internet (by giving them a helping hand on where to start). OK, so you've forgotten how to add a source to an image tag, how about we start looking on the Mozilla Developer Network (MDN) for the
By giving participants starting points on where to look for answers to their questions, and also how to ask a question effectively, we're able to break down this illusion that developers are some kind of all-knowing code-generating powerhouses. Furthermore, we encouraged participants to browse through documentation, and tried to spark curiosity within them of what they are actually capable of generating with surprisingly little knowledge.
Be curious, ask questions #
In one part of the workshop, we got all participants to go to a website (actually, it was this website) and have a look at the underlying HTML via the inspector. After this, we made sure to encourage the participants to go to any site and repeat the same process. It's easy to write off certain websites such as Facebook because they have many talented engineers making very large sums of money to ensure that their site is built to the highest quality. But, by opening the inspector and seeing that really, it's just HTML, you can (hopefully) demystify this idea that the Facebook engineers are in another class of programming to the rest of us.
One critique I would give to myself through all of this would be to encourage the audience to ask more questions. It's very easy to give a presentation with smaller amounts of audience interaction. But this places more importance on the actual content of the presentation being interesting. When you get the audience to ask questions, they understand things more clearly, they are encouraged to think outside the box and as a result (hopefully) the workshop leaves more of a lasting impression.
Giving tech presentations is stand-up comedy for nerds #
I had the pleasure of watching Richard Feldman give a talk at ClojuTRE earlier this year titled "Why Isn't Functional Programming the Norm?" (I would thoroughly recommend giving it a watch, it's very insightful/entertaining), and what particularly stood out to me was the way that he delivered his talk. At points, it felt closer to a stand-up comedy set rather than a tech talk. Taking this approach meant that the audience were comfortable and the serious points that he was trying to make were more easily digestible.
So, naturally I felt the need to try and add some humour to a (if I'm honest) quite bland topic of presentation (HTML tags and their usages). I ended up with this slide:
I'm not sure how well this hits the mark of making the process of learning HTML tags more enjoyable, but I had a blast making this slide, and that's good enough for me.
To Summarise #
Teaching women how to code in one day was always going to be a pretty daunting (and if we're honest, impossible) task. However, it's for a cause that we're all obligated to push, which is making tech a more diverse and welcoming place. We sought to give confidence our attendees by showing that we're all really just living by the "fake it 'til you make it" philosophy. We also showcased that programming doesn't need to be that scary if you know what questions to ask, and where to get the best answers. Finally, we tied this to a real-world business case (in true Columbia Road fashion) by helping our attendees code a part of an ecommerce store, from scratch.
Personally, this was an incredibly fun and rewarding experience, and helped me get a bit more comfortable when presenting to audiences. I made stupid slides, told stupid jokes and had some great conversations. And if someone decided to look into programming in their own time after the session finished, then that's a victory in my eyes.