Half-Elf on Tech

Thoughts From a Professional Lesbian

Category: How It Is

Making philosophy about the why behind technical things.

  • 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.

  • Apple Watch Faces

    Apple Watch Faces

    I’ve had my Apple Watch for getting near a year now.

    Time flies I guess.

    I started out using the basic Utility face, with the round clock and simple notifications along the edges. The more I used it, the more I realized I needed different faces for different days. That’s something the Watch lets me do with surprising ease.

    The Workday

    Modular face with schedule first

    What I need to know the most is ‘what do I have scheduled next?’ Meetings of course, but I also put appointments and I schedule ‘to do’ slots in there. I need a half day to fix some code? I’ll do block that out.

    The complications are the date in the upper left, the calendar in the center, and the bottom row are the weather, my activity, and MacID. The last one is a premium app which lets me lock and unlock my laptop from my watch. Since I leave my laptop open on my desk all the time, I find this helpful for security. Pop off the bathroom, lock the laptop. Come back, tap the watch, unlock.

    If you don’t have a watch, they have an iOS app that works too. In fact, the Watch uses the phone app.

    The Weekend

    Classic round watch with few complications

    I like an analog watch face. It’s my default. This one shows me the time and date with the day, the corners are battery and activity. The bottom is weather in detail. If I tap on the date, I go to my calendar, but most weekends I don’t need to worry about it.

    The Traveller

    Modular Face with weather first

    When I travel, I don’t actually need my calendar so much. It’s weird, but since I mostly go to WordCamps or similar conventions, I don’t tend to schedule things past ‘event – 8am to 5pm’ followed by ‘After Party – 6pm to 9pm’ and so on.

    That means what I need for my watch is the weather (I’m often in places for the first time). The bottom row is the time at home (so I don’t call my wife at one in the morning), activity, and my flight status. I almost always fly American these days, so I put that complication in.

    The Apps

    I mentioned MacID already. It’s $3.99 and worth it. I also use Wunderground for my weather, since it has the right kind of alerts. I can see the clouds and the rain and that’s all I want. I use the free version. American Airlines has a free app, and it’s surprisingly good about alerts for gate changes and rescheduled flights. I’m constantly getting updates before gate agents. I also use TripCase since I can track my hotel and event information in it. The bonus there is my wife can check and know where I’m supposed to be, in case she needs to get a hold of me.

    What Else

    I actually have other faces I use. I have a photo I took in Japan that I like to use with the time, and nothing more, when I have a non-stress, non-fuss day. I have a red-text time only face for when I’m in theaters (red light is less ‘glaring’ than others if I should happen to check the time). But the three I listed above are my regular watch faces. All on one watch.

  • 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.

  • The Trouble With Libraries

    The Trouble With Libraries

    I’ve had the same argument over and over, to the point that people follow me here and complain that I suck. You’re welcome. I’m going to spell out the issues, as I personally see them with frameworks as plugins. If you want to talk about this in so far as it applies to the WordPress plugin repository, please read this post and keep the discussion there.

    The Problems

    Problem 1 – Users have no idea what the ‘library’ plugin is for.

    Most users understand “I have an add-on for WooCommerce, I probably need Woo.” They do not always understand “I have plugin Slider Joe. Why do I need Advanced Custom Fields?”

    Problem 2 – We don’t have true ‘dependancies’ in WordPress

    I think everyone can accept that’s a problem. We literally do not have a perfect way to require things. Look at Themes. If you try to delete a parent theme, you get warned there are children around. We don’t have that for plugins. We probably should.

    Problem 3 – Users are responsible for something they don’t understand.

    By having a library as a plugin, the onus of version compatibility and updates is now on the person least likely to understand it when it breaks: the user. They have to update the library, and your plugins, every time there’s a new version.

    Problem 4 – Frameworks and libraries can no longer break backwards compatibility.

    This is hugely restrictive, by the way. With a framework-as-plugin you can’t break things because you (the framework developer) are responsible for all the plugins that use your framework. If you break how things work from V1 to V2, and one of the myriad plugins a user has doesn’t work on V2, and the user updates your framework, you broke things. True, this was always the case, but at least the plugin contained the library and could use it’s own version.

    Problem 5 – Plugins will still break.

    I have to say ‘still’ because we have one version of the problem today, and we’ll have another tomorrow. Right now, if four plugins include the same library, and they’re all different versions, we don’t have a clear and perfect way to know which version of the library the user will get. Tomorrow, if a framework is a separate plugin, there’s absolutely no assurance than every plugin that requires that library has been tested with the version the user has install.

    The Options

    Today we really have two.

    Option 1 – Frameworks are plugins and users have to install them.

    This means all new plugins that include said framework have to remove it and change it to a require. All existing plugins should be contacted and told to change their code. Some users will complain about installing ‘extra’ plugins and some developers will lose users (it’s already happened).

    All developers have to put in this requirement themselves, possibly using a library like TGM (until we have dependancies). Also all developers have to ensure they, now and forever, keep up with the frameworks and ensure compatibility as well as proper alerts if a user removes the framework by accident. Their code has to break elegantly if the user doesn’t upgrade the library. Your plugin takes advantage of the latest feature in a framework? Awesome. Make sure your plugin checks “If this feature exists, use it” and fails gracefully if not.

    Option 2 – Frameworks that are not ‘functional’ frameworks, but really libraries are treated as all libraries are with all projects, and included separately.

    Developers have to code the calls to the library, making sure that the ‘right’ version is included no matter what someone else includes. Developers also have to update their plugins when a library updates. though if they properly handle the code calls, they don’t HAVE to. They could use namespaces and cleverly call use MYPLUGINAWSSDK as /aws/AWS/foo/bar instead, so their version is what’s used. They’ll probably want to code in a failsafe “If a version higher than mine is used, show a warning.”

    The Solution

    Looking at the options we have today, we have to ask “Which is better?”

    Neither. They both suck for developers. They both suck for the users. They both frustrate everyone. I have heard arguments from the same number of developers for each option. Some developers want to include the ‘core’ or a framework in their plugin because it’s ‘better’ than requiring another plugin. Other developers want the other plugin so they don’t have to be responsible to update the library.

    There is, clearly, an argument to be made in both cases. There isn’t a win here. Personally, I think once a framework or library exists as a plugin in the .org repository, you should remove it from your plugins and require it. Of course, good luck figuring out how to do that in a sane way without breaking people. The best I came up with was have a period of time where you keep the library while using TGM or something to require the other plugin. Make an alert or notice to tell users to install the requirement. Keep that for a whole major version. Then, on the next major version release, drop the library.

    With all that in mind, we have to ask this instead “Which option annoys users slightly less?”

    That’s – libraries as libraries, not plugins. The one where the users don’t have to know (or care) about it anything except “I have plugin X.”

  • The Big Picture

    The Big Picture

    Decisions, Not Options

    WordPress’s core philosophies are what has allowed it to be extendable, supportable, extensible, and surpass 25% market share.

    One of WordPress’ hallmarks is a massive plugin repository and the ability to extend WP to do pretty much anything. Instead of making the core software huge and bloated, filled with aspects the majority don’t use, WordPress decided to follow a path of ‘decisions, not options.’ With that, the onus is on the developers to deeply learn and understand the implications of any and all changes and additions to the core software. We’re encouraged to separate our personal feelings from what is best for the project and the users.

    We need to think about the big picture.

    I Fight for the Users

    I often say this when I’m in core meetings about ideas for changes that will impact users. Generally these are visual changes, like moving a menu or adding in a more obvious button. When we, as developers, make a decision, we need to have the big picture in mind. Do most users need to decide what quality of image compression to use for WordPress? No. Not because they don’t care, but because the information to explain it is overwhelming to many.

    Recently WordPress increased the default image compression (you’ll see it in WP 4.5). In the proposal, an incredible amount of research went in to figuring out what settings would be best for the majority of users.

    Will the minority, the photography site runners, be possibly upset? Yes. But when we look at the big picture (ironic, I know) we remember that most people will only notice that their sites are loading images faster.

    It’s Okay To Be A Minority

    Most of us started using WordPress and were the majority. We were the target audience and the people it aimed at. Over time, the ways we use WordPress become more and more specific, and suddenly we have at least one way where we are unique and special. We no longer ‘just blog’ on WordPress. We sell our wares, we write novels, we build communities.

    We are, suddenly, a minority in how we use WordPress. This makes it harder and harder to keep the big picture in mind. We are, as humans, inclined to see ourselves first and put our own needs first. Our websites need these things, therefor they are the most important aspect of the upcoming changes in WordPress.

    This isn’t true, of course. But we lose sight of the big picture very easily when the changes impact us, and it tends to make us concentrate on the wrong things.

    I Prioritize the Users

    I speak up for the users in developer meetings when they’re not there.

    I think of them first.

    When I make a change, when I design a change, it’s for the users first. Even when it inconveniences me, even when I feel it’s not the perfect solution for my plans, I consider that what I’m making only is what it is because of the users.

    The big picture is that users make the software what it is. Putting them first in as many things as possible makes it so that they can trust me when I make a decision. When I say “No, this would be better for you as a user but not for your safety.” I know I can say it from a place where I’ve earned the respect and trust of the users.

    You cannot get to that place of trust without putting the users first in all possible things.

    The big picture is bigger than just you, who wrote the software, and you, who used the software. The big picture is all of us.

  • Cooking as a Dev Skill

    Cooking as a Dev Skill

    My friend Dan asked if I’d be talking about cooking as a dev skill for WordCamp Minneapolis.

    While I won’t be making that camp this year (sorry folks), I thought I’d take a moment to talk about cooking as a dev skill. Or rather, what cooking teaches you about developing a website.

    Know What You Want to Cook

    You can’t just decide to throw things together until you’ve been cooking for so long, and you’re an expert at winging it. Most of the time, we pick a recipe we know, or feel we can follow, and decide what we want to make. We have to temper this with what we need to make. If I’m making dinner, I need protein and vegetables. If I’m making a pie, do I need the pie or do I just want something sweet?

    Websites are the same way. We pick the site we want to make before we start building. When you go into making your site, you have to know what you want the site to be. You also have to know what you need. I need a web presence (it’s 2016, yes you do), but I don’t need a video and an interactive game and all the bells and whistles.

    Check Your Ingredients

    Open the door to your refrigerator and make a list of what you have. Look at the recipe. Do you have what you require to make this dish? If you’re ordering out, you get the meal pre-made. When you’re making it yourself, you need to make sure you have salt and butter and tofu and eggs.

    When we talk about webpages, we talk about the code behind it. Can you design something out of nothing? Do you have the tools with which to do so? Can you write javascript and PHP and HTML? These are things you need, these are your ingredients. They’re also going to be your libraries like Backbone and React.

    Mise En Place

    In cooking, setting up everything beforehand makes the entire cooking experience better. I’m terrible at it, but I’m doing my best to get better, because once I’m prepared, everything flows and I’m less of a whirling dervish. The setup doesn’t just keep you organized, it keeps you real. It lays everything out and sometimes, when you look at 10 pats of butter, you may think about maybe cutting down a little.

    Speaking of those libraries, make sure you have only what you need. The whole Backbone repository is over 5 megs. The one file you need is 69kb. Use only what you need. The more individual pieces you need, the more you should scrutinize them. Did you really need all that in the first place? Do you really need eleven css files for options of display, or should you make a basic one and let people build what they want?

    The Cake Will Collapse

    You’re going to mess things up. You’ll burn the caramel, overcook the pasta, underboil the egg, and so on and so forth. These mistakes are okay. As Julia Child said it, “No on will ever know!”

    Do I even need to say it? Your code will fail. A lot. In weird ways. You may spend an hour wondering why WP-CLI fails, only to remember it’s WP_CLI instead.