Over the last couple of posts, I’ve been talking about the various things that contribute to WordPress developers having lower salaries than other traditional software developers. Specifically, I’ve talked about:
- Three reasons I think salaries are lower,
- And how the industry, applicant pool, and skill set play a role
To be clear (and as pointed out in the comments), this isn’t the case everywhere, but it’s apparently a common enough trend such that peers in the industry are noticing it, and it’s struck a chord with others to, ahem, write about it, and to continue a talking about it a little more in-depth.
Anyway, one of the things that’s undeniable is that WordPress can’t be compared directly to frameworks like Rails and .NET, libraries like jQuery, or straight up languages because it’s none of those things. In and of itself, WordPress is an application that can be installed on a web server and can be used for digital publishing.
It just so happens that it has a powerful API that allows it not only to be extended, but for other applications to be built upon it.
Software Development With WordPress?
Yes. It can be done and I know people who are far smarter and accomplished than I who have done it, and do so on a daily basis. They’re my heroes:
But seriously.
Ultimately, WordPress provides a foundation – not a framework – on which applications can be built. Yes, it can be extended through plugins (and plugins via extensions), but that’s not the point of this post.
Instead, the point I’m trying to make is that it provides a lot of code and functionality that’s common place among web applications.
That is:
- User accounts, roles, capabilities, and management
- Custom Post Types that can be viewed as a hybrid of a model and a view
- Custom Taxonomies for categorizing or tagging information in the data model
- A built-in email system (along with complete APIs)
- The ability to define custom URL routes
- A relatively small number of database tables flexible enough to store a variety of information
- …and much more.
Obviously, I’m painting with broad strokes here, but you get the point: When you look at web applications in the general sense, many of them consist of the same functionality – at a high level – all of which WordPress contains and that can be leveraged through its API.
Furthermore, these APIs can be further extended, modified, changed, or even removed based on the hook system that the core application provides.
And as nice as fun as all of this is to talk about, this still doesn’t get us any closer to why WordPress developer salaries are set at a lower point than other traditional software developers. And though I’ve mentioned it in a previous post already, I think it’s worth reiterating that not only is “WordPress development” an umbrella term, but those who have no experience with classical software development can assemble – or implement – solutions with WordPress without writing any code or being familiar with any of the standard software development terminology, processes, and so on.
And if the site hums along, then people are none the wiser about what’s going on under the good.
Perhaps it’ll take a beating (“Hear me baby, hold together.”)
That isn’t to say that that’s a bad thing – after all, we all have different skill sets and people need different types of solutions – but if you’re going to be paying a WordPress developer a salary, then it’s reasonable to assume that it’s on par with the type work that they are doing.
This, of course, is based on if they are a content manager, developer, implementer, and more (all of which I’ll talk about later).
But first, what does a software developer look like and how does it stack up in the context of WordPress?
The Skills of a Software Developer
If someone was to look at WordPress as a viable option for building software, and then attempt to grab someone from the pool of applicants, there are a number of things that professional software developers are assumed to know with a certain degree of certainty.
They are givens, more or less. And – as mentioned – those who work with WordPress may not actually know what some (or any) of these are.
For example:
- Source control
- Unit testing
- N-tier applications
- Database Abstraction, Business / Application, and Presentation Layers
- Design Patterns
- Continuous integration
- Development, Staging, and Production Environments
- Breakpoints, Step Through, Step Over, Step Into, etc.
- …and so on and o and on
This isn’t to say that this can’t be taught. After all, anyone who has a career in software development likely knows the majority of the above (likely more, even), but didn’t know it at one time. I’m not even saying that these are things required to be a successful WordPress developer (though I do think they contribute to being a successful software developer).
Personally, I think some of the above can go a long way in increasing your skill set, marketability, overall quality of your work, and all that fun stuff, but they aren’t requirements if you’re looking to be someone who primarily works with managing WordPress installations or implementing solutions (which I’ll talk more about later).
But the blessing and the curse of WordPress is its low barrier to entry.
That is, it’s relatively easy to get a site up and running with a WordPress installation, a theme, a few plugins, and an FTP client. After that, it’s a matter of populating the site with content which is easy to do via the WordPress dashboard.
Now, this is not saying that not knowing any of the above can prevent someone from making a career out of WordPress. People are doing it daily and that’s fantastic. But what I am saying is that if you’re looking to be paid a typical salary while doing software development with WordPress, it requires a level of experience and a method of thinking that exists among a wide, wide variety of others in this industry.
So what do we do about significantly more complex solutions where there’s a unique problem domain and Posts, Pages, and Categories don’t fit the bill?
What happens then?
Overused, Meaningless Terminology Hurts
One of the problems that we face is that the term “developer” is so overused that it practically has no meaning.
If you ask someone what they do for a living, and they say they are a developer, that answer may be fine for a non-technical person, but for many of us we then ask “Ah neat, what kind?” Then you get into frontend, backend, database, JavaScript, PHP, .NET, Ruby, C, C++, Laravel, and so on and so on and so on forever because there are too many languages and tools for people to know them all at this point.
You have to qualify the type of developer you are. So this raises the question: If someone says they are a WordPress developer, what comes to mind?
For many – and this is just a guess – I’d venture to say that people in the industry – again, who have a vague understanding of what WordPress is truly capable of – may assume that you’re capable of converting designs into themes, and/or you’re capable of extending the platform through plugins and widgets.
But if you’re someone who’s been involved with the application in some level for several years, then I’d venture to say there are additional things that can contribute to you being more skilled than a peer:
- If you’re familiar with the WordPress Coding Standards, that’s a plus.
- If you’ve built you’re own theme and/or plugin, that’s another plus.
- If you’ve contributed to WordPress Core, that’s yet another plus.
- If you’ve written and maintained a WordPress project by triaging tickets, managing scope, and so on, yet another plus.
- …and you get the idea
But what if you tell someone you’ve built a web application using WordPress as a foundation in which you created a custom dashboard and public-facing user interface while also hooking into the core APIs not only in order to take advantage of some of the built in features of WordPress, but also to make sure the core application is compatible with upgrades to the foundation on which it sits, and so that it can be extended through the built-in plugin APIs.
On top of that, you have reasonable unit test coverage using both PHPUnit and perhaps even frontend testing with something like Selenium and you’re hooked up your entire commit processes to a continuous integration application that runs deployments to your staging environment so you can see how it stacks up in an actual environment.
Now we’re getting into significantly deeper waters, right?
So Are We Getting Somewhere?
And here’s a completely honest question (that is, I’m genuinely interested in a response – this isn’t a loaded in any way:
How many software development professionals know that that can even be done, let alone understand the event-driven model that powers the WordPress hook system?
As an side, I’d venture to say that this pattern is probably viewed as antiquated by many developers because of MVC and MVVM and all of the other M* frameworks that have been been on the rise as of late the despite the fact that they’re patterns that have been present along side the event-driven model in the very same design pattern books for decades).
But I digress.
Anyway, I’m hoping that the general points and examples outlined above provide a bit of an understanding as to what a software developer can do within the context of WordPress, though I’ve likely missed some of the finer points.
Still, the general idea remains: This is how software development with WordPress can be achieved, and why salaries don’t necessarily need to be lower when the person you’re hiring is going to be working with these approaches, tools, methodologies, and so on.
Of course, that’s just my take. As usual, I’m interested in yours.
Leave a Reply
You must be logged in to post a comment.