While this helps professional WordPress developers feel less shame about their CMS of choice, I hope we don’t forget about the “small d” developers (a term inspired by “small b blogging“). By that, I mean people who want to build with and contribute to WordPress, but don’t have years of experience with it or the opportunity to do so full time. I worry that, for them, all these new developments make developing with or contributing to WordPress unapproachable.
“Small d” developers can be easily overlooked. They probably aren’t able to attend the weekly WordPress core dev chats, nor do they have a booth at WordCamps. But serving them has been a core component of WordPress’ mission and success. To me, WordPress’ mission to “democratize publishing” doesn’t just mean to enable as many people as possible to publish what content they want, but also to enable as many people as possible to understand and contribute to the software used.
Abandoning What Got Us Here
We have been told “what got us here, won’t get us there“, axiomatically implying fundamental changes are needed to WordPress (both the software and the community) in order to progress further. But when “what got us here” served us well enough to supercharge niche software to becoming a third of the Internet, I think we need to be cautious about abandoning it.
“What got us here” has been a preoccupation with understanding real users’ problems, instead of bored developers’ imagined ones. On the other hand, “what will get us there”, complicated Node.js dependency trees, fragile new build processes, and breaks in backward compatibility, sounds a lot like the ethos of other CMSs. Ones that are losing ground, like Drupal and Joomla, despite how much “real” developers love them. “What will get is there” doesn’t seem to have a great track record, so why are we adopting it?
We Don’t Use What’s Best, We Use What’s Easy
At Church there is an expensive, complicated system for receiving video broadcasts from church headquarters, which now sits totally unused. It’s been replaced by online video streaming, which is far lower quality and less reliable, but is much easier to use. It doesn’t take any special equipment or training, and so that’s what we use.
WordPress’ success story has a similar theme: it’s never been the most well-designed CMS, it’s just been easy to install, write with, develop with, and contribute to. “Modern best practices” are removing the simplicity that made WordPress popular to begin with.
Don’t be Bullied into “Best Practices”
As a developer, you feel bad when someone mocks your work because it doesn’t conform to “modern best practices.” It’s easy to get bullied into wasting considerable time and resources to chase the ever-changing criteria of “modern”.
[M]any best practices are purely folklore. No one knows where they came from, why they started, and why they continue to be followed.It Doesn’t Have To be Crazy at Work – by Fried, Jason; Hansson and David Heinemeier Hansson
If the only reason you’re being told to change is order to “follow best practices”, don’t fall for it! You should change when there is a measurable benefit, not just theoretical promises.
For example, should a plugin change all its shortcodes into Gutenberg blocks? It’s basically a best practice now. And yes, blocks are more user friendly than shortcodes. So sure, it’s a good thing to do. But if those shortcodes are nearly never used by regular users, and making this change will delay features or big fixes users are clamoring for, maybe it should wait.
If a best practice addresses an important problem you’re actually having, then yes, it makes sense to apply. But if it has hollow promises of making things better someday, it’s delaying features or bug fixes that actually matter to your community, and it’s making your software harder to work with for real users, it sounds like one of the worst things you could do.
Are “Small d” Developers Less Intelligent?
The new technologies required to learn and use WordPress can make it harder for “small d” developers to work with. Is that because they’re less intelligent? In which case, losing their participation and contribution might almost be good, right?
My definition of “little d” developers is that they have less experience doing software development. But that also implies they have more experience elsewhere… like working with clients, actually using the software, or dealing with the myriad of other tasks involved in a successful business or organization. So, they have a breadth of knowledge that is actually vital to developing useful software.
For example, who is most likely to make the most useful blogging software? Probably not a computer scientist, but a blogger. One who knows just enough about creating software, but who has a lot of experience outside of the bits and bytes.
If the software becomes too difficult for that blogger to contribute, you’ve lost your most valuable contributor.
That’s one reason WordPress’ simplicity has been so important: it doesn’t just enable “less intelligent” people to participate, but also very intelligent people, not just full time developers, to contribute their breadth of expertise.
The Best Practice of Remembering “Small d” Developers
“Small d” developers aren’t “Small h” humans with nothing to contribute. Their expertise is just in variety of areas as opposed to one.
So what can be done to not leave “small d” developers behind, but still appease “Big D” developers craving “modern best practices?” Here are my thoughts:
- Most importantly, don’t make big decisions with only “Big D” developers present. Their needs are different from the majority. We need to continue to actively gather input from “small d” developers by publishing items for discussion before making a final decision and then being attentive to their input, and talking with them at meetups and in the forums.
Remembering “small d” developers should be a best practice. Because they’re “what got us here”, and without whom we can’t “get there.”
What do you think? Is it important to not leave “small d” developers behind? What can be done?
12 thoughts on “Are WordPress’ "Small d" Developers Getting Left Behind by “Modern Best Practices”?”
I really appreciate your take on this, Michael. And thank you for putting it out in the open.
I’m one of those “small d” developers (perhaps a “smedium d” by now, but still). The new technologies are intimidating for a classically trained HTML/CSS guy who has worked his way through the Codex frontwards & backwards to build many custom themes for clients.
Here’s to hoping we continue the conversation & find a balance.
Thanks for sharing your feelings about it Dave. Yeah, I feel pretty conflicted about it too. In no field is technology stagnant, we should expect to need to learn new stuff, especially in web development. But it’s hard to drop everything and focus solely on learning new stuff…
The thing that especially bugs me is when we spend so long learning new stuff, that something new comes along and then we spend all our time learning that! There will always be something new. The trick certainly is finding a balance.
I ran into an example of this. We released a cache purging plugin https://github.com/spiritedmedia/redis-full-page-cache-purger It has an external dependency (predis.php). Another developer suggested we use Composer to manage that single dependency. I opted to include it as is so people could just download the plugin and use it without having to mess with a composer update command. Practicality trump theoretical.
Thank you for that Russell. Yeah, once you’ve setup composer in your environment, and know how to work around the errors you get, it’s pretty nice. But I’m sure many of your plugin’s users haven’t done that, and if that were a requirement, would probably first try another plugin that *doens’t* have that requirement.
Thanks for speaking up on this, Michael. I’m one of those who, faced with the outrageous tooling overhead of Drupal 8, decided it was time to move to WordPress instead. I hope it doesn’t now go the same way. Tooling infrastructure has its place for complex sites and big teams, but not necessarily for the small d developer.
Interesting Tim! Thanks for sharing your experience. Admittedly it’s been about a decade since I dabbled with Drupal.
I had a somewhat similar experience with using Java, and its dependency injection framework Spring, its package dependency manager Maven, etc. Dealing with “dependency hell” (see https://en.wikipedia.org/wiki/Dependency_hell) was my daily routine. I found working with PHP such a breeze, in comparison. But now PHP is starting to look more and more like Java from 10 years ago. It makes me worry something else new, simpler, will come along and beat PHP once it’s gotten too complicated too.