Author: Ipstenu (Mika Epstein)

What I Learned From The Man

It’s no secret I worked for “The Man” for nearly fourteen years. I’ve learned some pretty amazing technical things from that, but I also learned some tricks about ‘working’ with a big company that have yet to fail me no matter where I worked. They were all lessons my family instilled in me, but having some pretty amazing people like Bonine, Margie, Joe P., Nikki, Rae, and a host of other amazing people all reinforce the morals of the stories, and it made me know that these were the right things.

Always Admit Fault

Scariest moment of my life was the day I accidentally rebooted a trading server at 10am on Thursday. Those were only supposed to happen at 10pm on Thursday nights, well after all trading was done for the day. I did it mid-day which meant there was a high risk that in-flight data could be lost. I was tasked with diagnosing what had happened and, after a lot of review, I came back and said the only logical reason was I had typo’d when I scheduled the time. We since changed to 24/7 clocks and not AM/PM to mitigate, but I was up front about the error being me. Similarly, when a bad change I made to a script broke the internet for all of our UK offices, I said it was me, I fixed it, and I took the hit. This meant later when a change I’d fought against was put in and caused an outage, everyone believed me when I said I’d done it, but it was someone else’s idea. I had credibility and history and (of course) documentation on my side.

Document It Or It Didn’t Happen

I had a boss whom I did not like. I liked the work, but working with him was terrible. He didn’t grove like I did, he was misogynistic and racist. He also had a flagrant disregard for protocol. Love it or hate it, when your company has specific steps to follow to do a thing, you do the steps. He didn’t want to and demanded I make an on-the-fly change. Verbally. I didn’t. This ended in a shouting match which our manager had to step in and settle. But before that event, I was told to make a change I knew was wrong. I demanded it be documented that this was a change in scope and a requirement by him. I then, under duress, made the change. It broke. I backed it out. That marks the last time I ever let it go that far and may explain to many people why I’m so firm about not letting people do ‘wrong’ or ‘bad’ actions. If I know something’s wrong, I won’t do it and I won’t help you do it.

Remember You’re Special, And So Are They

I’m a techie. I know all sorts of weird things. Remembering that I know those things and understand the different between minimizing a screen and closing a window is important. Joe reminded me about that once. I never forgot it. I also don’t forget that my place is to make sure problems are solved. So just because I don’t panic doesn’t mean I’m being cavalier, but at the same time I have to make sure the other person knows that.

Credit: xkcd

That window resize via a resolution change was the only way to fix a specific problem with a specific app. I used to travel across town to do it for people because trying to walk them through it on the phone was too difficult.

Use Your Calendar

“I’m sorry, I’m really busy.” has a lot more weight when they look at your calendar and see it’s booked. Solid. When I know I need to spend time working on a specific project, I schedule it as booked time and that way everyone can see and understand I’m busy. This is also a respect issue. If someone schedules a meeting, you confirm and click that damned ‘I accept’ button. It’s a contract, or a friendly agreement, in order to tell someone ‘Yes, I will be there.’

Don’t Waste Group Time

Irony. If you think about big companies, you think about wasted meetings where people never get anything done. I’m not talking about that (which is a thing). I’m talking about wasting time with being disrespectful of the meeting. Keep your phone/mic on mute in a conference call so no one hears you pounding on a keyboard. Turn off your video feed if you’re not presenting so you speed up the internet for everyone. Joining in a massive meeting with hundreds of people? Get a conference room for your location to prevent overwhelming the system. If it’s an on-line, text meeting, follow the announced protocol.

What Did You Learn?

I’m not the only open-sourcer who used to work for the Man. Did you learn anything that you still use today?

Those meetings, by the way, are generally a waste of time. I greatly prefer stand-ups. Everyone gets 60-90 seconds to state status. Everything after is taken outside meetings.

11 March, 2015
Markdown Isn’t All Bad
It’s not a secret I hate markdown. It’s annoying to remember various commands, and one of the things I loved about WordPress from the start was that I didn’t have to learn bbCode or anything beyond the HTML I knew. When Jetpack included Markdown, I was a huge opponent. I thought it was useless and pointless and a waste of space.

I now use it in many of my posts.

You see, I don’t write in the visual editor. I used to, but there are ‘glitches’ with it. Like I couldn’t see the embed for Facebook (it showed up blank for some reason), and I had trouble embedding video content that required me to paste in script code. Then when I starting writing code, like I do on this site, I needed to make sure the formatting didn’t get mangled. It all boiled down to giving me two places where I use the Visual editor, and everything else is text.

That’s all well and good until I fell in love with my iPad mini.

You see I also have a major annoyance with the iOS app for WordPress. It’s too easy to post to the wrong site and it’s problematic when you want to upload featured images or make custom excerpts or have any custom post types. That means I use Chrome or Safari on iOS to write blog posts. If I’m offline, I write it up in Notes or Byword and just have it there until I’m ready to import. But I use WordPress in my browser because that’s where it works ‘best.’

Except HTML on an iPad is a pain in my ass.

It really, really, is. The number of clicks you have to do just to make a header, or strong text, is annoying. It’s three clicks to make an <h2> and it’s not even in the same place. It’s one click to get to the numbers, another (one up from where you hit to get to numbers) to go to advanced characters. Then you can press the button. Any chance I have to minimize my clicks means I can type even fast.

And you bet your bippy I’m fast at typing on my iPad.

Markdown’s syntax is intended for one purpose: to be used as a format for writing for the web.

John Gruber’s Markdown syntax primer is the only place that really took the time to make sense of Markdown to me. Everyone else just said ‘It’s what we use’ or ‘It’s faster’ or (worst) ‘It’s better.’

No. No. No. Better is what works for you. HTML, for the most part, works for me. And for me, a small subset of markdown syntax terms work very, very well to speed up my writing:
```
## Title

### Subtitle

&amp;amp;gt; Blockquote
```
There are a few more, like the codeblock (which I don’t use, since I like pretty formatting better) but the ability to use backticks and say <code> is pretty nice.

So do I like Markdown? No. It’s hard to remember ‘new’ syntax. But the ones I can use without having to close tags makes me a little happier and speeds me up a bit. For that, it’s pretty good. I can use it to enhance my HTML, and I wish that MediaWiki let me use HTML and Markdown instead of their woe begotten WikiSyntax. My kingdom for <table> in MediaWiki. Am I right?

Now. If I could just get John Gruber to increase his font size.
9 March, 2015
Mailbag: What Code Makes You Sigh?
When I was talking about ThemeForest, I mentioned we had code on WordPress.org that made me sigh. Or cry depending on the day.

Here it is:
```
if (!defined('WP_CONTENT_URL')) define('WP_CONTENT_URL', get_option('siteurl').'/wp-content');
if (!defined('WP_CONTENT_DIR')) define('WP_CONTENT_DIR', ABSPATH.'wp-content');
if (!defined('WP_PLUGIN_URL')) define('WP_PLUGIN_URL', WP_CONTENT_URL.'/plugins');
if (!defined('WP_PLUGIN_DIR')) define('WP_PLUGIN_DIR', WP_CONTENT_DIR.'/plugins');
```
Why do I sigh?

It’s not needed.

You can use functions to determine those directories and while I’m sure someone’s thinking “But WP_PLUGIN_DIR is shorter than plugins_url()!” it’s not.

That code block above was used so that one line of code could exist.
```
include(WP_PLUGIN_DIR.'/PLUGINNAME/settings.php');
```
Those four lines, plus the include, could be replaced with this:
```
include( plugins_url( 'settings.php' , __FILE__ ) );
```
So yes, I sigh. Because with just a little work, you could see that there’s a more efficient way to make your plugin smaller.
6 March, 2015
Packaging Code

I love that people do it. I hate that they don’t review it.

The number of projects I review, only to find that the author ran a tool like Grunt to combine files, but forgot to go over what the result was is fairly high. And this is a problem when you consider how many times I have to tell people “Your submission still has demo files, test scripts, and other files that aren’t applicable for distribution.” What happens is that people use the very cool auto-scripts and never stop to make sure that everything’s right. They make sure the code works but they don’t remember to clean up the package.

So let’s talk about what should never be in your plugins for WordPress.org

Deployment Scripts

Now I know a lot of people use scripts to copy their code from GitHub to WordPress’s SVN repo, and I think those scripts are great. They’re helpful, they speed up development, and please keep them out of your plugins. Your script should include a note not to distribute itself. I understand why, when you link us to the GitHub default zip, those scripts are in the review package, and that’s okay. But I do sometimes run a sweep through the repository to see how many people are accidentally including those SH files in their plugin packages. You’ve got to remove those. They don’t matter to the final product and without them, your plugin will be smaller.

Demo Folders

Here’s the thing. They don’t matter. A lot of awesome 3rd party tools come with detailed demo files and extensive things you’ll never need. Those demo folders also tend to be where you’ll find all sorts of crazy things like Google Analytics tracking, calls to external resources (like jquery’s JS files), and more. Your users will rarely, if ever, need that sort of thing. They generally don’t notice it, unless you code it into your plugin, at which point you’d be better served by making it look like WordPress.

Test Scripts

Your test scripts don’t need to be in your plugin. They’re cool, to make sure that the code is going to work before you push it, but that code doesn’t need to be in the plugin on my site, does it? No it does not. All automated tests should be separate from your plugin code files. People don’t need to see the Travis checks in the code on their sites. If they’re developers, they’ll go look for them at your code’s home, after all.

Compressed and Uncompressed Files

Pick one. You don’t need both. When you’re talking about a framework or a library, it’s fine to pull in a minified (but not p,a,c,k,e,r compressed) version of the file as your own version. If there’s no need or plan to edit that file (and there shouldn’t be), you can make the plugin smaller. Of course, I feel that if the JS is all of 7 lines, for goodness sake, it’s fine to leave it all human readable.

What Else?

What do people leave in plugin or theme packages that drive you up the wall?

4 March, 2015
I’m Fine With Envato

I just don’t use ThemeForest.

Look. I think Envato is actually pretty awesome. They’ve made a way to help people monetize development within WordPress. I’m all about that! I want to see people making a living from WordPress and I want people to be able to succeed and make WordPress even better. A number of people I know who are currently successfully running their own WordPress related business got started over there.

So why don’t I use their products? I haven’t had a need to. I don’t use WooCommerce either, or their themes. There’s nothing wrong with that. But there is a ‘problem’ with Envato, or rather there’s one with ThemeForest, and it’s the same problem as we have on the WordPress.org plugin repository.

The last (and possibly only) time I mentioned them, I said I had an issue with their lack of upgradability. If I buy a theme or a plugin, I can’t easily get updates. I’m stuck on the old way of download when I get an email. There’s no way to do it easily from inside my dashboard. This is a problem of our own creation. Ten years ago, that was normal. Today, we have a reasonable expectation to easily upgrade WordPress, it’s themes and plugins.

I happen to know Envato’s working on it, so I still look forward to their solution.

But they have the exact same problem as we have with the WordPress.org plugin repository: crap code.

You see, there’s only no practical difference between the WPORG repository and ThemeForest and how it handles reviews except they actually may be checking on every upgrade. If you didn’t know, ThemeForest does review things. But they do it exactly like we do! They read the code, they test it, they look for evil things, and they approve or not.

Theme review on WPORG is a tighter ship than plugin, for a few reasons, but frankly I doubt the overall quality of code on WPORG (plugins) or ThemeForest is all that different. We’ve had some pretty insane vulnerabilities in plugins, after all, and the WPORG repository doesn’t have a great way of dealing with them. But to say that you don’t trust ThemeForest because the code quality is bad while simultaneously using any free plugin from ORG is naive at best.

The constant problem we have with plugins, and one they have with ThemeForest themes, is that we allow a lot of different types of code. In being liberal like we are, we can allow for a lot more creativity and expression and, well, art. The downside is that there’s a practical limit to what a human being will be able to catch. We’re like the TSA. We try, but we’re fighting a loosing battle and that’s why we’re always going to miss things and we’re always going to be running behind and cleaning up.

And worse they have the same problem with any code they yank. How do you upgrade everyone? When is it right and safe? When is it an overstep? Weighing security risks with information with compatibility is complex. For the WordPress.org repository, we have a long way to go before we’ll be able to push minor security updates like core can… at least not without a lot of fear and consideration. We’re on the road there, though, so one day you may wake up to a plugin magically secured on your site.

Oh and as a reminder? If you see a WordPress.org plugin hosted that is insecure or doing evil things, email plugins@wordpress.org with the plugin URL and all the possible information about how it’s insecure. If you know how to hack it, please tell us exactly what you did. You make it faster for us to sort things out.

For Envato, you can report these things via their Helpful Hacker program.

2 March, 2015
Mailbag: Being Rejected Is Good

Do you talk at every WordCamp you go to?

Nope.

You probably wanted a longer answer. I suspect the real question is “If you apply to speak at a WordCamp, are you always accepted?”

Nope.

Looking at the numbers, I speak at just over half the WordCamps I attend. I apply to about 75% of them (yes, sometimes I intentionally do not apply, it’s nice to just go to a camp). I’ve been specifically asked to apply to a couple, and I’ve been requested to speak (no application) at two I think (one I did not manage to attend, sorry).

But I’ve applied to multiple WordCamps and not been selected to speak, like WordCamp San Francisco 2014.

It doesn’t bother me much.

Oh, it bothers me some, since I don’t often get to find out why. Sometimes I do. I like when I do. But looking at WCSF 2014, I assumed I was a long shot. I’d spoken at the last two, there were a high number of applicants, and lets be honest, we should get some new faces in there. I also don’t think I submitted the best application, but it was rather obligatory that I do submit, so I did.

Still, it’s good to get that rejection email, especially when they do tell me things like “We already had X number of speakers apply about Foo, and you’re not local.” I love hearing that one. Yes, pick local! The generic rejections, like from WCSF (I swear I’m not picking on it) makes sense when you consider the mountains of submissions. Same with WordCamp NYC. I submitted twice, once something I picked and once was something they posted as ‘Talks we’d like.’

That’s my magic sauce for speaking, by the way. I ask what kind of talks they’re looking for, or what the theme of the WordCamp is. A WordCamp based on security should have a security themed talk. A WordCamp with a high number of bloggers and community runners probably would benefit from a talk about dealing with the community. Not everyone has a wide range of topics they can talk about, of course, but it’s still good to broaden your own horizons and talk about what both makes you comfortable and what doesn’t.

The rejections I learn from. I try to ask what about it wasn’t right. What did people want and not get, what did they not want. This works well with my job, because I’m supposed to be keeping in tune with how people are using WordPress, and being rejected means I learn where I’m wrong.

Does it hurt? Of course. ‘Losing’ in any sense of the word is painful and uncomfortable, and all the time I tell you that you can learn from it doesn’t make that feel any better. But what will make you feel better is next time. Because if you do learn from it and become better at what you do, then you will speak at an event, or stand up and do a thing, or simply succeed, in whatever way you mean for that to be. And not much feels better than that.

My father told me once that you lose more than you win, and losing hurt worse than winning felt good. He’s right. And that hasn’t changed in my life one bit. What has changed is that I appreciate the winning a whole heck of a lot more, because I’ve lost.

27 February, 2015