One of the things that I think is easy to forget about working within the WordPress space is that we’re often talking to a circle of [many of] the same people. By that, I mean that developers are largely talking to other developers (and likely some designers), designers are talking to other designers (and likely some other developers), and so on.

I mean, I have no expectations that anyone who reads this blog is outside the scope of someone who writes or wants to write WordPress code.

And though there’s nothing inherently wrong with this – I mean we’re naturally all about creating groups and communities – I think that it can negatively influence how we may be marketing our products or even discussing our work with other people.

In fact, I’d argue that one of the biggest problems that we have as it relates to marketing our WordPress projects is the fact that we use phrases “clean code” or something similar when trying to sell others on our work.

Communicating Code Quality

First, to be clear, I understand that even though people don’t necessarily know what code is, they want to assume that they’re running something that’s well-built. As such, the best way for us to communicate this to them is to tell them.

Honestly, there are other ways to do it, but this seems to be the way that we’ve chosen to go. There are a lot of industries that are not like this – we seem to be an exception.

If you tell people that it’s got good code, then people are going to believe it and roll with it.

The Varying Degrees of Quality

With that said, I think that we’re doing ourselves a disservice for a number of different reasons.

First, I think it’s important to acknowledge that there are varying degrees of quality as it relates to code. Since there’s no single write way to write code, then there’s not a single way to say something is of high quality.

We can have parts that are of high quality, parts that are of low quality, parts that just work, and so on, but we’re naturally going to be biased of our own work because it’s natural. Plus, we have a very hard time admitting to the public when we’re shipping something that isn’t well-written.

No one wants to do that.

On top of that, we only know as much as we’ve exposed ourselves to and there are always going to be people who have exposed themselves to more. There are people who are excellent at object-oriented design, there are people who are incredible at some extremely technical aspects of working with WordPress, and so on.

To some degree, it seems like we’re able to benchmark ourselves against our peers purely against what others have done. Generally, I’m not a fan of comparison, but in this regard, it does help us to gauge how far we’ve come and how far we have to go.

And there are very few instances in which I can point to someone else and say “I’m definitely better than that person.”

Generalizations like this are rarely true.

Aside from coming off as completely pretentious, it’s likely not even true. Sure, you might be more capable or skilled in an area than they are, but they are likely more skilled in an area than you are.

Code Quality Isn’t a Value Proposition

Secondly, why is it that we feel the need to communicate that one of the value propositions of what we’re selling is something that people won’t understand?

I mean, telling someone that you’re not writing bloated code and that you’re writing high quality code means no more to the typical customer than someone telling you about the quality of the materials that went into all of the components of, say, your television.

That is, only a small section of the customer base is really going to care about that (let alone be knowledgeable of the topic).

If it has a clear picture, is thin enough, and looks good in whatever room you want it, then you’re likely to purchase it. The vendor doesn’t specify if they used aluminum, plastic, or gold for some of the internal components.

The proof of the quality is in the end result of its utility.

Yet, as developers, that’s exactly what we’re doing and I question if people really care. Essentially, in our world, the vendor is telling the potential customer what a good product it is without any form of third-party validation.

Imagine any other industry doing that.

On top of that, what does it say when something doesn’t perform as expected or when something breaks or when a bug appears? What does that say about the quality of your code?

The point of all of this isn’t to critique or to drive home any particular point about whether or not we’re good programmers. That’s an entirely other post that I don’t think I’m qualified to write, but the point is that if you’re in the business of selling themes or plugins, don’t make “quality code” one of the value propositions of your work. Let its functionality vouch for that.

Instead, focus on telling the customer why what you’ve built is going to solve a problem that they have.

Code Quality Isn’t A Solution

Ultimately, I think we’d all like to be better programmers and it’s something that we’re all working towards becoming. I also think that many of us care about what it is that we’re shipping and we want others to understand the work and/or meticulous nature that went into it.

There’s nothing inherently wrong with that. It’s just not something that help most people understand how the project is going to solve whatever problem they may have. To that end, I think we can do a better job of marketing our projects than simply describing them as a trait of their internals.