In the previous post, I happened to share a screenshot of some source code that was from a 0.1.0 (or, perhaps more appropriately named, an MVP) of a project I’m writing (and it turned out to be a good opportunity to exchange ideas with someone else).

Exchange ideas based on your source code.

Not long after it had gone live, I received a tweet containing the following comment:

Interesting to see how differently people work. There at least four things in your screenshot that I wouldn’t do.

From experience and from being online long enough, I know there are certain segments of our industry who look at something like this and think “Burn – he’s got it down and he’s going to take him to school.”

Except not really.

I believe I’ve talked about this in previous posts, but what I’m getting at is when others make comments like this to you, approach it in two ways:

  1. Understand they are coming from a place of [likely more] experience,
  2. Ask what things they would do differently. Odds are they have good reasons and are likely in a position to help you get better at what you’re doing.

Later in the post, I’ll share the entire conversation that took place on Twitter but I think it’s important to mention that, at this point in time, I know the person in question well enough to have both respect and no problem in engaging them in further questions and conversations about things like this.

But it hasn’t always been that way. So for those of you who are getting into sharing your code and learning how to field feedback that comes regardless of the format, then this is primarily for you.

Exchange Ideas (For Everyone’s Sake)

At some point, I’m going to talk about my reservations about releasing anything less than a 1.0.0, but this is not that post. I will say, though, this is probably the first time I’ve ever used a simple screenshot and received a code review.

But I dig it.

The gist of the conversation revolved around a few of the following topics:

  1. Licensing,
  2. Uppercased namespace,
  3. Manually including files,
  4. File names,
  5. Directory structure.

Some of these have to do with using the PSR versus the WordPress Coding Standards, some of these have to do with how I typically structure my boilerplate files, and some of these have to do with how I structure my plugin directories.

1. Licensing

For example, when it comes to licensing, I default to the GPL sine that’s that WordPress inherits, but Thomas brings up an interesting point:

Given that I’m a fan of open source and that I’m not interested in getting into any debates around the GPL, using an even less restrictive license makes a lot of sense.

2. Manually Including Files

I usually work on my projects up to a point until it’s time to introduce something that follows more modern standards. In this case, an autoloader.

Exchange Ideas: Learn how to use an autoloader in PHP.

During the first couple of iterations, I may not include an autoloader because the number of dependencies is so small. On the other hand, there are times when I may include an autoloader from the very beginning because the number of dependencies is greater than other projects.

On the other hand, there are times when I may include an autoloader from the start because the number of dependencies

The point I’m trying to make is this: If you’re working on a modern PHP project, use an autoloader before you release the final version of your work.

3. Directory Structure

This one is arguably the most subjective of the other points listed above, but I tend to organize my files based on the area of WordPress in which they are applicable (and namespace them accordingly).

No, this isn’t necessarily the best way nor is it the only way. But it’s a convention I’ve followed for years and it ones that tends to make it easier for how to organize files (and yes, namespace them) accordingly.

Learning From Each Another

As I mentioned at the beginning of the post, it’s not about trying to “burn” anyone or try to show anyone what a poor developer they are.

Instead, it’s more like this:

And for those of you who are interested in reading the full exchange (after all, I didn’t include all the points I mentioned), you can do so here.

Don’t sweat sharing your code. Sure, you may get some critique and you may get some of those who are more concerned with showing how right they are.

But that’s noise.

There are those out there who care more about having a conversation around why certain decisions have been made. Sometimes they’ll learn something; sometimes you’ll learn something.

And it’s worth engaging in those conversations for exactly that reason.