Posted on

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!

Tumblog

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

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.

Posted on

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!

Posted on

WordCamp Spain

Just a quick note to say that I’m heading to Barcelona today for WordCamp Spain on Saturday! 🙂 It’s gonna be awesome and I will post my slides and experiences here afterwards. I’ll be presenting on WooTumblog and Post Formats, as well as the Express for WordPress iPhone app.  Check out more details here: http://wordcamp.es/ (you might wanna do it through Google Translate for english).

Posted on

WooTumblog WordPress Plugin

For those who follow WooThemes, you will no doubt have seen our Tumblog Themes such as Cinch and Crisp, and will know that they give you similar functionality to a tumblr style blog from within WordPress. So if you didn’t buy one of our tumblog themes you wouldn’t be able to have that functionality, but now you can for FREE! In addition to this, you can buy the Express for WordPress iPhone app and publish content to your Tumblog enabled WordPress blog right from your iPhone!! See the official announcement page here: http://www.woothemes.com/2010/10/tumbling-along/
Continue reading WooTumblog WordPress Plugin

Posted on

Twenty Ten Custom Taxonomy Template

I’ve been doing some modifications to the default WordPress Twenty Ten theme and I needed a custom taxonomy page template for my taxonomy archives – taxonomy.php – to take advantage of the WordPress template hierarchy. So I made a generic one for the Twenty Ten theme seeing as it doesn’t come with one.  So now your custom taxonomy archive pages don’t have to say “Blog Archives”, instead with this it will output the Taxonomy as well as the Term, similar to the Category archive page. Simply download the file below, extract it, and put taxonomy.php in the root of your Twenty Ten theme!

[download id=”4″] Continue reading Twenty Ten Custom Taxonomy Template

Posted on

FlagTag WordPress Plugin

Seeing as how I’m big on getting behind your sports team, I saw an initiative by White Wall Web (Disclaimer: I used to work for them) to get the internet into the World Cup Feva by adding what they call a FlagTag to your site.  I think it’s fantastic, see my FlagTag on the right of the site.  But what most people (who cant code) don’t know how to do is add the code to their website.  So I thought, let’s use my WordPress experience and slap together a plugin.  No code editing, just a simple download and upload, activate the plugin, and choose your flag! It’s that easy.

Download it here or here. Continue reading FlagTag WordPress Plugin