Happy International Women's Day, everyone!

Today also marks another miracle, where I follow through on a recurring post type. Granted it's only week two, but for me that's miracle enough.

In honor of today's holiday, my first big lesson this week goes to something we should do as little of as possible, on today and any other day: mainsplaining.

Mansplaining Is Real, Make it Stop #

There's no shortage of men condescendingly and unnecessarily explaining things to women online, but it seemed especially bad this week. Below is just a sample of times I saw it happen this week.

I can imagine men who, even if they accept what mansplaining is, dismiss it as something trivial. But it happening so often is worth caring about. It's the everday things that create and reinforce the culture, and the culture helps create society's power dynamics and structure. Mansplaining is one of many occurences that reinforce gender inequality dynamics, and default assumptions that women know less then men.

If a man doesn't want to believe even that, they can at least avoid it on the rule of "not being a dick." If that doesn't work for them, how many female friends do you think they'll have?

This lesson is more about responding to men doing this, specifically ones acting confused about what mansplaining is or why it matters. A good response is pointing out that they should be able to google simple questions like this and educate themselves. Pushing the burden of making them better people on the woman isn't a kind gesture, it's trying to make the woman waste their time and energy on explanations the man usually won't accept.

It's not every woman's job to make men better, it's the man's own damn job.

Also, keep this handy chart in mind!

It may seem like I've already long learned these lessons about mansplaining, and there's no reason to write it now. But I still need to restrain myself from making these mistakes too, which means I need to keep relearning them. International Women's Day is an especially good time to do so.

Be Mindful of JavaScript Data Mutation #

Once upon a few days ago, I was writing a test with some tricky requirements. I had to take a data stub, add some extra data to it, pass it to a component, and make sure the component filtered out the extra data.

Sounds simple, right? Make an adjusted copy of some data, save the original, and make sure the component's output matches the original. These were the data variables I worked with:

const DATA_STUB = {
changes: {
user: 'maxwell',
date: '03/08/2019',
images: [
}, {

const fakeImages = [
}, {

As with all otherwise simple things, JavaScript screws things up.

My first attempt went something like this:

DATA_STUB_WITH_EXTRAS.changes.images = DATA_STUB_WITH_EXTRAS.changes.images.concat(fakeImages);

Think this works? Turns out it doesn't! JavaScript variables store a reference to the passed in value, not a separate copy. So making changes to that variable changed the original. Then it can't be tested right and the test fails! A better solution that avoids this uses spread operators!

'changes': {
'images': [ ...DATA_STUB.changes.images, ...fakeImages]

The spread operator essentially takes an array and outputs each value as if listing them as individual values. This lets you do many things, including cleanly combining two arrays like so. I recommend this article for learning more about what spread operators can do.

But the larger lesson here is me being more conscious of managing data with my JavaScript. Data mutation can sneak up and do plenty of damage, especially with data going to and from a database. A good default approach is building up new JavaScript data structure with existing data to avoid the risk of data mutation. Extra testing to make sure data doesn't make possible mutations can also help one's peace of mind.

Making Smaller PRs #

Last week one of my lessons was breaking up big changes into lots of smaller pieces and components, and now this includes smaller pull requests.

As a direct comparison to my giant pull request in the last weeks, I started this week with many smaller ones. I started a larger redesign with five small PRs, some of which only changed a few lines in one file. Overall mistakes were found faster, there were fewer rounds of feedback, each had great focus, and some got merged right away.

Of course there's a trade-off with this approach. Tracking multiple PRs can get overwhelming, no matter how small each one is. The need to rebase each branch can also be lots of work, along with keeping track of which changes are in which PR. But unless I create a truly staggering amount of small PRs, this approach is virtually always worth the trade-offs.

Equality isn't Oppression #

One more note for the men out there:

Your Tweet of Zen #

One last tweet in the spirit of #InternationalWomensDay:

See y'all next week.