Start Nitpicking Your Source Code (Or Someone Else Will)

Earlier this week, a fellow WordPress programmer whom I respect (and who is doing amazing things with his Aesop Story Engine) shared the following tweet:

Truth be told, I wasn’t sure if he was being sarcastic or not. This isn’t his fault, of course, but my own ability to discerns, y’know, tweets. So I did what anyone would do in that situation: I asked him if he was being sarcastic or not to which he replied:

nope no sarcasm there. the nitpickers provide amazing value

And he’s right.

Someone is going to be nitpicking your source code.
Someone is going to be nitpicking your source code.

This post is not about my opinions or observations as to how we tear one another down online under the guise of trying to help one another (that’s another post for another time), but it’s about the idea for which I completely agree (and that’s mentioned in the tweet above):

because it matters what’s on the side you don’t see.

Because I believe it does, and because I think that a number of people are sloppy. There’s a just get it working mindset, and I’d love to see more people take pride in their work and stop shipping code that has the same amount of details “on the side you don’t see” as on the side that you do see.

Nitpicking Source Code

This month, I shared some of my opinions on how to write maintainable WordPress themes and a significant portion of doing exactly that is making sure that the parts with which you’re working are just as well assembled as the look-and-feel of the product makes it appear to be.

Obviously, I believe Nick to be on point. He isn’t the first to make this observation, either. For example, in the Steve Jobs biography, Isaacson writes:

Fifty years after the fence was constructed, Jobs showed it to Isaacson, still standing and recalled a lesson about making things of quality that he learned from his father. Touching the boards of inside of the fence, he said that “He loved doing things right. He even cared about the look of the parts you couldn’t see.”

The type of effort and attention to detail exemplified by both Nick and Jobs is something for which I believe we should all strive.

Furthermore, I think WordPress urges us to do so.

  • We have a set of coding standards that define what our code should look like
  • We have a set of documentation standards that define how our code should be explained
  • We have documented APIs so that we know how to leverage functionality that exists within the application
  • We have the entire code base available for us to study
  • …and so on

So when it comes to building yet-another-theme, don’t approach is as just building a theme. Approach it as building a well-rounded product – something that you’re creating with pride and that you’re doing so both inside and out.

And if you’re working on a plugin, make sure that the parts that are moving behind the scenes are just as well put together as the problem at attempts to solve. People do notice that stuff. It’s the nature of open source.

If you’re not nitpicking source code – especially your own – then perhaps it’s time to start. We can be our own worst critics, you know. Why not make the most of it?

So, as Nick said, here’s to the nitpickers: You keep us all honest and make us want to do better work.

8 Replies to “Start Nitpicking Your Source Code (Or Someone Else Will)”

  1. Because I’m a bit OCD with my own code, this article hits home :).

    In my experience the optimal path is somewhere between “just get it working” and “nitpicked”. If you’re too sloppy, it becomes hard to maintain. If you’re too obsessed, you fall behind and/or it never ships.

    Knowing when a piece of code is finished is an art – a “sixth sense” – that you have to cultivate over time. I’ve experimented on both extremes (rushing jobs vs. polishing to perfection) to develop that sense.

    In general, I encourage devs to err on the side of “just get it working” because, for the typical dev, it’s harder to ship than it is to craft code. Would you agree, Tom?

    1. Because I’m a bit OCD with my own code, this article hits home :).

      Oh yes. I think we’re all part of a club on this one ;).

      In general, I encourage devs to err on the side of “just get it working” because, for the typical dev, it’s harder to ship than it is to craft code. Would you agree, Tom?

      Generally, yep – I do. I especially like your “sixth sense” idea. This is something that I think takes time to develop, to refine, and to almost have an intuition. I also think the flip side of it is that you also know when the code you’re releasing than what makes you comfortable (where the circumstances for release are outside of your control).

      I think you’ve really kind of nailed it when it comes to striking a balance.

  2. I agree, no matter what comment or minutiae someone points out, every opinion is valuable. Negative or positive. The trick is pulling the lessons from them ;-)

    However it can get you down. In my experience decent programmers care deeply about their code and when it’s get’s criticised it’s difficult to be objective. I guess we just have to stand back, take a deep breath and look at what the person is trying to tell us, rather than the words written or being said.

    1. I agree, no matter what comment or minutiae someone points out, every opinion is valuable. Negative or positive. The trick is pulling the lessons from them ;-)

      Yep. Within reason, of course. It’s like the saying that “there are no dumb questions.” That’s true up to a point, but you’ve always got your exceptions :).

      I guess we just have to stand back, take a deep breath and look at what the person is trying to tell us, rather than the words written or being said.

      Again, yeah, I think this is it true , but there are also exceptions where some people are either just being cruel, trolling, or are wrong and don’t know enough to know that they are wrong.

Leave a Reply

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