| You are aware that you're not being paid to "write code", right? You can't just deliver a bunch of nicely formatted for-loops and call it a day, your code actually has to do something, it's part of a product. While implementing that product, everybody involved makes myriads of tiny decisions. Even if you're not in project management or any official "decision maker" position, you likely still make tiny (or not-so-tiny) decisions that affect the experience of users of your product. If it's a web or mobile application for example, you might decide between different libraries or build tooling and that in turn could affect the download size, which affects people on slow connections. Or you could make certain assumptions about connectivity, affecting people who frequently need to work on spotty connections or high latency. Or in software in general you might pick a component or implement one in a way that makes it inaccessible or harder to use for vision or motor impaired users. And those are just generic examples that apply to most products regardless of the actual intended use cases. There's of course the obvious examples of Google image recognition categorising photos of black people as apes (which I as a white person might shrug off as an inoffensive glitch but someone with a lived history of racist slurs in the same vein might be extremely hurt by) or soap dispensers not reacting to black hands (which is genuinely silly but betrays a lack of consideration on the part of the people who built the technology). There are many, far more subtle examples. Like a woman is more likely to have experienced abusive relationships and might therefore find it more obvious how certain "inoffensive" tech might be used by an abuser. Or someone who's experienced intense trauma (like the death of a child) might not enjoy your social network's "remember this day from last year" surprise feature. Or someone who's trans might not want their identity be revealed to untrusted people automatically (or might even prefer to use different identities when interacting with e.g. their ultra-conservative parents who come from a cultural background that encourages honor killings). Or a member of a group that is frequently on the receiving end of racial profiling might have concerns about what data you are gathering that you may have to hand over to law enforcement (not because it might hurt the guilty but because it might help building a case against someone innocent the jury is likely to be already biased against). Or you might implement a payment gateway a certain group of people can't use because it requires documentation they can't provide or because it denies them service for some reason. It's not about having a black person at your all-white all-male event. It's about having a diverse group to maximise the chances of having a diverse set of experiences present. It's about empowering marginalised speakers because by definition their voices frequently remain unheard and their marginalisation means their experiences are likely going to be very different from yours. I'm a code monkey like anybody else. I see an article about a new JavaScript framework, I'm gonna click it. I see a hip new editor trending, I'm gonna check it out. But there's more to our jobs than just punching strange symbols into a machine to make stuff appear on the screen. It's about building products (or projects, at least) and those products are going to be used by people and will affect them. So the least we can do is learn how to avoid actively making their lives worse with the products we help build. |