Git is a very common tool in modern development workflows. It’s incredibly powerful, and I use it all the time — I can’t remember the last time I used a version control tool that wasn’t Git — but it’s a bit of a black box. How does it actually work?
For a long time, I’ve only had a vague understand of the Git’s inner workings. I think it’s important to understand my tools, because it makes me more confident and effective, so I wanted to learn how Git works under the hood. To that end, I gave a workshop at PyCon UK 2017 about Git internals. Writing the workshop forced me to really understand what was going on.
The session wasn’t videoed, but I do have my notes and exercises. There were four sections, each focusing on a different Git concept. It was a fairly standard format: I did a bit of live demo to show the new ideas, then people would work through the exercises on their own laptop. I wandered around the room, helping people who were stuck, or answering questions, then we’d come together to discuss the exercise. Repeat. On the day, we took about 2 ½ hours to cover all the material.
If you’re trying to follow along at home, the Git book has a great section on the low-level commands of Git. I made heavy reference to this when I wrote the notes and exercises.
When I go to tech conferences, I’m often drawn to the non-technical talks. Talks about diversity, or management, or culture. So when it came to make a proposal for this year’s PyCon UK, I wanted to see if I could write my own non-technical talk.
Talking about diversity and inclusion can be tricky. It’s easy to be well-intentioned, but end up saying something that’s harmful or offensive. But it’s an important topic — the tech industry has systemic problems with inclusion, and recent news shows us how far we still have to go. I chose it for both those reasons — in part because it’s an important topic, and in part to challenge myself by speaking about a topic I hadn’t tackled before.
This is a talk about privilege. It’s about how we, as people of privilege in the tech industry, can do more to build cultures that are genuinely inclusive.
I first gave this talk at PyCon UK 2017. You can read the slides and notes on this page, or download the slides as a PDF. The notes are a rough approximation of what I planned to say, written after the conference finished. My spoken and written voice are quite different, but it gets the general gist across.
If you’d prefer, you can watch the conference video on YouTube:
As I write this, it’s the last day of PyCon UK. The air is buzzing with the sound of sprints and productivity. I’ll write a blog post about everything that happened at PyCon later (spoiler: I’ve had a great time), but right now I’d like to write about one specific feature – an idea I’d love to see at every conference. I’ve already talked about live captioning – now let’s talk about quiet rooms.
I’m an introvert. Don’t get me wrong: I enjoy socialising at conferences and meetups. I get to meet new people, or put faces to names I’ve seen online. Everybody I’ve met this week has been lovely and nice, but there’s still a limit to how much socialising I can do. Being in social situations is quite draining, and a full day of conference is more than I can manage in one go. At some point, I need to step back and recharge.
I don’t think this is atypical in the tech/geek communities.
So I’ve been incredibly grateful that the conference provides a quiet room. It’s exactly what the name suggests – a space set aside for quiet working and sitting. Whenever I’ve been feeling a bit overwhelmed by the bustle of the main conference, I can step into the quiet room. Some clear head space helps me through the day.
If there hadn’t been a quiet room, I’d have worn out much faster and probably been miserable towards the end of the conference. It made a big difference to my experience. I think it’s a great feature, and I’ll be looking for it at the next conference I attend.
This weekend, I’ve been attending PyCon UK in Cardiff. This is my first time at a PyCon (or indeed, at any tech conference), and one nice surprise has been the live captioning of the talks.
At the front of the main room, there are two speech-to-text reporters transcribing the talk in real-time. Their transcription is shown as live, scrolling text on several large screens throughout the room, and shows up within seconds of the speaker finishing a word.
Here’s what one of those screens looks like:
I’m an able-bodied person. I appreciate the potential value of live captioning for people with hearing difficulties – but my hearing is fine. I wasn’t expecting to use the transcription.
Turns out – live captioning is really useful, even if you can already hear what the speaker is saying!
Maintaining complete focus for a long time is remarkably hard. Inevitably, my focus slips, and I miss something the speaker says – a momentary distraction, my attention wanders, or somebody coughs at the wrong moment. Without the transcript, I have to fill in the blank myself, and there’s a few seconds of confusion before I get back into the talk. With the transcript, I can see what I missed. I can jump straight back in, without losing my place. I’ve come to rely on the transcript, and I miss it when I’m in talks without it. (Unfortunately, live captioning is only in one of the three rooms running talks.)
And I’m sure I wasn’t the only person who found them helpful. I saw and heard comments from lots of other people about the value of the live captioning, and it was great for them to get a call-out in Saturday’s opening remarks. This might be pitched as an accessibility feature, but it can help everybody.
If you’re running a conference (tech or otherwise), I would strongly recommend providing this service.