Are WordPress’ "Small d" Developers Getting Left Behind by “Modern Best Practices”?

5 minute read

After years of being derided as not being with the times, WordPress’ code and community is experiencing a cultural shift in adopting “modern best practices.” Examples of this are the emphasis on Javascript (and especially the React framework), introducing a build process, and increasing the required minimum version of PHP.

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:

• Don’t force WordPress developers to learn current JavaScript development overnight (Gutenberg block’s server-side render is a good effort towards this).
• Help WordPress developers learn modern JavaScript. Yes, they can search the Internet for React, Node, NPM, webpack, lodash, babel, jest, and all the rest of the new JavaScript dependencies by themselves. But deciphering how all those moving pieces work together, and how WordPress uses them, is a mess they could use help with.
• Don’t require everyone who wants to run WordPress’ development version to run the new build process. There were recent efforts that required you to run the build process less often, but we could take that a step further by committing the built files into the repository (while unconventional, at Event Espresso we’ve done this by committing our built JavaScript to our GitHub repository, so even though we use a build process, you don’t need to do any of it to try out our latest work).
• 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?