WordPress developers: How to write less code & get more done

If you’re a WordPress developer, you’ve probably experienced this before:

You’ve spent lots of time on a plugin. You’ve polished and perfected it. It’s finally ready to show the world.

But first, you show it to a colleague for “review”. Truthfully, you’re just waiting for them to start crying tears of joy when they see your work of art. Their first words:

“Hey, cool. That looks like $plugin_xyz.”

Wait, what?! You frantically open a browser window and google $plugin_xyz. It can’t be…

Ah, crap. It is.

The Exact. Same. Thing.

…except $plugin_xyz is more polished *and* has more features than yours.

The horror sinks in: You’ve spent hours, or days, or weeks reinventing the wheel.

It’s not entirely your fault. You write code for a living. When someone describes a problem to you, snippets of PHP start dancing in your head. Code is comforting.

But some problems don’t need code; instead, they need a bit of contemplation. Before you start coding, do you ask:

  1. Has someone done this already?
  2. Is there a simpler way? Without code?
  3. What are the potential conflicts/maintenance costs of coding this yourself?

#3 is particularly important for WordPress. There are 34,000+ plugins and 2,800+ themes on the WordPress.org repo. There are bazillions of premium plugins and themes.

And your code needs to place nice with all of it.

Despite believing (with my whole heart) that I need to think before I code, I’ve had to relearn this lesson many times, often in painful ways.

One of the biggest leaps in my career came when I realized that the best solutions were often those that involved the smallest amount of code. I wish someone had told me this when I was fresh out of college. I was a regular cowboy coder.

I’d love to show you how to avoid my mistakes. But first, a story.

I wrote some code, and it stunk

This story is hard for me to tell. To be frank, it’s embarrassing.

Early in my freelancing career, my friend Geoff contracted me to develop a plugin that changed the way WP category pages appeared. Simple, right?

We agreed on a price, had a brief talk about the functionality, and I set off coding it.

Without getting into details, let me say that modifying templates via a plugin is tricky. But I was clever. And I could hack like nobody’s business.

Using output buffering and some WP coding magic, I had it working.

Working…except for certain themes. When you used certain themes, it was broken.

Oh, and except for certain plugins. If you installed those (free, widely used) plugins, it broke my plugin, too.

Not to worry. I’m a coder.

I hacked on a few more conditionals, even getting to the point of checking for a specific theme to handle the bugs my plugin caused. When I look at that line of code, I get a sinking feeling in my stomach. Take it away. It’s horrible!

What should I have done differently?

First, I should have paused a moment before I started hacking. I should have thought about the repercussions of doing a complicated output-buffering technique.

I should have thought about the platform I was building on. WordPress: Where users routinely install multiple plugins that modify the content I was trying to control.

In short, I should have gone a simpler route. Instead of coding it myself, I should have:

  • Written instructions for modifying a theme to use the plugin.
  • Done more research on how others solve this problem.
  • Explained to my client (and friend) that what he wants isn’t possible.

Any of the above would have been better than hacking out the buggy mess I did.

WordPress requires special attention

The WordPress ecosystem is huge. Your code needs to play nicely with plugins and themes that:

  • You didn’t write
  • Are installed by average, non-techy people
  • Are changing the same variables and content you are

You don’t have these problems on other platforms. For example: You don’t have to consider whether someone will install unwanted gems on your Rails app. There’s no interface for that.

What do we do about it?

There’s not a prebuilt solution for every problem. Sometimes you need to code. But you can try a few things to stop yourself from writing excess code.

What follows are some simple tips for overcoming your “code first” habit. FYI, I’m still figuring this out. These are my feeble suggestions.

Tip 1: Reframe your job

From this day forward, you’re not a programmer. You’re a problem solver.

[pause for effect]

Did you feel that? You were just catapulted into the top 20% of programmers, ranked by “getting things done”.

The truth is most programmers enjoy coding so much, they’d prefer to keep coding even if they’re reinventing the wheel or creating more work for themselves.

That’s fine. You don’t want to take their joy away from them – seriously! You just need to focus on getting results and solving problems, even when you don’t get to code them yourself.

Speaking about yourself…

Tip 2: Talk to yourself

Have you talked to yourself lately? I recommend it. If you’re not sure about how to solve a problem, fight the code-first instinct and bounce your ideas off…yourself.

I talk myself out of complex solutions all the time. Often, I talk out loud. You may have heard of rubber duck debugging. I use it for planning, as well. Here’s how it works:

Here's what you'll need
Here’s what you’ll need
  1. Grab the first stuffed animal you find. In my house, the odds are it’s a Curious George doll. Yes, it belongs to my kids.
  2. Explain to the stuffed animal what needs to be done for this problem you’re solving.
  3. Have the stuffed animal ask you questions that a non-programmer would ask.

Me: “So Pajama George, I need to flush the cache before a CPT is published.”

George: “Oooo, why do you need to do that?”

Me: “Come to think of it, you’re right! The CPT doesn’t affect the cache, after all. I was confused. Thanks, George!”

It helps that George is actually curious, but I’ll talk to anybody who will listen.

Benefits of talking to yourself include:

  • You’re forced to put the problem into words
  • You’re allowed to ask “stupid” questions (with the help of your stuffed friend)
  • You can discover nuances and angles you wouldn’t have considered otherwise

If you work remotely, this can also improve your social skills. In a talk-to-puppets kind of way.

Tip 3: Comment your way to a solution

One of my favorite practices is writing my entire solution in comments, in natural language. A snippet helps illustrate what I mean. Here’s what a function looks like before I code it:

This has many of the same benefits as talking to yourself, but also yields some extra pluses: simplicity and documentation.

Simplicity because natural language guides you towards simple, understandable solutions. If you can’t explain it in words, you probably shouldn’t explain it in code.

Documentation is a byproduct of commenting first. Here’s what that function looks like, completed:

Note that the comments didn’t specify the implementation. I decided to use user_meta, but that’s only one way to solve the problem.

Let’s simplify: Put this into practice

We’ve covered a lot. My hope is that by now, you’re a problem solver. You recognize that every line of code you write has a cost, and you need to weigh that cost before you start coding. This is especially true with WordPress, due to the vast amount of other people’s code your code may come in contact with.

When you start solving your next problem, I’d love for you to try one of the techniques above. Talk to yourself. Convince yourself you don’t need to program it yourself.

If you can’t talk yourself out of it, try writing some comments.

In short: Slow down. Just a tiny bit. You’d be surprised how much you get done.

Questions or comments? Hit me up on Twitter or Hacker News!

Freelancer? Me too!

Join my newsletter and I'll send you some emails about the business of freelancing and software, for free.

I won't send you spam. Unsubscribe at any time. Powered by ConvertKit

This Post Has 7 Comments

  1. This is true! I think this happens a lot for complex projects too where you’re so used to everything being a mission to build that you just assume from the start that there’s a lengthy solution to the problem. And then you have that moment when you’ve thankfully talked to someone else and they point out – hey, why don’t you just do XYZ instead of coding this entire crazy thing you were planning? And it just totally didn’t hit you until then.

    I also like the comments idea. It helps to sort of arrange the logic in a function too. My college professor once told me, if you can’t explain it, then you don’t really understand it. Besides, comments are good for documentation and for future you who looks at this function a year from now at 3 in the morning and don’t remember what the heck anything does! Uncommented code makes me sad…

    Anyway, thanks for insightful article! 🙂

  2. I liked the blog. However in the end i was not convinced at all.
    Considering the amount of libraries and plugins out there you can’t afford to behave a problem solver instead of coder. You will end up a user of libraries and all your coding will be mere some loops and flow control. No?

    1. My thought is: If you can find libraries to do it, and it saves you time…why not? There will always be more programming to do.

  3. I’ve seen and done the “commenting you way to a solution” for a while now; I actually picked it up from the guy on Destroy All Software screencasts.

    Really helpful to describe the problem in english, maybe jot down some pseudo-logic, and work my way through those steps.

  4. This was a good read.

    I will definitely try commenting out my code before I actually start coding.

    I do have a thought, though, and please critique my logic here:

    I’ve been working on a Video portfolio design for a client. I COULD have just hopped over to Code Canyon or used another plugin to create the entire CPT, and galleries but I opted to code it myself to ensure that things were kept lean and mean.

    I created the CPT. Created a few new page templates with some custom loops. The rest was just styling.

    The thing is, I didn’t need 10 different gallery styles. I just needed one. So why bog down the site with so much unnecessary code?

    Let’s assume any plugin I chose would be well coded. Am I wrong in thinking extra code and features impacts a site’s performance enough to avoid using it? Or should I only opt to do it myself if I can’t find the style I want in an existing plugin?

    I’m all for avoiding wheel reinventing, and welcome insight here.

    1. That’s a tough call. If the plugin does 100% of what you need, I would probably buy it, use it, and if – only if – there were performance or “cruft” problems, I would see what I could do to remove/disable those pieces of the plugin – preferably through unhooking the filters and actions I don’t need.

      There’s a lot of nuance that I can’t capture very well! Hope that helps a smidgen.

  5. That does help, yes. Altering the plugin could be a good option sometimes. I hadn’t thought of that.


Leave a Reply

Close Menu