Half-Elf on Tech

Thoughts From a Professional Lesbian

Tag: essay

  • Obviously Oblivious

    Obviously Oblivious

    So I was asked this…

    @binarygary: .‭@Ipstenu‬ I know you aren’t the patent office…but have you ever declined a plugin for “obviousness”?

    I replied, not in jest, that I had declined some for obliviousness.

    Gary’s plugin was obvious in that it did exactly what it was purported to do, and it did it well. And it had a puny name. I quite liked it and approved it pretty quickly. But the crux of the question is interesting. Have I ever rejected plugins for being too obvious?

    Not that I can remember. In fact, I kind of love the plugins that do exact what they claim to do. Like Rickroll which turns your videos into Rickroll or Logout Roulette which gives you a one in ten chance of being logged out. Those are simple and obvious and a little stupid, but they’re perfectly obvious and only the oblivious would be confused.

    An obvious plugin is possibly the best kind of plugin. My buddy Otto once remarked that well named functions don’t need documentation. If you have a function named reset_the_loop it’s pretty obvious what it does. Now you might need to add some docblox to explain how to use it and what parameters you can pass through to it, but in and of itself, it resets the loop!

    On the flip side, here’s rts_reset which is actually a function I saw recently in a plugin. Okay, what does that do? It was in a class named RTSCode which didn’t help at all. And there was no inline documentation. After a while, I traced everything back and sorted out what the heck the code was doing (it was reseting a query, but only if you passed specific params back).

    In general, a WordPress theme and plugin should be painfully obvious. It’s open source, it’s code anyone can look at, and yes, it should be stupid easy to understand what it does and why. That’s the meaning behind ‘open’ in so many ways. Open for everyone. Open to be forked and learned from and studied and made more perfect. Or at least more fun.

    I like obvious things. Obvious is good.

  • Dependency Disaster

    Dependency Disaster

    Over the last few weeks and months, the nightmare that is WordPress plugin dependency hell has waxed and waned with the ire of a thousand burning suns. It flared up when I, perhaps naively, posted a reminder of a rarely called upon guideline to not submit Frameworks for hosting on WordPress’s official plugin repository.

    This brought up the perfectly valid arguments that these repositories are useful as they allow for deployment and updates that were hitherto unavailable when rolled up into one package. And at its heart, I understand their point and agree with them as to the benefits. But since WordPress core doesn’t have true plugin dependencies at this time, it’s exceptionally complicated and a hassle to include them.

    Personally, I feel that the NPM or Composer style development of plugin is the way to go. Development. Not deployment. With few exceptions, I feel the best way to release a plugin is all in one, rolled up together. The exceptions are, of course, plugins that are add-ons to others, like a plugin that adds a new email integration hook to MailChimp, or a new payment gateway for WooCommerce.

    The rest of our plugins should be self contained, reliant on naught but ourselves. I have two plugins which contain the same AWS SDK libraries, written in a way to check if the library is already loaded and to make sure it only loads what’s needed. Why did I do that? Because then someone can have one or the other or both without conflicts.

    The user doesn’t have to care about dependancies. They are invisible. That is as it should be. Users don’t have to care.

    But there’s also a danger with dependancies, as recently came to light in the JS world. Azer Koçulu liberated his modules from NPM after the threat of a trademark based lawsuit had NPM remove one of his projects.

    Sidebar: Open Source has no right to impinge on trademark law. Period. However some lawsuits are frivolous and daft and should be contested. Sadly most communities (NPM, WordPress.org, etc) do not have the money or resources to fight that battle for a developer. If you chose to fight, please contact the EFF.

    As is his right, Azer pulled all his packages from NPM. The fall out from this package removal is that a lot of automated builds failed. This has to do with the way Composer is often bundled. Instead of a wrapped up package like an exe or a dmg, it’s a stub that reaches out and downloads all its requirements on the fly. Just like the TGM Plugin Installer. Right? And what happens when those requirements are missing? The build fails.

    Perhaps worse, by unpublishing the name slugs used can be taken over by anyone else, and used to push more nefarious code. This did not happen. NPM checked everyone and verified they were as decent as one can before handing over the old names to new owners.

    My first thought was “Could this happen to WordPress?”

    Yes and no. First up, we don’t reuse names. If you have the plugin ‘foobar’ and ask to have it closed, the name is still reserved. In extremely rare cases we’ve turned over names to trademarked owners (like how Facebook owns the facebook slug) but always with communication of both parties and always with awareness to how many users might be impacted.

    But could we pull a plugin for trademark infringement and screw up package dependancies? You bet your ass.

    We’ve been lucky that all legal parties involved in similar arguments have been accepting of the ‘grandfathered’ ruling. That’s why we still have plugins with slugs like ‘google-analytics-by-joe’ out there. But it’s also why we don’t allow any more. And yes, when a plugin with a unique name is submitted, we do take the time to check if it’s already trademarked. To spare people this drama.

    But yes. It could totally happen. And since we have to name our dependancies and rely on those slugs, there’s no easy way out.

    I suggest reading the Hacker News thread on the matter. They weigh both sides of the issue, and show you how the pros and cons make this even more complex.

  • The Pressure to Succeed as a Woman Who Codes

    The Pressure to Succeed as a Woman Who Codes

    I feel a disproportionate amount of pressure to succeed in coding.

    I call it disproportionate because it’s only about 1/3rd of my career. The other two are support/training and public speaking. And while I used to have a fear of public speaking, I’ve somehow managed to discard that and I’ve got no concerns at all about screwing up on stage. I might. My talk might flop. My training might not be understood or adopted. My support may be wrong.

    But what scares me to the point of tears is coding.

    It’s not that I’m bad at it. Intellectually I think that I’m pretty good. I’m not the greatest in the universe, but that’s a realistic stance as opposed to anything else. And I enjoy playing with it, inventing new things, seeing how they work, helping people solve problems with code. It’s honestly fun.

    Looking at the Stack Overflow Developer Survey I noticed that only 5.8% of the participants identified as female. Taken a different way, 92.8% of people had no problem saying they were men. Now, SO is aware of the disparity, and mentioned this:

    Our survey results demonstrate a dramatic disparity in tech among men and women. In fact, we know women make up a more significant proportion of the developer workforce than this suggests. According to Quantcast, about 12% of Stack Overflow’s readers are women. (We don’t actively track gender internally.)

    I have a personal theory that gamification appeals more to men than women. This stems from reading about Richard Bartle’s player types way back in the 90s. It was a big thing in MUDs and MUSHes, and the Bartle Test is essentially a series of questions that can be used to identify the classification of a player into one of four types: Killers, Achievers, Socializers, or Explorers.

    Now it helps if you’ve read a little of Hearts, Clubs, Diamonds, Spades: Players who Suit MUDs, but you can get by with the Wikipedia article. The main point is that we can classify people into player ‘types’ based on what they enjoy doing and how they like doing it.

    In general, winning and hacking are associated with Killers and Achievers, while helping and curating fall under Socializers and Explorers. And when I say it like that and you look at things like programming vs support forums (of which I do consider Stake Overflow), lines start to be drawn. These lines are carved in stone when you consider some of the research gamerDNA did into what kinds of player played what kinds of World of Warcraft characters, and what their genders were.

    What does all this have to do with the unrealistic expectations on women who code?

    If one buys in to the hype and typecasting, then one would say that women (nurturers) are more likely to be socializers and explores. Regardless of if this is accurate, there certainly is an expectation on women that they are ‘mothers’ and, from that, they are often unconsciously perceived of being a specific player type. And when someone steps out of what people feel their norm is, they’re often set upon.

    This is not solely endemic to women, of course. Men who express emotions publicly, like crying for example, are also set upon by others for not being manly enough. And that is precisely my point. People who don’t fit the stereotypes of what gender is get pushed back. People who act ‘out of character’ are looked upon as odd.

    Okay, so why do women keep feeling pressured? Because shit like this happens:

    You can look up the ‘fake geek girl’ phenomenon on your own. The fact is that it applies to anything not stereotypically female that a woman does. And it means that, in order to be taken seriously as a coder, we have to achieve great things or all we’ve done is prove we’re only good for the ‘fluff’ of support.

    Eddie Izzard makes a joke in his “Dress to Kill” routine about men who wear dresses and heels:

    You know, if a woman falls over wearing heels, that’s embarrassing, but if a bloke falls over wearing heels, then you have to kill yourself. It’s the end of your life. Its quite difficult.

    And while we laugh at it, the truth is that ‘abnormal’ behavior is treated with incredibly high expectations. Unrealistic ones. Unfair ones.

    I don’t have an answer to this, and for now women shoulder the burden of being expected to be greater than men of identical backgrounds, simply because of how we were born.

  • Project Bloat

    Project Bloat

    Can we have a serious talk about project bloat?

    During the framework kerfluffle, I remarked that I hated seeing a 10 line plugin needlessly include a framework like CMB2 because of the size of plugin it created. Someone remarked that if the library helped them write something in ten lines instead of 100, wasn’t that better?

    And the answer to this is maybe.

    My issue is not using a library when the library is the best solution. My issue is people defaulting to use a library before they think about if it is the best solution.

    And my point is really quite simple and obvious to a large number of developers. I’ve touched on it time and again. I’ve told you how I handle packaging my vendor folders. Simply put, I think that before you include anything in your project, you should evaluate it’s merits and flaws.

    Look. There are always, and will always be, good reasons to use a library. There’s never a reason to use a library thoughtlessly, and that’s what I see every day. By ‘thoughtlessly’ I meant someone who has a plugin that adds one setting, a custom meta field let’s say, into all posts. And in order to do that, they wrap ACF into their plugin.

    For one field.

    One.

    Literally one.

    Jackie Chan WTF Meme Face

    And I get it, I really do. The settings API is a bag of wet hair, and the fields API needs love (so much props to Scott Clark for his work there), and figuring out how to do things can be a comprehensive battle of trial and error vs ‘How much hair do I have left?’ And yes, I do use some of those libraries, like CMB2 and ACF, when the need calls for it. When I’m making a massive custom tool or theme and I need to do a million things. But …

    What I don’t do is use it for one field. Sure I could, but that would make my plugin very large and to no real benefit except it’s ‘easier’ for me. And even that is questionable. When I do use them, and yes I do, I do so thinking about the weight I add to my project.

    A pause here. I say this a lot, the weight of a project.

    Everyone seem to assume I only mean the size (in MB) of a project. I don’t. When I say the ‘weight’ of a project I mean the file sizes, of course. Making your 10kb plugin over 500kb just to add one field (I’m being literal here, folks) is sketchy at best. Making it over a meg is borderline ignorant. But I also mean the weight of how it impacts the speed of the site. Will having the library called make a site slower? It might. And I also mean the weight of technical debt. Am I going to update the plugin and the library every single time? This is my responsibility now, and I have to test and test and ensure I don’t break anything.

    The weight isn’t just the size, it’s the time sink. It’s everything that has to go into keeping a library included in a way that doesn’t conflict with anything else. It’s managing my time so I can test and evaluate changes. It’s making sure I push code that won’t break on new versions of my main project (i.e. WordPress). It’s making sure my changes don’t break other co-projects (like WordPress plugins and themes), by assuming they’ll always work on the newer versions. Backwards compatibility isn’t a requirement for all projects, but when it is, you bear that weight too.

    And the weight is also the fact that I’m robbing myself of a greater understanding of WordPress core. Using a library isn’t ‘cheating’ but it does mean I might be less capable of debugging a conflict, if it’s due to the library.

    That’s the real weight of a library included in your project. If you’re not considering it when you add a library, you’re doing yourself a massive disservice.

  • The Awareness of Method

    February and March were weird for me. A lot of personal drama, and none of it really mattered to the masses so I kept it to myself and my close friends. I don’t feel the need to publicly broadcast my personal pain on everyone, and I do my best to step back and let it (hopefully) not impact my reactions to everyone else.

    This was very hard because a goodly portion of my drama was from the public sector, and it boiled down to people unintentionally hurting me. And as I grumbled on Twitter, I feel like I need to explain how having hurt feelings doesn’t mean I’m over reacting. Which is preposterous.

    I understand that, for the most part, the people who hurt me certainly did not intend to attack me or sound combative. And I’m well aware that tone is a terribly difficult thing to read in the written word. That’s why good authors take the time to explain things in detail. Things like italics and bold and capital letters are important for reading into the meaning of a sentence.

    At the same time, any time a comment aimed towards me starts with a remark about how they don’t care for drama, I walk away. You should never say that. If you don’t want to talk about the drama, don’t invite the drama. It’s really that simple. And if you’re worried that how you’re saying something, it’s a sign that you should rethink what you’re saying and how you’re saying. This is where the method comes in to play.

    The intent of what you’re saying is subject to the manner in which you say it. If you ask a sincere question and people react strongly and negatively to it, then your intent was lost in the method. Communication in text-only is complicated. You can’t see people’s faces, you can’t hear their tone, and most of us don’t know each other to the degree that we can reliably read intent. Simply put, your intent is subject to how it’s read.

    For a long time, I’ve advocated people remember that when someone misinterprets what they’ve said, the fault lies in both parties. If I say something and it’s read as aggressive, this is in part my fault for not tempering my tendency to be direct with the need people have for humanity in a conversation. At the same time, no matter how nicely I say “Your plugin has been closed…” someone is rightly going to read it and be angry and interpret that I am being mean or offensive.

    It’s a no-win situation. Or at least it’s one I’ve never figured out how to win. I’ve been told the default ‘your plugin has been rejected…’ email is too angry because it uses all caps for one line, even though it apologizes and explains it’s trying to get the reader’s attention and encourage them to … well … read. That email was developed over years of communications with thousands of developers. It’s the one we determined to have the highest success rate of people actually reading and processing what was said.

    Still, at least once a day someone replies to an email asking ‘How do I resubmit my plugin?’ This invariably comes in reply to an email that says “When you’ve corrected your code, reply to this email with the updated code attached as a zip, or provide a link to the new code for us to review.” And at that point, I honestly don’t know how to make it more clear.

    When people say the email is too aggressive, I explain that we’ve cultivated them over years, but we’re always willing and welcome to make it less so. And we ask if they have suggestions? Not a single person has ever replied with advice, except the person who said “Don’t use emoticons, they’re unprofessional.”

    Seriously, you just can’t win.

    Which brings me to the point and it’s that winning isn’t the point. Losing is the point. We lose when we don’t take into consideration the reaction to what we say. We lose when we dismiss someone else’s reaction. We lose when we over-react to what we perceive as an over-reaction.

    We will never be able to always speak clearly and without accidental misunderstandings. We will never be able to ask every question in a way that makes everyone feel welcome to join a dialogue.

    We can be aware that our words have weight and meaning, especially because an increasing number of us communicate in text first (if not text only). We can try to learn from our mistakes. We can apologize sincerely for those mistakes.

    What you say can and will be taken out of context. It can and will be read the wrong way. When it happens, it hurts and it tends to make you react poorly. But being hurt by someone’s words doesn’t mean you’re over-reacting. And it would do us all good to remember to respect other people’s feelings and reactions.

    Yes. Even me.

  • On Saying No

    On Saying No

    We are, for the most part, accustomed to getting our way. We have a problem, we contact support, they fix it.

    Once in a while, however, support says ‘No.’

    I’m sorry, I can’t do that, Dave.

    There are technical limits to all products. Due to our own failures of imagination, we cannot foresee every possible iteration of usage for the things we build. These failures are, of course, not the fault of anything but our own lack of omniciense. We cannot know all things. We cannot predict all things.

    In this way, we have learned to expect limitations over time. We know that there is a line drawn in what the computer can do. If we have not programmed the computer to do a thing, it cannot know to do the thing. The reason for the limitation is just that the code’s author didn’t wish to write a thing. Why? Many reasons, none of which matter.

    We can, however, accept that systems and software are written by humans. Humans are fettered with limited vision. Computers are shackled by the humans who create them.

    When a program says it cannot do a thing, it cannot do the thing.

    I’m sorry, the system’s a bit limited.

    The problem with our shackles is that the one who has to tell a customer that the computer cannot do a thing is a person, not a computer.

    We cannot delete user accounts on WordPress.org for a number of reasons. If the site was just a blog, or a BuddyPress network, it would be a simple matter. Instead we integrated a wiki, multiple bbPress 1.x instances, a BuddyPress network, a multisite, theme SVN, plugin SVN, and core SVN.

    So no. We no longer have the technical ability to remove a user ID. Not even in the case where you accidentally used your gmail address as your username and are now ipstenugmailcom … It says username, but people do what they do. And no, we can’t rename users either. Same reason.

    We coded ourselves into a situation where we are technically limited. We cannot do the thing because we didn’t develop a way to do the thing.

    I’m sorry, but it’s against policy

    Then there’s a different kind of reason that someone tells you no. Like when someone asks for an embarrassing post or comment be deleted. Obviously this can be done. Comments and forum replies can always be deleted. That’s how they work. You may have your own site and you’ve deleted spam.

    But every site has a comment policy. They have the right to moderate their site however they want. Some delete things right away. Some moderate and manually approve all comments. Others let things run until the shit hits the fan and then spend hours and weeks and months cleaning up. However they choose to moderate and maintain their site is their business and their choice. You don’t have to stick around if you don’t like it.

    A large issue occurs when you don’t realize until after the fact that one of the policies is, perhaps, not removing posts. That’s when things get really messy, because now you’re being told no and not only is it by a human, but it’s a human who makes the choice.

    Your rights are subjective

    The rights you have on someone else’s website are subjective.

    The rights you have when you use a product are as well.

    If you download Microsoft Office, you agree to a lot of terms and conditions. Whether or not you read them, you agreed to them. Same with Apple’s iCloud terms and conditions.

    You give up some of your freedoms in exchange for their convenience. Your rights are subject to the agreements you make when you chose to use software, comment on a site, join a community, sign a contract, etc. etc.

    Be gracious in victory and defeat

    Once in a great while, someone will make an exception for you. Most of the time you really don’t want it.

    Perhaps you think it proves that all policies are mutable, but the reality is not. You see, that exception means it’s worth more to them to shut you up than it is to abide by policy.

    Of course a post can be deleted. Of course someone can lock your account for you. Of course you can be granted an extended warranty. But, for the most part, in order to get that far and get that level of ‘reward,’ you will have had to become the person no one wants to talk with.

    An example. A user asked for his account to be deleted and was informed of the technical impossibility of the request. He then asked for his posts to be removed and was informed of the policy prohibiting such a request. He finally asked for his account to be made inactive and to ban him from the site. He was told (after confirming that these requests were all to calm his paranoia and not that he was being harassed or stalked by someone) that the site was not his parents, and if he wanted to leave, the answer was to log off and walk away.

    Instead he began to post nothing but vulgarities.

    His account was locked and he was banned.

    He will likely never be welcome again.

    He might think he ‘won’ the argument, but all that happened was he showed his deplorable behavior, in public, in a way that Google captured. He tainted his reputation. He tarred and feathered himself. He burned his bridges. And he bragged about it.

    Support are people too

    When you are told ‘no,’ try to understand why. Accept the fact that you cannot get what you want all the time. Sometimes it’s just impossible. It’s understandable to be upset and angry. But the people tasks with enforcing policy or educating you to as to limitations, they are people just like you.