In the previous post, I shared a few thoughts on the challenges of setting a WordPress developer salary. When I began writing out my opinion, I ended up writing a lot more than I had intended, so in order to keep posts at a shorter length (thus saving all of us time 🙂 and sounding less monotonous, I’ve broken everything up into a handful of posts that I’m basically running as a series.

Yesterday, I laid it all out in that I shared three reasons as to why I think WordPress developer salaries are lower than that of the average software developer. There were some really good, thoughtful comments on the post, too.

And the whole point of doing that was to lay out a high-level view of my opinions before looking at the topic in more detail.

As much as I want to talk about more technical matters of WordPress, I think it’s worth noting that one reason that a WordPress developer salary is hard to set is that many still see WordPress as a content management system, if not just another blogging platform.

WordPress Developer Salary: Just Content Management

As I mentioned in the previous post, I think that the challenge with trying to nail down what a WordPress developer salary should be has a lot to do with understanding what WordPress is, what it’s capable of, and what a person is capable of doing with it.

Sure, there are other things to consider – which I’ll mention later – but understanding what the core application actually does and is capable of doing plays a major role.

But that’s where part – and arguably the biggest part – of the problem is.

I believe most people still see WordPress as a blogging platform (and that’s fine!). Even those of us who build other things for it and with it still use it for exactly that, right? I mean, isn’t this a case in point? We even use WordPress to blog about WordPress and/or our WordPress-based companies.

How meta of us.

WordPress Developer Salary: It's All Content

Meta Joker is Meta

But seriously, we all know that it’s matured into what’s typically better known as a content management system. And that’s fantastic. WordPress has grown up on us in a lot of ways (and continues to do so).

For those who have built more sophisticated systems with it, it’s obvious. For others, it looks like a blogging platform that offers more options than the usual CMS, doesn’t it?

Wait, though – what’s content management, anyway? What constitutes “content” and how far do we actually go when “managing” it? Ask 50 different people about content management – those technically inclined, and those not – and see what kind of answers you get.

But It Is More Than That

On top of that, those of us who are familiar with the WordPress APIs and what can be done with WordPress know that it’s far more than a CMS. It can be used as a foundation on which to build web applications.

To that end, one of the biggest problems that plagues WordPress developers (and designers, I’d venture to say) is not so much what can and can’t be done with it, but it’s how it’s perceived by the industry.

For many:

  • The idea of building an application with an application sounds weird (and not like something professional developers would do),
  • It’s not something that you use to build enterprise and/or scalable applications,
  • There are what are believed to be far more advanced (and expensive!) languages and tools to build the solutions that need to be built.

Whether or not any of the above are true is irrelevant for the point of this discussion. That could be a post all on its own, though I don’t currently plan to chat about that.

I think it simply goes back to a problem of perception and understanding of the core application. Part of this has to do with how WordPress is marketed, part of it has to do with the fact that it has a primary purpose as a way to publish content, and part of it has to do with the fact that it’s not targeting the developer niche like programming languages, libraries, and frameworks do simply by their nature of being. To be fair, though, WordPress is meant to be marketed towards programmers.

With that said, I don’t think the problem is one-sided.

So, What About These Developer-Types?

If someone was to look at WordPress as a viable option as a platform (not a framework) 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 degree of certainty – some comes from education, some comes from experience.

But if a WordPress developer is someone who is technically proficient with using an application, then we’re looking at an entirely different type of person. There’s nothing wrong with that, of course, but I don’t think those types of people should be labeled as developers, nor do I think that those looking to hire someone with a background in software development should skip out on evaluating the technical experience of a candidate.

And that’s the other side of the problem: The people who are labeling themselves as WordPress developers and are then being hired by those who know WordPress can be used as a more than a content management system end up finding themselves faced with problems that are more typically related to a software development role – not a content management role.

Perhaps there have been times where the opposite has happened: Someone applied for a development position that utilizes WordPress  and ended up finding that it was actually a role that was more content management than writing code.

Ultimately, I think that the problem can be partially attributed to how those who are doing the hiring view WordPress and the applicant pool, and those people in the applicant pool are labeling themselves.

Regardless, that’s getting into the core issue of the next post.

Share:

Leave a Reply