When I decided that I was going to commit the journey of my career to building solutions on WordPress, I was – at the time – all in. That is to say that HTML, CSS, JavaScript, PHP, and MySQL were at a place where I could stay involved with all of them and work competently down the stack as needed for whatever it is I was building.

But as both my family [and I] have grown and as WordPress has changed over the past half-decade (let alone decade), that entire perspective has changed.

Not just that, though.

HTML has changed, CSS has changed, JavaScript has changed (in other words, the entire front-end has changed), PHP is evolving (largely for the better, in my opinion), and working with various database technologies beyond MySQL but also APIs, other data sources, GraphQL, and so on is becoming a larger task.

Some time ago, I wasn’t sure I liked that. I liked knowing all the ins-and-outs of all the various parts of the foundation on which I was working. I’m not saying we should ignore all but some parts of application, but it’s at a point now where I think it’s worth knowing where you want to focus your efforts for the sake of making sure you can solve the problem, or help solve the problem, in the best possible way.

  • If you’re a solid React developer, then you know where your efforts are best focused.
  • If you’re interested in PHP and object-oriented and/or procedural programming, the the back-end is the place to be.
  • If accessibility is something you’re passionate about, then there’s a place for that in WordPress, too.
  • And this is but three examples.

The point I’m trying to make, if anything, is this: If you’re worried that it’s too hard to keep up with the various parts of WordPress, don’t. Instead, focus on the parts with which you enjoy working and then focus much of your time and effort on becoming the best possible developer you can for that area.

Conversely, do I want to get better with React? Yes, that’d be nice. But is it the most important thing to me or to my career at this point? No.

In software development, we talk a lot about must-haves and nice-to-haves. And if we’re going to talk about it externally with regard to our customers, why not do the same it internally with respect to our own skillset?

I still contend, in this context, it’s better to know a lot about something that a little about a lot.