Takeaways from interviewing 13 great WordPress developers

Editor’s note: this is a guest post by Fred Meyer of WP Shout. WP Shout is a really solid WordPress tutorial blog by Fred and David Hayes. Up and Running is an excellent guide for leveling up your WordPress development skills, and this post walks through some of the takeaways they had during the process of creating the guide.

As part of our e-book package on WordPress development, Up and Running, my partner David and I recently interviewed thirteen of the world’s best WordPress developers:

In addition to live code walkthroughs, the interviews included a series of questions about WordPress development:

1. What does well-written WordPress code mean to you?
2. What tools do you find most useful in your work in WordPress?
3. What advice do you have for people learning WordPress development?

In this article, I’ll summarize some of my own key takeaways from these interviews. (You can also see a related slide deck at WPShout.)

It’s About Clarity

“To me, good code is code that you can understand, and that you can work with, and iterate upon without serious pain.” -Helen Hou-Sandí

Virtually all of the advice we got about code related to its clarity—although the specific term “clarity” generally wasn’t used. Helen Hou-Sandí‘s answer succinctly summed up the overall attitude: “To me, good code is code that you can understand, and that you can work with, and iterate upon without serious pain.”

This breaks down into the following general categories:

Readable

As Pippin Williamson said, “Another developer who’s not familiar with the codebase should be able to jump in and understand what’s going on.” Jenny Wong said, “If you look at a line of code and don’t understand what’s going on straightaway, it’s not well-written.”

Well-Formatted and Well-Documented

Many interviewees advocated documentation as a way to make code’s nature and purpose clear to future readers. Those future readers could be other people, or the author herself a few weeks down the road: as Carrie Dils said, “Documentation is like my past self was thinking about my future self.”

A few interviewees discussed formatting and documentation as something correlated with good code: in other words, good coders are also the people who are careful and thoughtful enough to put work into formatting and documenting the code they right. Curtis McHale said, “One of the things I look for is documentation. If they’re taking the time to document it, it’s at least a certain level of quality typically.”

Pippin: “It’s no coincidence that most good and great developers take time to format their code nicely.”

Extensible

The need for code to be clear enough to improve came up very often. Daniel Espinoza put this as follows: “Code has to work for the next guy or next gal. If the code works, and then somebody can take it and run the next mile with it, then that’s good code.”

How to Write Clear Code

Our interviewees gave some very concrete advice—and some more general principles to follow—for writing clear WordPress code.

Know Exactly What You’re Doing and Why

The foundation of writing clear code is that you understand exactly what it does, how it works, all the side effects it might have, and why you decided to architect it that way.

Curtis recommends mentally telling yourself “This function should do…” before every function you write, and then writing that exact phrase into the documentation before the function. He does this before every function he writes: then, “if I start diving deeper into the function—’Oh, it does six other things too’—then I start breaking it out.”

The opposite of clarity in coding is to hack around until something seems to fit your immediate need, and stop there. Daniel Bachhuber said this really well: “Do you figure out something that just works, and not really understand why it works? That’s going to cause problems later.” Or, as Helen said, “Stay curious and critical about what you’re doing. Don’t just lie back in your pool of copy-pastes and snippets.”

Short Functions and Methods

Pippin recommends that you “break your code up into as small chunks as possible”; in particular, “a function should do one thing, and one thing only.” Curtis has a related rule of thumb: “If a function is longer than 6 to 10 lines it’s probably doing too many things inside it”—since a single responsibility usually doesn’t take more than that to execute.

Clear Function and Variable Names

Some interviewees preferred that code not be extensively commented, but that it instead be self-documenting. As Mika Epstein said, an example of self-documenting code is “when you give a function a really good name so that everybody knows, ‘This function is for this action.'”

Daniel Bachhuber said, “On a line-to-line basis, if you have to have a comment that explains what’s going on, your code isn’t readable, or your comment is redundant.”

It’s Not About Having the Coolest Tools (Technical or Conceptual)

Most of our interviewees used some similar tools for development:

• PHPStorm, Sublime Text, or Coda as their text editor or IDE
• Varying Vagrant Vagrants (VVV) or MAMP as their local development environment
• Git and GitHub for version control (and Subversion for version control for WordPress.org projects)

Many also used Grunt as a task runner, and iTerm 2 (Macs only) for the command line. Several interviewees also recommended Sass, the CSS preprocessor, for front-end development.

For programming practices, most code we looked at was object-oriented, and auto-generated docblocks for documentation (often through PHPStorm) came up several times.

However, what kept emerging was that these choices don’t matter too much. For example, Brian Krogsgard mentioned using Coda (rather than Sublime Text or PHPStorm) “for no reason at all.” Similarly, Pippin relies on only three tools: “Terminal, a code editor, and a WordPress install.” That way, he says, “If I lose my computer, I can be back up and running within 30 minutes.”

For programming, the consensus was that code should have the properties described in “It’s About Clarity.” Very little else—such as the choice between OOP and procedural code—actually matters. The most unanimous piece of technical advice was simply, “Follow the WordPress coding standards”: a practice for clarity and readability, rather than a specific prescription for how to reason about code.

What Set Our Interviewees Apart

I also looked for similarities between the people we interviewed. Here’s what I found:

Confidence

The interviewees almost all shared a lack of intimidation, even when they didn’t know how to do something or hadn’t faced a challenge before. Some common “tones” in their shared attitude were:

“I Can Do This”

A lot of our interviewees committed to learning under pressure—specifically, learning on the job. Sean said, “The best teacher for me has been freelance development.” Brian loved the slogan, “Just build websites!” originally coined by Chris Coyier, and advised WordPress learners simply to “Find someone that needs a website and build it for them; learn what you need to do to build that website.”

Pippin used to do exactly this:

“When I did client work, sometimes they would ask for custom functionality, and the first thought that went through my head is, ‘I have no idea how I’m going to do this!’ And then the response is, ‘Sure, that’ll be X number of dollars extra to do that.’ And then once they say yes, you go figure out how the heck to do that. It does put you into a state where you say, ‘I’m going to solve this, because somebody is paying me money to solve this, and they’re expecting a product to be delivered,’ and so you don’t give up.”

“I Can Learn This”

All interviewees saw knowledge as attainable, not out of reach, and worked to regularly push themselves past the boundaries of their own knowledge. As Daniel Bachhuber said, “If you’re always doing easy things, you’re not going to develop as a developer; you’ve got to always be pushing yourself to learn more, and do more, and get stuck more, and get unstuck.”

For Pippin, this quality does a lot to predict the success of someone’s career as a developer: “If someone gives you a task, and you say ‘Okay, let’s figure out how to solve it,’ you’re going to do really really well. If you look at a challenge and say ‘Oh, I don’t know how to do this’ and just quit, then you’re not going to go far.”

“Let’s See What Happens”

As Helen said, “There’s a lot of value in just trying new things: being really curious about, ‘What will happen if I do X thing?'” Helen also mentioned reading the WordPress code responsible for function calls like update_post_meta()—and how doing so has helped her avoid redundant is_revision() checks that she commonly sees in copy-pasted code.

Sean Davis mentioned finding a typo in the style.css file of the Underscores (_s) starter theme, and deciding to submit a pull request for a fix: “Once my pull request was submitted and merged, that’s when I started looking at everybody’s public repos: ‘Now I’m curious. What else can I do?'” Fixing a number of other GitHub projects gave Sean the understanding, “I can talk to these people. I have value as a WordPress developer,” and eventully led to his being an early hire at Easy Digital Downloads.

Brian also got his first job in WordPress “by pointing to a few personal websites that I’d built for myself,” as well as some blog articles on WordPress, “in order to say, ‘I’m passionate about WordPress, I know WordPress, I’m a completely inexperienced programmer. Will you give me a job?’ And they did.”

Similarly, Mika described the mentality that got her started writing plugins: “I have a problem, no one else is fixing it; I’m annoyed enough and I’m smart enough that I’m going to try to do it.”

On Intelligence

Most of our interviewees were conspicuously smart. But that intelligence seemed mostly to be a source of confidence, more than something that enabled them to write code that no one else could have written. As Mika said, “If you can understand the concept of algebra—how to find X—you can troubleshoot any WordPress problem.”

Connection and Involvement

I was surprised, throughout our interviews, by how important the social aspect of WordPress development was for every interviewee. They overwhelmingly saw code itself as a social activity: the most-mentioned metric of good code was how well others could read, understand, and extend it.

More than that, each person we interviewed was deeply networked with other WordPress developers. Curtis, for example, is part of a regular Slack channel chat with what seemed like every prominent developer in WordPress. The group regularly exchanges technical knowledge: “I can ask questions and usually get an answer within twenty minutes.”

This didn’t happen by accident, but “came after years of cultivating relationships with them—contributing to their projects and continuing to try to be helpful to them.” After consistently offering value and developing those relationships, “Now it’s an easy exchange of information.”

What to Learn from Interviewees’ Example

This section discusses what I think we can learn from these developers’ example.

Confidence

More than any other trait, confidence was what allowed our interviewees to continue learning and growing in WordPress. Based on their suggestions, here are a few main ideas for developing confidence in yourself as a WordPress developer.

Overcome Impostor Syndrome by Offering Value

In a technical setting, knowledge is the main social currency—and so one of the scariest things is to expose your own ignorance. The seeming need to know everything can quickly drive you into “impostor syndrome”: the sense that you secretly don’t belong in a given room, job, or conversation.

The cure for this is open communication: having people whom you can ask real questions without needing to keep your guard up. How can you develop those relationshps? By offering value.

For example, if you’re trying to contribute to someone’s GitHub project, and you hit a function you don’t understand, the author will almost certainly be happy to walk you through it—after all, you’re trying to help.

This is a big contrast to writing the author out of the blue when you get stuck on a client project. In this second case, you may never get a response: you’re just asking for free knowledge, for your own paid ends. Getting stuck like this with no help is a great way to deepen one’s sense of being a solitary impostor.

So work to deliver a lot of value up-front, in order to develop technical friendships marked by (to again use Curtis’s phrase) “an easy exchange of information.” This will be a great source of confidence—you can simply let your guard down and learn—and will do a lot to remove impostor syndrome and self-criticism as impediments to your learning.

Develop Independence and Thick Skin

Interviewees also mentioned not allowing themselves to be intimidated—or even bullied—by others, online and in-person. For Tom McFarlin, it’s important to “learn to listen to the input other people give you” online—for example, via Twitter or GitHub—”even if they come off as negative”: “you have to get a thicker skin, if you’re going to be online talking about stuff.”

Sean discussed the importance of having “your own identity” in WordPress, and not being bullied into learning trendy programming practices when it may not be the right time for you to learn them. Similarly, Helen finds that “feeling better about what you’re doing through elitism” by creating “boundaries and hurdles to becoming an expert” is “anti- what the web has been about for so long: about opening doors to people.” So if you suffer from impostor syndrome, question how much of that lack of confidence is actually a healthy understanding of your own current boundaries—and how much is taking on the weight of other people’s bad habits.

Connection and Involvement

First, because this is me and not Brian, I feel no embarrassment in saying: get a Post Status membership! It will quite possibly be literally the best $99 you’ve ever spent.

After you’ve done that, you should also get out in the world and meet people—particularly at WordCamps and WordPress meetups. Patrick Rauland said, “I get so much out of every WordCamp I go to. For me, that face-to-face time is better than anything else.”

At WordCamps, “Don’t be afraid to meet people and engage,” Carrie said. “The sessions are great, but really they’re about 30% of the value for me. The rest is connecting with other people.”

In general, as Morten Rand-Hendriksen said, “Talk to people. That’s my best advice. Don’t find a cave and work in that cave on your own. I strongly recommend physically talking to people in real life.”

However you meet people, start those relationships, as Curtis said, by “offering value up-front”—”just because it’s valuable.”

Patience

As a simple point: Most interviewees have been working in WordPress since around 2008. None were overnight successes. Daniel Espinoza advises WordPress developers, simply, to “code every day.” Mika says that her secret is simple: “I just keep going.”

Summing Up

My major takeaways from interviewing these top WordPress developers were:

1. In code, always know what you’re doing and why. The main judge of code is not what programming paradigm it adheres to, or any other type of coding credential, but simply how clearly reasoned it is.
2. You must also thoughtful about the social side of code: how easy the code is to understand and extend for future readers (including your future self).
3. Being a successful WordPress developer is social, interactive, and collaborative to a surprising degree. Build relationships by offering value up-front: for example, by contributing to other developers’ projects. The relationships you develop can become an “impostor-syndrome”-free way to ask questions and exchange knowledge
4. Curiosity and confidence are the two main traits that let someone grow as a WordPress developer.
5. The best way to learn development is by doing it. Being “paid to learn” as you work to satisfy clients is an outstanding practice, as is working to contribute to other developers’ projects.

Thanks for reading! To watch the interviews and code walkthroughs themselves—and to learn the key principles of WordPress development through our e-book and tutorial videos—check out Up and Running. Use coupon code krogsgardsarmy for 15% off any package!