Why I won’t talk about being a woman in tech (and neither should you)

I won’t do talks on “being a female in tech” for a number of reasons.

First, because they prevent me from doing talks on tech, which is what I would actually like to do, because that’s what I am best at. If someone approaches me to talk somewhere just because I’m a woman, they haven’t done their job of finding what my expertise is. Therefore, I am going to insta-decline.

It not only is very insulting and distracting, but also pigeonholes you into “talking about being a woman in tech”, instead of “woman who knows her tech”. It feels like, once again, we’re delegating on women and other vulnerable collectives the “caring for others” matters, in addition to their normal job. That is not OK.

Second, it devaluates the job of diversity and gender studies professionals, as it is implied that just by virtue of me being a women, I not only can talk for all other women, but also know how to fix things for all other women (note: I don’t).

That, in turn makes me the “token woman”, where everyone assumes that I represent all other technical women. This is a handicap on my abilities to actually do my job and be an excellent technical person, as it puts an additional pressure on me to be “perfect or go home” (ref: tokenism).

And it also makes me lose precious opportunities to be a good role model for other women. If they see that women in tech are relegated to “speaking about being a female in tech” instead of building and talking about solid technical stuff, they’re going to be discouraged and uninspired. Why try hard at tech if people are just interested in you because of your physiognomy? It is, once again, focusing on women physically, instead of highlighting their work and personal achievements.

Finally, I really dislike that it so often feels like either…

  • a really lazy attempt to solve the lack of diversity in conferences by organisers that didn’t do their work, but also do not want an internet storm rightly complaining about their all male line-up
  • or a feeble attempt at having a “trendy” topic in your conference, because “diversity is the hot new thing everyone is talking about”

No! The answer to an all male line-up is not a talk on women on tech by a woman. The answer is diverse people in the line-up, talking about tech. And if they want someone to cover that “trendy topic”, they should reach out to qualified people. They need to do their homework, instead of reaching out to the first “tech woman speaker” they can think of, and asking her to do a talk on something she’s not qualified on (which again, puts her in a vulnerable position).

This doesn’t mean that I do not care about other women in tech. Of course I care! I dream of the day we stop having these conversations because “being in tech” has become the normal default, but in the meantime I will contribute to pave the road to equality by talking about tech, inspiring other women and normalising the presence of women in these environments. Which is tiring enough, with all the sexism already present in our industry/society.

Volumio: a Raspberry Pi jukebox

Volumio playing aerodynamisk neger

Last Sunday, I spent some time tinkering with my Raspberry Pi 3, trying to get some sort of jukebox software up and running.

I finally settled on something called Volumio. It is a complete distribution that you install on the Pi and then it becomes a machine that plays many audio formats and that you can control from other devices, using a web interface.

And thanks to the Raspberry Pi 3’s WiFi, I just need to connect the audio jack and the power cable, and then the little machine can hide under the table with the rest of cables and other devices I don’t want to look at generally (NAS, modem, etc).

Volumio is installed by flashing a complete distribution onto a mini SD card. I had a small 4GB one roaming around so I used that. It’s cool because I can just swap SD cards and boom! I have a completely new environment without destroying the previous one.

The “official stable” builds that you’re directed to from their website won’t work with the Pi 3. They get stuck at the colourful loading pattern. I found someone had had the same problem, and the solution was to flash another image for Volumio 2 RC2. I flashed this new version, which is very hard to locate unless you know that such a thing exists or read the forum, and the initial boot didn’t show up the device on Bonjour, but after a reboot I could see it and start using it.

I configured it using the web interface, accessible at volumio.local. I told it to use WiFi (it worked!) and also to use my NAS music library (which also worked!). Then I shut it down again, moved everything out of my desk, and turned it on again to enjoy some music.

Apparently the initial Volumio front-end was built with PHP. Now they are rebuilding everything from scratch as Volumio 2, using Node.js, Socket.IO and Angular. I was excited about the node.js bit! But although there’s plenty of documentation around, I felt like I couldn’t understand where things were in the source, in the distribution, how to get a developer environment running, etc. Maybe it’s because I came back from holidays on Saturday and I’m still pretty jetlagged and my brain is not very functional yet, but maybe it’s also for the best: I surely don’t need to contribute to yet another project.

Anyway, I have a working jukebox. It can even play modules! It’s a bit basic at points (e.g. you cannot navigate by ‘genre’ or other MP3 metatags) but it is getting the job done so I’m happy.

Polyglot tracker module data decrunching, processing and crunching

I was sorting out a bunch of old digital files and folders and was quite amused at the realisation that it seems like I have written some sort of tracker module converter or reader in pretty much every programming language I’ve ever used.

NOTE: a tracker is a music creation program, and a module is how their files are called—they’re tightly optimised compressed binary files and use all sorts of tricks to save data.

Other people write To-Do apps to learn new languages, and I guess I write tracker module conversion tools? 🙃

So, in order of creation, as far as I can remember:

2005: C++: IT to events (in XML)

I wrote a utility in C++ to pre-process and parse pattern data from Impulse Tracker’s IT files, which would then be output as an XML file with event data, and then the C++ executable would use tinyxml to load the file. I am not entirely sure of why I didn’t just incorporate this event processing and reading directly into the executable instead of doing that at build time—I think I either didn’t have enough time to finish the exporter and I ended up generating the important events with Audacity or something like that, or my parser was very slow and I didn’t want the demo to take ages to load.

I can’t find this code, but I remember it was very buggy and I wasn’t progressing very fast. I wrote about it back then! There was a lot of confusion and non-written knowledge around the tracking format that I finally understood asking other people for help (e.g. how to calculate how much time do each row and each ‘tick’ take). Also, lots of segmentation faults and time spent thinking about memory and string allocations! And I was using the wrong tool for the job.

GitHub and Google Code didn’t even exist back then and SourceForge was terrible, so this is probably collecting digital dust in some folder.

2007: Ruby: XM to events

Apparently I also wrote a Fast Tracker’s XM to timed event utility in Ruby because I was going to work with a musician that used XM (hi JosSs!) and I was so into Ruby as server side and general utility language back then—the demo was going to be built in Flash with probably ActionScript 2.

I actually didn’t finish the demo, therefore the exporter is quite incomplete and I haven’t bothered publishing it, but it was interesting to use Ruby to process binary data from a file in a sort of stream like way.

In absence of a demo, here’s my favourite song from JosSs:

2008: PHP: IT to events (in a .h file)

Another iteration of this event list idea was to parse the data with PHP and generate a song.h file containing a big data array to be used in 64k intros, like this one.

I can’t find the code, but if I remember correctly, the nicest aspect of building this was that I could use some sort of text template to generate the .h file, and since string manipulations are way easier with PHP than with C, I got to the point where I wanted to be really quickly and without tons of segfaults.

2009: PHP: XRNS to MOD

I found another twist on my data conversion efforts: xrns2mod takes a Renoise song and converts it into an Amiga MOD file.

This is not a trivial conversion, as Renoise files are XML based and the player is significantly evolved compared to the MOD format: it can have a lot of channels, and more than one track per channel, plus arbitrary length patterns, plus a lot of instruments, and more than one sample per instrument, etc, whereas the most basic MOD files only have 4 tracks, use a limited note range, different base frequencies, less sample effects, and lesser quality samples, etc. So it’s not just moving numbers from one place to another.

I think I wanted to enter some MOD contest but I found all the MOD trackers quite uncomfortable compared to Renoise, and I wanted to have the best of both worlds: ease of use and also entering the contest. It’s incomplete and quite hardcoded in places, but it was already converting files quite decently the last time I ran it, so I put it on GitHub, just in case it maybe helps someone. Maybe.

Of course, minutes after I published it I found XRNS2XMOD, a similar tool which seems more complete as it also exports to XM in addition of MOD, but it requires Mono and what not.

~2010: Python + Lua: XRNS to events (in a .lua file)

I wrote an exporter in Python for generating a list of timed XRNS events and use them in a demo for ~~incredible synchronisation~~. The demo was run with Luisita which was my programmable graphics environment built with Lua and C++, and since the exporter generated a .lua file, it was very easy to load it all into an array like object at runtime.

This was used in this demo — as you can see the visuals are tightly related to the music:

I later tried to port this demo to WebGL, but I never finished it… perhaps I should just share the code for whoever was interested. It was a bit challenging to migrate because I was using OpenGL immediate mode in the Luisita version, so I needed to change my mental paradigms to WebGL/three.js’s and also write a shader or two to make it look as I wanted it to look… also those were a ton of events that I wanted to send to JavaScript, so my naive initial attempts were making the Garbage Collector work a lot more than it should have worked.

Funnily enough I remember being frustrated with not having tweening in the Lua version, but it could be ‘easy’ to add it to the web version using tween.js. But it’s not going to happen.

2013: node.js: XRNS to JSON

I also wrote a node.js module for extracting XRNS data into something the browser could use more easily (i.e. JSON). I guess not many people are using it or are interested in it, because 3 years later I haven’t heard of anyone improving or using it, but if you want you can install it with npm:

npm install renoise

I used this to generate the events and note data for the slides for my JSConf.EU 2013 talk in which I programmed virtual instruments to play a tracked song in the browser, built their interfaces with Web Components and also used hardware controlled/read with Open Sound Control and node.js! Yay to mixing everything together! 😎

Here’s the video starting with the actual demo:

Well, I hope you have enjoyed this tour, and remember to always use the best tool for the job 😉

 

Post #mozlondon

Writing this from the comfort of my flat, in London, just as many people are tweeting about their upcoming flight from “#mozlondon”—such a blissful post-all Hands travel experience for once!

Note: #mozlondon was a Mozilla all hands which was held in London last week. And since everything is quite social networked nowadays, the “#mozlondon” tag was chosen. Previous incarnations: mozlando (for Orlando), mozwww (for Vancouver’s “Whistler Work Week” which made for a very nice mountainous jagged tag), and mozlandia (because it was held in Portland, and well, Portlandia. Obviously!)

I always left previous all hands feeling very tired and unwell in various degrees. There’s so much going on, in different places, and there’s almost no time to let things sink in your brain (let alone in your stomach as you quickly brisk from location to location). The structure of previous editions also didn’t really lend itself very well to collaboration between teams—too many, too long plenaries, very little time to grab other people’s already exhausted attention.

This time, the plenaries were shortened and reduced in number. No long and windy “inspirational” keynotes, and way more room for arranging our own meetings with other teams, and for arranging open sessions to talk about your work to anyone interested. More BarCamp style than big and flashy, plus optional elective training sessions in which we could learn new skills, related or not to our area of expertise.

I’m glad to say that this new format has worked so much better for me. I actually was quite surprised that it was going really well for me half-way during the week, and being the cynic that I sometimes am, was expecting a terrible blow to be delivered before the end of the event. But… no.

We have got better at meetings. Our team meeting wasn’t a bunch of people interrupting each other. That was a marvel! I loved that we got things done and agreements and disagreements settled in a civilised manner. The recipe for this successful meeting: have an agenda, a set time, and a moderator, and demand one or more “conclusions” or “action items” after the meeting (otherwise why did you meet?), and make everyone aware that time is precious and running out, to avoid derailments.

We also met with the Servo team. With almost literally all of them. This was quite funny: we had set up a meeting with two or three of them, and other members of the team saw it in somebody else’s calendar and figured a meeting to discuss Servo+DevRel sounded interesting, so they all came, out of their own volition! It was quite unexpected, but welcome, and that way we could meet everyone and put faces to IRC nicknames in just one hour. Needless to say, it’s a great caring team and I’m really pleased that we’re going to work together during the upcoming months.

I also enjoyed the elective training sessions.

I went to two training sessions on Rust; it reminded me how much fun “systems programming” can be, and made me excited about the idea of safe parallelism (among other cool stuff). I also re-realised how hard programming and teaching programming can be as I confronted my total inexperience in Rust and increasing frustration at the amount of new concepts thrown at me in such a short interval—every expert on any field should regularly try learning something new every now and then to bring some ‘humility’ back and replenish the empathy stores.

The people sessions were quite long and extenuating and had a ton of content in 3 hours each, and after them I was just an empty hungry shell. But a shell that had learned good stuff!

One was about having difficult conversations, navigating conflict, etc. I quickly saw how many of my ways had been wrong in the past (e.g. replying to a hurt person with self-defense instead of trying to find why they were hurt). Hopefully I can avoid falling in the same traps in the future! This is essential for so many aspects in life, not only open source or software development; I don’t know why this is not taught to everyone by default.

The second session was about doing good interviews. In this respect, I was a bit relieved to see that my way of interviewing was quite close to the recommendations, but it was good to learn additional techniques, like the STAR interview technique. Which surfaces an irony: even “non-technical” skills have a technique to them.

A note to self (that I’m also sharing with you): always make an effort to find good adjectives that aren’t a negation, but a description. E.g. in this context “people sessions” or “interpersonal skills sessions” work so much better and are more descriptive and specific than “non-technical” while also not disrespecting those skills because they’re “just not technical”.

A thing I really liked from these two sessions is that I had the chance to meet people from areas I would not have ever met otherwise, as they work on something totally different from what I work on.

The session on becoming a more senior engineer was full of good inspiration and advice. Some of the ideas I liked the most:

  • as soon as you get into a new position, start thinking of who should replace you so you can move on to something else in the future (so you set more people in a path of success). You either find that person or make it possible for others to become that person…
  • helping people be successful as a better indicator of your progress to seniority than being very good at coding
  • being a good generalist is as good as being a good specialist—different people work differently and add different sets of skills to an organisation
  • but being a good specialist is “only good” if your special skill is something the organisation needs
  • changing projects and working on different areas as an antidote to burn out
  • don’t be afraid to occasionally jump into something even if you’re not sure you can do it; it will probably grow you!
  • canned projects are not your personal failure, it’s simply a signal to move on and make something new and great again, using what you learned. Most of the people on the panel had had projects canned, and survived, and got better
  • if a project gets cancelled there’s a very high chance that you are not going to be “fired”, as there are always tons of problems to be fixed. Maybe you were trying to fix the wrong problem. Maybe it wasn’t even a problem!
  • as you get more senior you speak less to machines and more to people: you develop less, and help more people develop
  • you also get less strict about things that used to worry you a lot and turn out to be… not so important! you also delegate more and freak out less. Tolerance.
  • I was also happy to hear a very clear “NO” to programming during every single moment of your spare time to prove you’re a good developer, as that only leads to burn out and being a mediocre engineer.

Deliberate strategies

I designed this week with the full intent of making the most of it while still keeping healthy. These are my strategies for future reference:

  • A week before: I spent time going through the schedule and choosing the sessions I wanted to attend.
  • I left plenty of space between meetings in order to have some “buffer” time to process information and walk between venues (the time pedestrians spend in traffic lights is significantly higher than you would expect). Even then, I had to rush between venues more than once!
  • I would not go to events outside of my timetable – no late minute stressing over going to an unexpected session!
  • If a day was going to be super busy on the afternoon, I took it easier on the morning
  • Drank lots of water. I kept track of how much, although I never met my target, but I felt much better the days I drank more water.
  • Avoided the terrible coffee at the venues, and also caffeine as much as possible. Also avoided the very-nice-looking desserts, and snacks in general, and didn’t eat a lot because why, if we are just essentially sitting down all day?
  • Allowed myself a good coffee a day–going to the nice coffee places I compiled, which made for a nice walk
  • Brought layers of clothes (for the venues were either scorching hot and humid or plainly freezing) and comfy running trainers (to walk 8 km a day between venues and rooms without developing sore feet)
  • Saying no to big dinners. Actively seeking out smaller gatherings of 2-4 people so we all hear each other and also have more personal conversations.
  • Saying no to dinner with people when I wasn’t feeling great.

The last points were super essential to being socially functional: by having enough time to ‘recharge’, I felt energised to talk to random people I encountered in the “Hallway track”, and had a number of fruitful conversations over lunch, drinks or dinner which would otherwise not have happened because I would have felt aloof.

I’m now tired anyway, because there is no way to not get tired after so many interactions and information absorbing, but I am not feeling sick and depressed! Instead I’m just thinking about what I learnt during the last week, so I will call this all hands a success! 🎉

The P-word

Remember “progressive house”? As in, the music genre? It emerged sometime during the 90s and increasingly became synonymous with “repetitive songs that last 8 or more minutes with a 6 minutes build up to a 30 seconds chorus which repeats for the rest of the song”.

Or, as quoted from Dave Seaman on the Progressive House Wikipedia entry: “it had gone the same way as progressive rock before it. Pompous, po-faced and full of its own self importance. But basically was really quite boring”

Also, to fully appreciate progressive house, you needed a decent sound system or the drumbeat got lost, muddled with the rest of subtones, and the echoes and reverbs were conflated with the main lead in what resulted an awful amalgamation of things fighting for protagonism. A very confusing cacophony.

While I liked the spectacular pads and the synths, I was more into happy melodic pop songs. They would maybe build up in 15 seconds, and go all in with a 💥BANG💥 of harmonies and fun. Almost instadelivering feel-good moods and all sorts of positive vibes. You could listen to pop songs literally almost anywhere, from crappy earphones to headphones to fancy Bang and Olufsen set ups (although if you have a B&O system are you allowed to have fun with it or just use it for austere minimalist making-a-statement decoration?). It always sounded good, and in various degrees of better or worse, depending on your particular setup.

This might be the most awkward introduction ever to the subject I wanted to cover, but the three things start with a P, and I kind of like the letter P because it’s how my one of my last names starts with too. But I’m digressing. Sole, what is the third thing?

The third thing is…

(DRAMATIC… PAUSE… FOR… SUSPENSE)

Progressive Web Apps. Or PWAs as they’re sometimes affectionately called.

Don’t tell me you didn’t see it coming. It would pamper too much to my non-existent thriller writing skills that I tricked you into reading this far and you didn’t already guess who was behind the curtain holding a deadly weapon, so to speak. And I’d get into writing thrillers and that would be really awkward.

ANYWAY… articles about PWAs them are multiplying lately. It’s like late Spring finally happened and the seeds are finally sprouting. Cool. 🌱 I like plants a lot (see, another thing that starts with P). There’s a new article, or more, every week: Ada‘s, Alex‘s, Andrew‘s.

Now, my name doesn’t start with an A, but I wanted to write something about this whole new “world” because all I have to say won’t fit in a couple of snarky tweets, and fitting my sophisticated thoughts in a “tweetstorm” won’t make it easy to reference let alone read, but too easy to take things out of context. And I have a few things to say.

So – this is my personal opinion. It has nothing to do with my employer:
Continue reading The P-word