Software Engineering in Web Development, Backend Services, and More
A couple of weeks ago, I had the pleasure of being a guest on the The Dispatch podcast with Chase Livingston, and Automattician, and Chase Clemens, a support tech at Basecamp, in which I talked about my experience with WordPress – from how to I got to started to what I’m doing now.
You can check out the original post and the actual podcast here.
One of the things that developers love to discuss is the tools that we use. And why not, right? It’s fun to talk about what IDEs, minifiers, compressors, build tools, deployment utilities, and so on that we incorporate into our daily workflow.
It’s also fun to see what other people use to see if there isn’t something to be learned and gained from the way that other people do work.
But sometimes I think that we do cross a line: I think that many of us have a disposition such that we think “if they aren’t using what I’m using then they aren’t being as productive (read: they are as proficient) as I am.”
And this mentality is lame primarily because there are a number of factors that contribute to the tools that a developer opts to use when he or she is getting his or her work done.
Regardless of your level of experience with WordPress, everyone is familiar with seeing the messages that display whenever an action has completed within the dashboard:
For anyone that’s read past articles, you know that when it comes to introducing functionality into the WordPress dashboard, I firmly believe that the work we do should look as native as possible. That is to say that I am not a fan of custom styles, custom controls, or extraordinary styles to give your theme or plugin that “extra edge.”
And for those who are familiar with the Settings API and/or the Options API, then you’re likely familiar with introducing new sections, settings, controls, and options, but what about error messages?
Generally speaking, success messages and notification messages are reasonably easy to come by, but let’s say that you need to validate some piece of information that’s coming into the server and return an error if it fails.
Maybe it’s just me, but one of the things about programming is that many of us pre-occupy ourselves with is the need to find the right way to do something. Contrast this with the mindset of “I just want to get it working” and you’ll know what I’m talking about.
Basically, it’s never good enough just to get something working.
Of course, there are exceptions: creating prototypes, working on a small demo to show someone how something may work, and so on.
But when you’re working on a professional grade product, there’s a number of things that go into getting things to work – anything from the design of the product architecture through how the various functions, modules, or pieces of code are going to interact with one another.
Let’s say that you’re working on a plugin that has its own plugin settings page, and on that page there are options to determine what type of posts will support part of the functionality of the plugin.
For example, let’s say this plugin will be introducing a meta box for each post type that extends the type of information that the user can add to a post. The settings page allows you to control which post types will offer this information.
To give a concrete example, take a look at the following screenshot:
Granted, it’s a small example but it makes the point: We have a plugin settings page that displays all of the post types that are in the current theme installation. If selected, we’ll save the values to an options array.
When it comes time to read the values, there are a couple of ways to go about doing it, but one that’s arguably simpler than all of the rest.
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 ↑