Software Engineering in WordPress, PHP, and Backend Development
In my previous post, I shared a few thoughts on how I think someone can become a better WordPress developer.
When it comes to talking with beginner – or intermediate – WordPress developers, one thing that I’ve noticed is that when you suggest the WordPress Codex as a resource, there’s beginning to be a somewhat-typical response that I’m beginning to hear:
Please don’t suggest the Codex.
Bummer, right?
Recently, I received an email from a fellow developer who had finished reading a number of series of articles on WordPress, who had watched a number of WordPress tutorial videos, and was working towards mastering WordPress.
He went on to discuss his current skill set, his aspirations, and the type of projects he eventually wanted to take on as his career progressed.
Not bad, right?
Here, you’ve got a person that knows who he is, knows where he wants to be, and is looking for advice on how to get there.
Unfortunately, there was only so much advice I could give (I’d love to master WordPress, as well!), but the bottom is line I responded with a series of things that i think he – or anyone – can do in order to become a better WordPress developer.
Up until last year, I had been happily plugging along working on various projects – both Rails based and PHP-based – and trying to put more and more stuff into open source until some of the issues what were being opened on my PHP-based projects kept mentioning something about PSR-0.
What is PSR-0?
People kept referencing it, no one linked to it, and it more-or-less an assumed standard that I, along with other PHP-developers, should know. But I’m not afraid to admit that, at the time, I’d no idea what it was.
As I see more and more activity happening around WordPress, and I see about the same amount of code documentation happening for projects – that is, not so much – I thought it’d be worth answering “What is PSR?” as well as the other three variants.
After all, I’d been working in WordPress and with PHP for years prior to hearing about it, and I still had to look it up. Perhaps that’s a problem of my own, but I’m completely okay owning that.
But hopefully this post will save someone else from having to look more deeply into it.
On March 14, 2011, I released the first version of the jQuery Konami Code as part of a project that I was finishing up. The project itself is no longer active; however, the jQuery Konami Code has been sitting in GitHub ever since.
Earlier this week, I merged the first pull request that the plugin has received (thanks to Stephen Hill!) which introduced a number of improvements.
Next, I spent some time cleaning up the demo code, cleaning up the actual project directory, and making a few other improvements with the help of JSLint.
Over the last few posts, I’ve been sharing some thoughts on why good development takes time. Of course, these are only limited to my own set of experiences, but I do think many of these are shared among developers.
In the first post, I said that we all fall into the category of a producer or a consumer, at some point, and we often want what we want sooner rather than later.
In the second post, I shared two reasons why I think good development takes time:
And in this post, I wanted to share the last three reasons for why that I think good development takes time.
Kinsta offers premium managed WordPress hosting for everyone, small or large. Powered by Google Platform and strengthened by Cloudflare, they take performance to the next level. All hosting plans include 24/7/365 support from their team of WordPress engineers. Get started with a free migration today.
© 2026 Tom McFarlin
Theme by Anders Noren — Up ↑
