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.

Category:
Articles
Tags:
,

Join the conversation! 6 Comments

  1. Hey Tom,

    I think I agree with Thomas to everything, except for one point (and yes, I’ve had that discussion with him before):

    I would not use Vhx, but rather VHX. My argumentation would be that Vhx is not a single word, but the acronym for three words (at least that’s what I assume). So, I uppercase the starting letter of each word … in that acronym. :) With some things, it gets difficult to argue, and Thomas certainly has consistency on his side for some examples ( Mysql vs MySQL, where that’s basically a trademark, not an acronym ), but I have to admit I sometimes throw consistency overboard to keep with common expectations and general readability.

    I also publish all my code under the MIT license, as it is just a less restrictive license and allows more people to make use of your code in an enterprise environment. GPL is more of a political tool.

    One other detail I noticed that Thomas didn’t mention:

    include_once is not a function, it is a language construct (like echo), so you can drop the superfluous parentheses.

    Cheers,

    Alain

  2. Hey Tom,

    I think I agree with Thomas to everything, except for one point (and yes, I’ve had that discussion with him before):

    I would not use Vhx, but rather VHX. My argumentation would be that Vhx is not a single word, but the acronym for three words (at least that’s what I assume). So, I uppercase the starting letter of each word … in that acronym. :) With some things, it gets difficult to argue, and Thomas certainly has consistency on his side for some examples ( Mysql vs MySQL, where that’s basically a trademark, not an acronym ), but I have to admit I sometimes throw consistency overboard to keep with common expectations and general readability.

    I also publish all my code under the MIT license, as it is just a less restrictive license and allows more people to make use of your code in an enterprise environment. GPL is more of a political tool.

    One other detail I noticed that Thomas didn’t mention:

    include_once is not a function, it is a language construct (like echo), so you can drop the superfluous parentheses.

    Cheers,

    Alain

    • How would break down the points through as satire? I’m asking not in a snarky way. I’m asking not as a loaded question. I’m asking out of sheer honesty. 

      (If nothing else, it can help me improve the way I convey some of this.)

  3. My biggest ‘should I even be a developer’ moment was caused by the first time I shared my code.

    I had been learning development for six months and attended my first hackathon. One of my teammates looked at my code and said “This is so bad, do you even know how to code?”

    That was so hard to hear, I moped for a month. I couldn’t even bring myself to look at my code. During that time, there were some days I was convinced that I should quit, that being a developer wasn’t for me.

    Finally, I was tired of being sad, so I forced myself to look at my code- and it was bad. Terrible in fact. Hard to follow, and terribly structured.

    On the other hand, it did things that I couldn’t even comprehend months ago. It was doing things which I would have considered wizardry a few months prior. It had a lot of flaws, but it showed so much of my improvement.

    I also realized that I understood his point. I could see where I needed to improve and start working on it. Even if I ‘didn’t know how to code’ at that moment, I knew that it was just a matter of time till I got there.

    It was then that I realized a few things:

    My code will always be flawed, all I can strive for is for it to be better.

    I’m not a developer because I write perfect code. I’m a developer because I write the best code I can, and strive to do better every day.

    Developers could do better at making sure that our criticisms are more constructive. We could do better at perspective taking and remembering that behind that code is a person that is putting themselves out there.

    Most importantly: Even if the criticism hurts to hear, I can still learn a lot from it. And even if the criticism is valid, its only a matter of time before I improve enough to conquer it.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.