BT turned on “Web protect” for me

I checked my email this morning and… surprise! 🎉 BT had decided to enable a feature I didn’t ask for, without asking for my permission. How exciting is this? (Answer: not at all exciting, it is infuriating)

Continue reading “BT turned on “Web protect” for me”

How to make your speaker line up more diverse

An organiser of the London Node User Group requested feedback on how to get more members of minorities to speak at their event. This is my contribution … which happens to possibly apply to any other event who wants to get a bit more diverse:

Hi!

Excuse me for crashing into the discussion, but as someone who’s a “minority” and has also been invited to many conferences on the basis of “being a minority”, I feel like I know a bit or two about this 🙂

(Disclaimer: I’ve been a couple times to LNUG so it’s not a total kool-aid-man convo-crash, ok?)

If you want to get people from minorities to speak on your event, you’ll have to do outreach. It’s as simple as that. Putting an ad that says “hey, minorities welcome” on your site is nice to start with, but having the most previous speakers being white guys will send a message of “oh, yeah, we have a problem, but we’d like you, member of a minority, to fix this for us”. So yes, you need to be encouraging, but you also need to do the hard work.

What this means is that you’re going to have to cultivate your networks and include more members of minorities on them so your network grows. You’re going to put a lot of energy on this. You’re also going to be amazed when this works. And surprised and confused when people tell you to f*ck off—specially if you just approach them because they’re a minority.

Why? Because you really need to learn about them, not take the laziest approach. What are they doing in their professional life? Why should they be speakers? What is it they work on that could provide a unique insight to the meetup? And no, the answer is not that they are a member of a minority.

This is going to take an awful amount of time. But it’s the right thing to do. So—kudos to you for realising you have a problem! Well done! 🙌

And now you need to start the work. Thankfully, the Internet exists and it can help you grow your network and educate yourself:

  • If you don’t know members of minorities, look at the websites of existing conferences or meetups. Look for minorities. See if any of them are in your area. Maybe they are going to speak at a local meetup? Then attend it. Watch their talk. If not, watch their talks online. See if they would be a good match for your meetup. If so, make a note.
  • While you’re on that, also follow them on their blog/twitter/facebook/wherever it is they put their online presence. See what they talk about when they’re not giving a talk. See who they talk to. Minorities tend to talk to minorities (although in their context, they might be the majorities). Learn. Don’t interrupt. Listen an awful lot. Learn more. Maybe the thing they talked about in a meetup isn’t even remotely as interesting as the other things they talk about normally with their friends. You’ll find lots of things you don’t understand if you are not friends with minorities already, so use your favourite search engine to find info about things that puzzle you. Don’t ask minorities to educate you. Do your homework.
  • If you don’t know where to start, there are people on twitter compiling lists like “women in tech”, “poc in tech”, “lgbt in tech”, and so on. Follow a list and also maybe thank the creator because they’ve done an amazing lot of work for you already.
  • Once you know what these new interesting people do, it’s the time to invite them!
  • When you invite people don’t tell them things like the following because you’ll look so freakingly lazy that it’ll be a miracle you get an answer:
    • “hi you’re an awesome female/POC/minority developer can you give a talk at our meetup?”
    • “hi I saw you do node, can you talk about it in our meetup?”
    • etc
  • Instead, tell them what you saw they talked/wrote about and why you’re interested in hearing about it in your meetup. E.g.:
    • “hi, I saw your talk on doing art with node.js and I thought this could be a really interesting topic for our local node.js meetup”
    • “hi, we’ve been running a series of talks on modular frameworks and I thought your talk about frameworks could be a good conclusion to wrap the series”
    • etc…
  • Don’t be fixated on the topic. Make it clear that this is a suggestion, not a requirement. Sometimes people have ideas for a new talk and would love to try them out in a local meetup before submitting to a conference. Tell them you’d be open about this, it makes things more interesting and welcoming!
  • If they say no, don’t be offended. Members of minorities are also at a disadvantage when it comes to things such as free time, so attending a meetup to talk for free is a precious extravaganza few can afford. Some people can barely afford tube tickets!
  • Also, don’t ask them to get you in touch with more people of minorities, because they have better things to do than your own outreach work. If they do offer to do that spontaneously, thank them! Because that is a very nice and expensive gesture on their part.

The above is about people who already have spoken or have put their thoughts online and maybe have got the attention somehow. But you might also want to use your meetup to discover and catapult (not literally!) new speakers. One way to do this is to talk to people of minorities in the meetup, and get to know what they do. Oftentimes you’ll realise that you have amazingly skilled attendees, but you never paid attention to them because your biases were blinding you. That woman sitting quietly in a corner? Not a recruiter–actually the head of development at an agency doing amazing 3D stuff on the browser. The POC nodding as the speaker’s laptop crashes? Lead developer at a company that specialises in aggregating crash data. And so on.

Speaking to people of minorities at meetups without appearing like a total weirdo is quite hard, it turns out. But you could start by bias-checking yourself, and doing simple things such as welcoming visitors if it’s the first time they join you, introducing yourself, asking them “what do you do?” instead of starting with a bias-loaded question like “so, are you a designer?”. And then make a mental note of that, don’t force the conversation too much, and try to remember next time you see them. And build a network gradually. You don’t want to freak people by interrogating them the first time you meet them, or they’ll never go back.

The more varied and diverse your meetup is, the more attractive it will be for people from minorities.

Jed also wrote a very interesting guide about how they have grown their meetup to be welcoming and inclusive: https://github.com/jed/building-brooklynjs

Phew! This is a lot of text already and I have barely started. I hope it gives you some ideas. Also hope to be able to join the meetups some time this year! I’ll be observing to see if you’re putting this in practice 😉

The cycling experiment: using a TFL bike after years of Brompton

Brompton TFL
Weight ~9 kg ~23 kg
Gears 3 3
Brakes 2 (front and back), pads, immediate action 2 (front and back), drum brakes, not quite immediate
Feels agile, responsive sluggish, leisurely

I normally cycle to the office, but yesterday I had to go somewhere before the office, and that place wouldn’t let me store my foldable bike. So I took the tube. On the way back, determined to not to take the tube and also not to walk because I know I can reduce the time to less than half, I used a TFL bike (also known as “Boris” or “Ken” or “Barclays” or “Santander” bike, depending on who’s perceived as responsible for introducing or sponsoring them).

This was very intentional, so I had brought my helmet and gloves. I was determined to do the same ride home as usual, only using a different bike.

I hadn’t used one of these since 2014, so I didn’t remember where things were, or how heavy and big they are compared to my Brompton. It did feel as if I was wearing somebody’s jacket and I didn’t know where the zipper was, or whether it was not a zipper but concealed buttons.

The other noticeable aspect is how useless the gears are. The first one, marked “start”, is literally useful for a few centimeters only. After you’ve reached a minimum speed, you find yourself frantically pedaling and trying to engage the next gear. Unfortunately it seems I got a slightly defective bike, so the next gear would either not engage or jump directly to gear 3, the longest. Which still felt super short. I’d say it felt like 2.25 and 3 (compared to the 2 and 3 gears on the Brompton).

Apparently this is by design: the bikes are designed to go 22% slower than a “normal” bike of that style and with normal gears would go. This made me feel really stupid going up a bridge, as it is slightly uphill, as most bridges are, but it was very windy yesterday. So if I went to gear 3 it was really hard to pedal, gear 2 would not engage, and gear 1 was evocative of public humiliation as I’d be pedaling like a hamster and barely moving at all–pedestrians were just slightly slower than me.

The gear mechanism is also slightly different from the Brompton’s too, so at the beginning I was expecting the gear to change, but it wouldn’t engage until I had pedaled a bit, whereas the Brompton’s is near instant. Cue some more hamster pedaling!

The brakes also felt quite used. I wasn’t really sure if I was braking at points, as I didn’t feel the very effective “ooomph” and subsequent slow down you get when you brake hard on a “normal bike”, but I was going so slow anyway that I’m sure I could bring myself to a halt by a combination of not pedaling and putting my heel on the floor 😜

Good aspects were that since the wheels are way bigger than my Brompton’s, the potholes, manholes, bumps, holes and any other anomaly in the roads (of which there are many) were less noticeable. I also liked the more upright position, and the fact that the pedals are further away from the road compared with the Brompton’s: I often need to be careful when going near pavements to make sure the pedal is on the higher point on that side, otherwise it’s highly likely to be scratched.

The other good aspect is that other drivers would just see me cycling on this bike, and just assumed I’d be slow as a turtle, and leave me alone on my side of the road. It did feel true that drivers were more careful around me driving a TFL bike 🐢

On telling this story to my partner, I’ve been suggested I get a pin that proclaims:

My other bike is a Brompton

so I can proudly wear it next time I use a TFL bike, and assure everyone I am normally NOT this slow. Maybe I just got the slowest bike in the system! It didn’t even have the laser lights.

We’ll see next time…

How to get a new bike (without actually buying a new one)

For the impatient:

  • Rub the dirt off the wheels with paper towels (or some rag you don’t mind throwing away, because it’ll get very dirty)
  • Grease the chain thoroughly to dissolve the soot adhered to it
  • Very gently rub the dirt off the chain
  • Grease the chain again
  • Wash your hands (many times) with warm water and gentle soap, perhaps a brush
  • Possibly moisturise your hands

Continue reading “How to get a new bike (without actually buying a new one)”

Fixing a “git mess” with cherry pick (from the command line)

Yesterday we were remotely pair programming (by me sharing my screen and my colleague Alex looking at it), and at some point I had to send a PR with a test change to validate the process would trigger the automation he had set up… but turns out he had changed something on the repo after I had forked and cloned it, and so I had a conflict!

I somehow resolved it (note to self: talking while resolving conflicts is not a good idea) but when I then pushed my branch to GitHub and created the pull request, it would not run automation because of that conflict (even if I had ‘resolved’ it).

I did not want to clone again and apply the changes… and neither wanted Alex! He said that everything is fixable with Git, so he showed me how to get myself out of this situation.

First we add the upstream remote to our repository, so we can check it out:

git remote add upstream https://github.com/user/repo.git

We fetch the data from the upstream repo:

git fetch upstream

Run a git log to find the hash of the commit we do want to keep (the Good Commit):

git log

Say it produces something like this:

commit 0BAD0BAD0BAD0BAD0BAD0BAD0BAD0BAD0BAD0BAD
Author: sole
Date:   Thu Mar 2 16:02:03 2017 +0000

    AAAAARGHHHH

commit 1337133713371337133713371337133713371337
Author: sole
Date:   Thu Mar 2 15:55:26 2017 +0000

    testing at the request of @ochameau

commit 0b225a66cf3ad67b3c67360d0e7c1e329ca3ce34
Author: Alexandre Poirot
Date:   Tue Feb 28 11:57:23 2017 +0100

    Upload screenshot and status

We don’t want the last commit (0BAD0BAD), we want the previous one (13371337). So make a note of that hash somewhere.

Now we check out their master branch (which we want to use as the base for our modification):

git checkout upstream/master

And we tell git to apply our changes from The Good Commit, using the hash we found before:

git cherry-pick 1337133713371337133713371337133713371337

Since I didn’t even change the same file he changed in his other commit, this applied neatly. No conflicts!

The problem is that my local repository is now different from the GitHub copy, because I had pushed a version which had an additional commit to resolve ‘the conflict’ (I tell you, this was quite messy!)

The solution is to force push to my GitHub repository (gasp!):

git push origin HEAD:master -f

And you don’t need to update the PR that had “conflicts”–GitHub already picks that you updated the repository, and since there are no conflicts anymore, the integration stuff works 🙂