Half-Elf on Tech

Thoughts From a Professional Lesbian

Category: How It Is

Making philosophy about the why behind technical things.

  • Mailbag: Why did you ask that at the Town Hall?

    Mailbag: Why did you ask that at the Town Hall?

    Last weekend, at WordCamp US, I asked a question at the town hall.

    At its heart, the question was that did Matt feel the rapid release cycle of WordPress major revisions was too fast? I asked this based on the concerns I hear voiced by plugin developers, generally the smaller shops (single person or under ten teams), who not only have to test their plugins with the new versions of WordPress, but also learn these new, rapidly evolving and changing, libraries like ReactJS and the REST API.

    Matt’s answer was essentially no, and that he felt that things would only get faster. Also he said he didn’t think plugins should be one-person shops.

    What did you think of the answer?

    I was asked variants of this by many people that night and the next day.

    I disagree with Matt somewhat.

    This isn’t a shock. I’m sure he’ll read this and nod. But he and I both know that a health disagreement can be good for an ecosystem. I understand his point, and in many ways agree with it. A team project for plugins and really any development is what makes things improve faster. Two heads are better than one.

    But at the same time, we look back on things like Yoast SEO, and to think that those can only exist while supported by a team is to forget the way that all of this, even WordPress, started.

    One person has an idea. One person shares the idea. A second person makes a suggestion.

    One person.

    Of the 45,000 plugins in the repository, the majority happened because of one person. One person had an idea and a dream and built a plugin. One person learned a thing and shared it. One. And the harder we make it for that one person to grow, the harder it will be for them to become the next Yoast, or Woo, or Jetpack.

    As of this post, we released four major releases of WordPress within 355 days. I think that speed for the sake of speed is as bad as dragging out feet and having one release a year. Yes, we have improved our stability by having more frequent releases, because we don’t rush to have an unready feature added to a release. There’s going to be another soon. And that’s a good thing.

    At the same time, it’s pushed us to release faster and faster, and that causes the bar to be set too high to new people. It causes burnt out. It causes update fatigue.

    I don’t think we should revert to ‘release when it’s ready’ again. That has as many problems (if not more) as ‘release X times per year.’ I do feel we need to consider the emotional health and the supportability of what we are releasing.

    Do it well, do it fast, do it cheap. Pick two. And know that the price is from our blood and bone.

    I think we should turn it down a notch. Just one notch. And we should stop releasing just to be sure we release a number of times a year.

  • Calypso

    Calypso

    You’ve heard about it. Calypso, the WordPress desktop editor for Macs. I’ve been using it and I’m going to give you a quick rundown on what I like and what I don’t.

    A screenshot of calpyso, used to write this post.

    Like

    First of all, it’s Open Source, which is great to look at. Anyone can poke at it and play with it. It’s also a nice GUI to use. Markdown works out of the box if you have it set up in Jetpack. That’s awesome since I’ve gotten very used to using it thanks to Jekyll.

    It’s very fast as well, which is great. Fast is good. It also saves rather quickly, even when I’m on some shitty wifi. It’s much faster than using the native WordPress editor.

    There have been some bumps in the road, but the development is open to comments and suggestions and steering. Some of the decsions made make sense from every angle except the end users. Users use things in weird ways and, once explained, development seems willing and able to adjust.

    Dislike

    There’s no spell check. This makes me very sad (I’ve been told it’s a feature request). Clicking back and forth between my sites is a little annoying, and I can’t easily hide sites (or reorder them). There aren’t tabs either, which means I can’t write on three or four posts at once. Yes, I totally do that.

    You can’t do Custom Post Types. Yet. This is a deal breaker for one of my sites. Basically I can’t manage my WordPress eCommerce store with this. You also can’t change color schemes. I somewhat wish that it would pick up my user settings and use the profile color from MP6 that I selected there. That way I’d have purple for some posts, green for others, and I’d always easily know where I was.

    On the Fence

    I don’t really like that it forces me to use Jetpack, but at the same time, the REST API isn’t in core yet, so this makes sense. Similarly, I don’t like that it’s Mac only, but I understand why. Unlike ‘traditional’ software development, the people on the WordPress.com project are primarily Mac users. Of course they went to Mac first. Since it’s open source, I’m hoping someone figures out how to Windows it up soon. Making it Unixy shouldn’t be too hard, since Mac is running Unix.

    Back to Jetpack, I would love to see this forked and decoupled from Jetpack, using the REST API instead. Not because I hate Jetpack (quite the opposite) but because I’d like to set my father up with this, and he travels to China where WordPress.com (and Jetpack) are problematic thanks to the Great Firewall.

    All in All, I Like It

    So far, so good. I like Calpyso and it’s no great effort to remember to use it, unlike pretty much every other desktop app for WordPress. And yes, I’ve tried those.

  • The Details of Your Life

    The Details of Your Life

    Becuase it’s my son’s birthday this week, can you please do X faster?

    I get emails like that a lot. It has to do with the nature of my volunteer work. It doesn’t really matter what the actual, technical, request is. Pretend it’s a request to reboot a server.

    I don’t need to know that your partner left you, took your dog and your truck, and so it’s really the worst day in the universe for your site to be down.

    The truth of the matter is I really don’t care. No one in support (dev or tech or any) actually cares about the country song that is your life. This doesn’t mean we don’t emphasize with you and feel sorry that you’re having a crappy day. It means the crappiness of your day doesn’t magically make us be able to do things faster.

    That server reboot? All the sob-story in the world will just not make your server reboot faster. Got a security issue? Ranting about how life is unfair doesn’t get it fixed and reviewed faster.

    We do get it. You’re having a shitty day and this one thing, this item that appears to be at the arbitrary whim of some relative stranger, is holding up your ability to feel better. Except we’re not. We’re following process and procedure for a reason. The world is bigger than just you, and we have to consider all of it when we do a thing.

    If rebooting your server impacts more people than you, say 500 other people, then we can’t just reboot on demand. We have to ensure we won’t break them either. If the security fix isn’t complete, or worse, we find more insecure things, we can’t wave our hands at it. We know what hackers look for and we want people to be safe.

    When you’re having the worst day of your life, when your server is down or your plugin is closed or your account is locked out, stop making it worse. Take a deep breath. Remember that the world is a big place. Ask politely and trust that the people are doing things to the best of their ability and speed and safety for you and everyone else.

  • It’s Okay To Overwhelm

    It’s Okay To Overwhelm

    “Your email overwhelmed me! I can’t do this!”

    That’s what the email reply I got was. It had started innocently enough. Someone asked how to set up Multisite. I linked them to the article and sent them a free copy of my ebook WordPress Multisite 101.

    He emailed back asking again how to to it and I replied that he needed to read the link and the ebook and, if he had a specific question, to ask, but otherwise, those two items were what I could do for him at the time. He wasn’t a customer, a client, or even a friend. He was barely a friend of a friend of a friend. There was no social contract or legal one. He was basically someone who asked a question.

    Seven emails later and a very angry chain, he finally explained that he had already activated Multisite, before the initial emails, and it was broken. He could no longer log in and, damn it, he didn’t actually WANT multisite. So I explained he needed to un-do Multisite, showed him where (in the ebook, and via a link) he could get directions on that.

    And that overwhelmed him.

    Now at this point, my friend who introduced him to me apologized and said he’d explain to the guy what ‘taking advantage of someone’s kindness’ meant.

    While I do feel sad that I overwhelmed someone and that he was in over his head, I don’t feel any guilt for not providing hands on help like that. There’s a limit to how much ‘freebie’ you can throw out into the world, and this fellow was not being very clear about what his actual situation was. If it had started with “I accidentally set up Multisite. How do I undo it?” I would have given him a quick set of directions with a note of “If editing the DB is too complicated for you, you’ll need to hire someone.”

    There is no shame in hiring someone when you’re overwhelmed.

    When you’re in over your head, you will make bad assumptions, get lost, and make expensive mistakes. If you think someone is expensive before you start your own demolition and plumbing, imagine how much the cost will be when they have to fix what you did to yourself? Websites are pretty much the same way. It’s the nature of the service industry really. You’re trying to perform a service on your own instead of paying an expert. If you get it right, awesome, you’ve learned new things and have a new skill! If not, you pay more.

    But that’s actually why I think it’s okay to overwhelm someone sometimes. When you give them a large amount of data, if they’re willing to learn and concentrate, then they can learn not only about a process but about themselves. The issue isn’t the data dump but how we react to it.

    When you’re overwhelmed, and believe me I’ve been there too, you have to take the elephant one bite at a time. You didn’t know how to drive a car perfectly the first time you sat in one. You couldn’t ride a bike from day one. You won’t be able to do anything 100% correctly out of the gate unless you’re a savant. Most of us aren’t.

    Perfection is the enemy of progress, though. If we all wait until we’re perfect, we’ll never get anywhere.

    It’s alright to be overwhelmed. It’s not alright (though certainly understandable) to let that prevent you from making progress.

    Be overwhelmed. At if, in that moment, you learn one thing, then you’ve made progress.

  • Say Thank You Publicly and Be a Better Coder

    Say Thank You Publicly and Be a Better Coder

    Takayuki Miyoshi is one of the best developers for WordPress you probably don’t know about. Miyoshi-san is quiet, thoughtful, and had written a handful of plugins you probably do know. Like Contact Form 7. He’s also written a wonderful multilanguage plugin called Bogo.

    He gave his very first presentation in English about why he uses free plugins. Miyoshi-san’s reasoning is plain and simple. By giving back to WordPress and open-sourcing the code, you have a greater chance of people helping you make your code better. More people will find bugs, more people will help you fix, more people will use it, and things will be made better for everyone.

    This is much the same idea as Pippin Williamson has about his open source philosophy. Now Pippin is pretty upfront that he thinks you should open source your plugins. And he’s got some strong views on supporting your site projects (and the responsibility there in). But he also mentioned once that he supports putting premium (i.e. paywall’d) products on Github.

    For free.

    That’s right. He said you can totally put your code up on Github for anyone to download or edit or fork.

    I thought about it for a moment, and how open and honest Pippin has always been with his code, and how some of his early WordPress code was not the greatest. Yes, I have been around WordPress long enough that some of the people I think of as being ‘The Real Shit’ about coding for WP were pretty bad. Maybe not as bad as I was when I started, maybe they were. My point is that Pippin, like everyone else, started out as a beginner. And some of his beginner code was bad, like everyone else’s.

    Would Pippin be as good a programmer as he is today without open source and without people giving him code corrections and suggestions?

    I think not.

    Furthermore, I don’t think that you’re going to lose any money here. The intersection of people who would both buy your plugin and are technically capable of using Github to install plugins is pretty small. I say this as someone who understands well the desire of people to get things ‘free’ from the internet and the seriousness of customers. If you make it easy for someone to buy your products (and in the case of WordPress, get updates for it), people will pay you. Because they like convenience. Remember the tale of Oatmeal vs HBO. If you stop people from being able to get your product easily, they just won’t.

    Most people are afraid of monetary loss, which I get. But you have to rethink things. First of all, most people won’t use Github. They won’t like not getting security updates, for one. And if you present Github as a technical place, they won’t use it. Done. Secondly, I happily bought the Person of Interest DVDs once Netflix got punched by (I presume) WGN on re-broadcast rights and couldn’t show me Season 4 before Season 5 airs. I get the added bonus of watching it on my Blu-Ray player, in super ultra HD. This behavior is NORMAL. Amazon made it easy for me to get what I wanted, and now I own it and if the Internet is out, well I’ll watch Root and Shaw and the Machine all day.

    And there’s something else to consider. The people who would use Github to get something for free are the folks who wouldn’t have paid in the first place. You’re losing money that you’d never have. To help explain this, I’ve made a little Venn Diagram for you, to show you how small this intersection is:

    percentage of people who would both buy your plugin and are technically capable of using Github to install plugins is pretty small

    I’m serious here. This is non-mathematical but based on my allegorical experiences of years in support be it free or paid. This is coming from someone who lives and breathes WordPress plugins. If you make it easy for them to pay, you will not lose money by putting the code up in a way for other developers to submit pull requests. That small sliver of green, the people who can use Git and would still pay you, those are your contributors. Those are the people you want. Because Open Source Code means more eyes, and more eyes means more reviews, and more reviews means better code.

    Everyone wins.

    And like Pippin and Miyoshi-san, I think that having your code available for others means I may learn new things and become a better developer. When I say ‘pull requests welcome’ what I mean is ‘teach me what you know, I love to learn!’ Even if I say “No, I don’t want to add that feature” trust me that your lesson was welcome and absorbed.

    When I went to WordCamp Tokyo, I had the intention of seeking Miyoshi-san out to tell him how much I like Bogo. That it solved a problem for me. That it just worked. That the code was good. Miyoshi-san also wanted to tell me thank you for the things I’ve done for him.

    It’s possible we both got a little teary eyed.

    And he and I agree on the big things. Make your code available for others to review and comment on and get pull requests. It will make you better.

  • Rant: Lightboxes and Scrolling

    Rant: Lightboxes and Scrolling

    Lately I’ve run into a problem where a tool I’m using has a lightbox that’s cut off at the bottom of the screen.

    This generally happens because I have my browser at half-height, or because I’ve pressed the ‘increase font’ keys to make a site 110% text for readability (WordPress P2, I’m looking at you). Here’s what life can look like for me:

    Dropbox doesn't scroll with lightboxes

    This image shows a lightbox cut off midway. The bottom of the picture shows the bottom edge of my browser. Obviously I could make my browser window larger, and most of the time this is what I do. But should I have to? There are situations where I can’t do that, like on mobile. Whomever decided that overlays on mobile was a good idea needs to have their favorite sweaters eaten by moths.

    Make your screen scrollable. Make sure your lightbox doesn’t get totally jacked up when a screen is ‘too small.’ A major part of responsive design is not just making sure your site works on mobile devices and ‘full blown’ computers, but that it works on all sizes of monitors when a browser isn’t maxed out.

    Here’s another example:

    Another example of Dropbox not accounting for screen limitations

    In that image I have what I can only presume is an advertisment that wants me to click something. It’s not until I change my zoom to 75% that I can see this is an ad for Dropbox Business:

    I can only see the ad for Dropbox Business if I reduce font to 75%

    Oh and Dropbox was totally unhelpful when I reported these things, which is why they’re getting shamed. They said to fix my screensize.

    When a similar issue happened with Slack, I got an apology and a promise to address it. Which they did within a week.