Royal Mountain Motorcross – May 2015

My brother has started to get back into racing dirt bikes and decided to hit the track this past weekend. He had a mechanical failure during practice and we weren’t able to get it fixed before the races. We had a fun time watching the races anyway and I took a lot of photos and some video.

Here are some pictures of my brother riding during practice (#879)

And here are some photos and a few videos of the various classes and races that happened during the day.



Five Ways to Secure Your WordPress Plugins

I wrote a piece on the VaultPress blog recently about some basic security practices plugin developers should know and include in their own plugins.

This sums up my beliefs on being a plugin/theme developer:

Writing plugins for WordPress gives us so much freedom and flexibility on the platform and with this ability comes a responsibility to the community; a responsibility to develop secure plugins that the community can trust and use on their websites. And by doing so, we are making the web a better place.

Read the full article:
Five Ways to Secure Your WordPress Plugins

Talk: Getting Started with the Cron API

I’ve wanted to speak at a conference for a long time and only recently decided to take the leap by submitting a talk for the local WordCamp in Saratoga. I chose the topic of the Cron API because I use something very similar everyday at Automattic and I’ve not seen any talks on the component in WordPress Core. Check out the video of the talk below. I’ve also posted the slides on Speaker Deck.

I’ve been waiting for the video to show up on WordPress.tv¬†so I could review my first talk and see what I needed to work on. Overall I think it went well and there was a good turnout (we only had two tracks of talks) of around 40 people. A few things I need to work on: speaking more clearly and enunciate, refrain from using filler words as often, and use specific vocabulary consistently throughout the talk. I also noticed I looked down a little too much (mainly for keeping on track with my presenter notes) and I pointed at the projection a lot. I’m not sure if that was distracting or even necessary but I made my slides in a way that highlighted parts that I was talking about, pointing seemed redundant.

I was pretty nervous right up until I was standing in front of everyone and only became nervous when I lost my place or words. Regardless I thought it went well and I had fun. I plan on speaking again soon.

What did you think? What would you like to hear me talk about in the future?

The Feeling of Insecurity

“… the desire for security and the feeling of insecurity are the same thing. To hold your breath is to lose your breath. A society based on the quest for security is nothing but a breath-retention contest in which everyone is as taut as a drum and as purple as a beet.”

– Alan Watts

Your Code May Be Elegant

OmniTI ~ Your Code May Be Elegant

I’ve had this article bookmarked for some time now and I agree with what the author says. Too often in this field I’ve heard developers complain about another developer’s code because it doesn’t fit into their standard. I’ve definitely looked at code and scoffed at it both vocally and in my head.

Over time though I’ve learned there can be good reason for why something was built a certain way. It could absolutely be a budget reason where they had to cut corners a bit. It could also be that the developer honestly didn’t see a better way at the time, we all have old code we’re embarrassed to look back at. Even at Automattic we have code that’s difficult to work with and other parts that are a joy with great inline comments and unit tests.

Why is this? Expediency.

A good engineer is not the one who knows how to build the most advanced system, but the one who knows when not to build that system.

Sometimes the expedient way is, at the time, the best way. It’s how we hit internal deadlines and/or how we redirect¬†our focus to a portion of code that could benefit most from the time spent making it elegant.

Very often I’ve noticed it’s a lot easier to see how a part of code could have been written better (DRY) after you’ve written what’s in your head. It can be difficult to see the bigger picture on how different parts of the architecture communicates with each other without first building what’s initially in your head. Iterating on the initial idea is key.

Get over yourself, be understanding, and remember that we’ve all been there. If you’re working with someone who always goes the expedient way, maybe they need some help. Talk to them, be open to educate each other and learn together. Complaining doesn’t move anyone forward.

As software developers, we often think our job is to develop software, but, really, that is just the means to an end, and the end is to empower business to reach their goals. Your code may be elegant, but if it doesn’t meet the objectives (be they time or business) it doesn’t f***ing work.