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:

Has someone done this already?

Is there a simpler way? Without code?

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.

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

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.

Explain to the stuffed animal what needs to be done for this problem you’re solving.

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:

1

2

3

4

5

6

functionmyplugin_give_user_funny_name(){

// Get the current user

// If they've already been processed, we're done

// Otherwise, update their display name

// And mark them as processed

}

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:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

functionmyplugin_give_user_funny_name(){

// Get the current user

$user=wp_get_current_user();

// If they've already been processed, we're done

if(get_user_meta($user->ID,'has_funny_name',true)){

return;

}

// Otherwise, update their display name

wp_update_user(array(

'ID'=>$user->ID,

'display_name'=>"Mr. Banana ".$user->display_name

));

// And mark them as processed

add_user_meta($user->ID,'has_funny_name',true);

}

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.

This Post Has 7 Comments

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…

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?

Andy Adams

18 Dec 2014

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.

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.

Andy Adams

3 Jun 2015

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.