The more time anyone spends with WordPress and all associated products (that is, themes, plugins, and so on), the more likely they are to also pick up on all of the commentary – both good, bad, and neutral – that surrounds the core application.
Obviously, I’m a fan of WordPress and make my living building things for it and trying to give back to the core application when I can so I know that what I’m going to say is going to come off as biased just as anyone else who writes about their preferred technology stack.
I’m well aware of the common complaints people have about the WordPress codebase and I’m not here to defend, to make statements about how it’s getting better, or to spark a discussion on how hard it is to maintain legacy features for a decade.
But if you’re a developer who is just getting into WordPress – specifically, products built on top of it – then I think that a significant portion of your first impression has to do with your experience on the first product that you use.
First Impressions Are Lasting Impressions
Let’s say that you’re an experienced programmer. It doesn’t matter if you’re familiar with procedural programming, functional programming, object-oriented programming, or whatever else.
If you’re familiar with web development – both front end and back end – and are familiar with database-backed web applications, then you’re likely familiar with the things that are in play as it relates to creating WordPress themes or plugins.
- You’ve got the templates designed to describe the data and to make calls into the application layer.
- You’ve got the application layer which is used to communicate with the presentation layer, the core application, and potentially the database.
- And you’ve got the core application that provides the APIs necessary to interface with whatever else you need out of the application.
These things are common to all web applications on some level, but it largely depends on the nature of the technology that dictates how flexible you can be.
By that, I mean that compiled languages such as .NET can have stricter enforcements on what’s allowed because the compiler can block you from doing certain things. The same can be said about the Ruby interpreter and the “convention over configuration” nature of Ruby on Rails.
Of course, this isn’t to say that PHP can’t do the same but I think it’s fair to say that it’s far more lax on certain things than other languages. But I digress.
Anyway, all that to say, building themes for WordPress isn’t all together different from anything that’s mentioned above.
So what’s with the bad wrap?
The Lower Barrier to Entry
One of the nicest things about WordPress is its low barrier to entry, but it’s double-edged sword: Those who are extremely accomplished developers can do some really neat things with it, but then those who are just getting started can end up creating things and selling them, as well.
Naturally, this is true for everyone in between.
But here’s the problem: Let’s say that you’re someone who’s just getting started in WordPress development and you’re able to get something to work and you decide to throw in n-number of options and hobble together your design which ultimately ends up being together a conglomeration of bad practices, spaghetti code, and all of the other negative terms we have with development.
For some, they don’t know any better – such is the nature of experience, right? For others, they don’t care – if it’s true that “what’s rewarded is repeated” and someone is able to turn a profit off of creating crappy products, then what’s the incentive to spend more time becoming a better developer when you continue to do the same thing and make a profit?
Bringing It Full Circle
Now let’s say that you’re a professional developer who is thinking of getting into WordPress and your first experience with a WordPress based product comes from a vendor who has spent more time churning out products in order to make a quick buck than someone who has worked hard (or works hard) to define themselves as a high-quality developer with integrity, adherence to best practices, and striving to improve their work thus far.
So what are you to think of the WordPress economy when the first impressions of the work that you see is something that looks something more like a junior developer in middle school (or high school, even) created to learn the ropes?
And then it happens again. And perhaps a third time.
What are we to think about the quality of the products that are built on top of WordPress? Obviously, it would be completely reasonable to draw a conclusion that the platform and its associated works are less than stellar, so what’s the point of pursuing this economy?
Then again, let’s say that you encounter a product – or a number of products – built by some of the more reputable developers and/or companies that are out there. And then you notice that you can do some really cool stuff with WordPress both as a publishing platform and as a foundation for web application development.
Then it’s a different story.
Take Care of Your Work
The point of all of this is that it doesn’t matter what industry it is in which you work – there are going to going to be vendors who give the industry a bad name, and then there are those who show just how advanced and of high quality things can be when they’re done right.
All of that to say: Take care of your work not only for your sake or for your customer’s sake, but for the sake of the open source community at large.
If we’re being judged by the quality of the work that we produce – and it’s absolutely clear that we are – then we need to make sure that we’re learning all we can about clean code, pragmatic programming, adhering to coding standards, and working to make sure that we’re applying all of those techniques to the work that we’re producing.
WordPress is only growing. The amount of work being produced on top of WordPress is only increasing. We can’t do anything about the low quality work, but we can show that high quality work can – and is – produced on top of the platform.