WordCamp Cape Town 2013 is here!

WordCamp Cape Town 2013 is only a few days away! A few of us local Capetonian WordPress community members have been organizing this years’ edition after last years’ organizer decided not to pursue it this year, and it’s been a great experience getting to grips with organizing a conference.

So now we are in the final stretch, grab your tickets now, check out the awesome speakers and the lineups, and come say hi on Thursday – I’ll be roaming around as a happiness expert and coordinating a few of the volunteers. WordCamp is all about the community, so let’s connect, have some fun and be inspired!

[box type=”tick” size=”large” border=”full”]Buy WordCamp Cape Town 2013 Tickets[/box]

[box type=”info” size=”large” border=”full”]See the WordCamp Cape Town 2013 Speakers[/box]

[box type=”info” size=”large” border=”full”]Check out the WordCamp Cape Town 2013 Schedule[/box]




WordPress Heartbeat API example plugin – Pulse

One of the most important experiences for me at this years WordCamp Europe was meeting other people, specifically members of the WooTeam who I haven’t met before. One of them was Remi Corson, who after overhearing a chat I was having with Patrick Rauland, sat me down and showed me what he was working on with Heartbeat API.

It was an awesome chat! The power of collaboration between WordPress community members is so cool 🙂 and in the spirit of collaboration, I’ve decided to release an open source plugin that will help you get started with your own Heartbeat API development.

So check it out on Github, fork it, submit some pull requests, if we can make life easier for other WordPress developers wanting to use Heartbeat API in their products then that’s what I’m hoping for!

In the long term I’d like to contribute back to the Heartbeat API docs because they are severely lacking at the moment!

Pulse – Heartbeat API example plugin

WordCamp Europe 2013

I’ve had the privilege of attending the first WordCamp Europe the past 2 days with the rest of the WooThemes crew and it’s been awesome! I thought I’d share some of the highlights for me:

Old Avatars, New Faces

I worked on WordPress 3.0 for menus with a few people but I never met any of them in person…until yesterday! I finally got to meet Ptah Dunbar and he’s a pretty cool guy! But that was just the first of many WordPress pro’s I got to meet…for me this conference has been a revelation to me in terms of understanding the community better – and not relying on twitter avatars to get perception of people.

Some of the (other) awesome people that I got to meet:

That’s what I’ll remember about WCEU – the people and the relationships.  Even just hanging out with the WooThemes team and talking about code and ideas has been such an inspiration for me personally and professionally. Some highlights were talking about the Heartbeat API with Remi, and BuddyPress with Scotty B. Moments like that are priceless in a distributed team like WooThemes.

I’m hoping the talks videos will be online soon so everyone can check them out! And now I’m tired…sleep time! 😀

Check out my photos here and here.

Letting Go

I’ve worked on numerous products at WooThemes over the past few years, and like most things I work on, each one I’ve ended up developing an attachment to; after all I was creating something and much like a parent (which I can fully appreciate since the birth of my daughter) I want each product of my creation to flourish to it’s full potential. However, something that I found in the past that was very hard to do was to let go of the “thing” and see it in the hands of others, sort of letting it “fly” in a way.

The Problem

The problem with hanging onto a “thing” is that you (may) eventually lose your objectivity in terms of making decisions, well that’s what I’ve found as the original developer of a product. You sometimes lose sight of when to stop developing a project, to pivot, or to kill it.

At WooThemes I’ve seen several things I’ve started working on either fly or fail, and it’s a difficult thing to watch from the sidelines because so often I’ve wanted to dive right back in and “fix” it – the problem with that, is that usually no one wins! Not the project, not the people involved and certainly not myself.

I’ve seen the following examples in my career:

WordPress Menus/WooNav

I built WooNav as my first project at Woo and I’m still immensely proud of it, however opening myself up to the rest of the WordPress community and their ideas and thoughts for how it was going to end up as in the WordPress core was difficult. I’ll be honest, I didn’t agree with some of the initial decisions, but it turned out for the best for WordPress. And that’s the bottom line, it wasn’t about me or what I thought was best for the product, others have done a fantastic job of taking what I originally built and making it far superior than that initial commit. It’s good to be wrong every now and then!


Another of my early Woo projects, our Tumblog themes/plugins arguably gave rise to and increased the prominance of the popular “tumblr” style WordPress themes. Eventually things led to post formats being included in core, of which we had nothing to do with directly, but I do think that ultimately the Tumblog functionality influenced the community in a positive way. Over time the plugin popularity has waned and isn’t even necessary for a tumblog style design because all that goodness is in core. So the Tumblog plugin will eventually die, much like Woo’s Tumblog themes, and that’s not a bad thing – may it rest in peace.


Sensei is my current development project at Woo and I’m super passionate about it and education in general, but more recently other members of the team have been getting involved in the development of the core code and it’s been awesome! I originally had a definitive direction in my head, but it’s been nice to let go and allow others the breathing room to run with ideas and build it without having to “run it by me.”

The Point

If you are a product visionary/original developer and are building in a team environment you need to be able to take a step back and allow others to embrace the product as their own – this allows for greater creativity and opens the product up to new ideas and can help elevate it to greater heights.

Self Commenting Code

So…a colleague of mine, posted a tweet today about self commenting code. I briefly replied, along with others, and I thought I’d share some of my thoughts on “self commenting” code and standards.

Whose rules are you following?

First things first, who defines what is self commenting code? I guarantee you that different developers will see code and comments differently. For example, a php developer who is used to a rather loose language structure, will think differently from a more structured C developer when it comes to commenting their code.

There are different interpretations based on different standards, and one such standard I have researched and written about is the Construx CxOne standard based on Steve McConnell’s work. And even by using such a standard as guidance, some of the standard is specific, for example naming conventions and formatting of variables, while other parts are vague, for example in section 1.6 under commenting “Remember the comment audience

With that said, let’s take this one step further…

Developer Career Levels

If you have been coding for 10 years (or even 5), think back 5 years and ask yourself if you know more or less than what you do now? That’s fairly simple, however, ask yourself if you are a better developer?  Who defines what “better” is – is it a feeling or do you use a metric such as a standard to govern this? Or is it your practices and habits (such as commenting and naming conventions)?

But all that aside, simply think of working in a team with junior and senior developers. I’ve had this very experience at a previous job where one of the senior developers and I had to work together on a project, and he had his ways and I had mine – whose way is better?

But is that even the right question? The real question is, when it comes to coding together is communication. Can I communicate effectively through my code to other developers. If the senior developer on the above project used super complex code with no comments, I would have been screwed and the project would have suffered. But we had defined coding standards before the project began so we knew what to expect. The same should be seen in the WordPress community, as WordPress has set code standards.

Let’s go a bit further down the rabbit hole…

Code Frameworks

Some frameworks use camel casing (but is that upper or lower camel casing…) for naming conventions of variables and functions, some have coding patterns like MVC, MVP, or n-tier, and some use docblocks to generate API docs to elaborate on there instead of the code – and here again it’s worth noting who is the audience? WordPress is a fantastic example of this – the Codex serves the community far better, in my opinion, than tons of comments in the code.

Onwards to my final point…

Who cares?

Ultimately this argument is subjective and people will inevitably have an opinion one way or another, because people are different and like to have their own opinion (just take religious arguments as one example) – the main thing here is to communicate well, if you do that well through your code, then you’ve already won!

WordPress Cape Town Meetup with Matt Mullenweg

Last night we had an awesome WordPress meetup in Cape Town at Sinn’s restaurant in the city centre, and none other than Matt Mullenweg was the guest of honor! It was great chatting to him and meeting him in the flesh. We chatted about MP6 plugin, REST API’s and where WordPress is going in the future. All in all a fantastic evening!


As you’ve no doubt noticed…this site has been down for a long LONG time…partly due to my boredom with blogging and just being so darn busy! Oh, and my wife & I welcomed our first child recently, baby Eva Marie Pearce!

I’ve decided to give it a complete rethink and I’ve actually rebuilt it 4 times already! Each time I was never happy with the outcome, and now it seems I’m getting there.

I ended up using a combination of The One Pager theme from WooThemes, WooCommerce to handle my plugin downloads, and I’ll be using Sensei soon to run 2 Courses starting shortly, the first of which will be free!

Here’s to more blogging and more code (and courses) releases!