When I draft posts, I normally don’t aim to write to any particular age group, demographic, or personality type – I generally just share my opinions on certain WordPress-related topics and/or development-related material.

But everyone mixes it up a little bit every now and then, right?

And so if I had to define a specific type person to whom this post is most relevant, it would be any one of the following:

  • Those who are just getting into software and/or web development,
  • Those who have been into development for a while but have yet to share code online,
  • And those who spend time critiquing others who are working to get better by publicly sharing code.

Maybe this is geared more towards the usual audience, but whatever the case: this is more of a retrospective post that I would have like to have read prior to where I am now.

A Cautionary Tale of Code Reviews

In the latter half of college, group projects dominated the majority of work that I did.

After all, how else are you supposed to get any type of semi-real-world experience if you’re writing code and building projects of any significant size, then it’s unrealistic to do it alone in your dorm room (or apartment) in the time frame for the given project.

But it was fun. I had the pleasure of meeting and working with a lot of great peers (some of whom I still keep up with) and the experience certainly helped as far as it relates to working in a team-oriented environment.

The thing is, when it comes to school, grades are important – so much so that sometimes you’ll sacrifice certain principles (such as, say, using X-number of design patterns in a given project) in order to actually get the project working to make sure you have a working build by the time the project is due, and then you’ll make up for the lack of implementation of the design pattern by talking about it with the class, the professor, on a test, or in another project.

I mean, that’s not just me, right?

But here’s the thing: When you first start working with a team – at least at that level – you get used to sharing code. Sure, you’ll likely bust each others chops for doing something poorly (or give each other props for pulling something off that’s really clever), but at the end of the day – save for, say, a senior design project – most of the work that you’re going to do will end up archived on a disk if not completely send to the trash.

Welcome to the Real World

But fast forward to your first job working on a team of other programmers – some of whom are more experienced, others who are the same – and begin working on a codebase that’s years old, deployed daily, and used by many, many, many people and you quickly learn just how important it is to be meticulous about your code.

Real Life in the Real World

Real Life in the Real World

In fact, you learn why so many blogs, articles, prominent developers, books, and so on push the issue of code reviews.

It’s simply this: Having multiple sets of eyes on your code especially from those who have more experience than you either with the language and/or the platform on which you’re building can help make you a better developer.

Then you get to pay it forward with the co-op, the intern, or the next new hire.

But wait: There’s this whole vulnerability issue going on, right? I mean, this is my code. I don’t want to show it to anyone else.

  • What if they laugh at me?
  • What if I look dumb?
  • What if I break something and they know it’s because of my code?
  • You mean everyone on the team has to see this?

In short:

  • They probably will.
  • You won’t, but you’ll probably feel that way.
  • Code reviews will ideally keep it from getting broken.
  • Yes.

As a developer, one of the most liberating things as a developer is the moment you stop fearing code reviews, and start seeking them out.

I don’t mean appreciating them (because you should), I don’t mean wanting them (because that’s not enough), and I don’t mean accepting them (because that’s weak). I mean looking forward to them.

What’s Wrong? Afraid of a Few Feels?

Here’s the thing: As far as writing code is concerned, I’m not sure of any other way to shortcut mistakes than learning directly from people who are more experienced. And when you accept that, all of the other stuff goes out the window.

Ignore the Feels

Ignore the negative Feels

Here’s why:

  • They won’t laugh at you because they’ve made the same mistakes.
  • You won’t look dumb – maybe inexperienced, but isn’t that the truth? – because dumb people don’t seek opportunities to better themselves (especially in a public arena).
  • If you’re seeking code reviews, then you likely won’t be breaking anything because either you’ve pushed code that you’ve done enough testing to have a reasonable degree of certainty, or you trust the reviewer(s) enough to prevent breaking from happening.
  • If you’re involved in open source, it’s likely that more people than anywhere else will see your code. I mean, it’s the Internet.

Yes, there are many, many more reasons why code reviews are something that you should seek out, but this is hopefully enough to drive the point home that if I knew then what I know now about code reviews, I would’ve been sharing code online much earlier than I am now.

Of course, this does come off a bit like code reviews are something that everyone should go after and that it doesn’t come at the expense of anything negative.

But everyone knows that’s not the case, right? I mean, there’s no positive without negative.

Extreme Aversion or Dislike

And so a word of caution to those who have been looking into putting their source code on GitHub, asking someone else to review their code, or pursue some type of mentorship from another developer: There are jerks among us, they will put your code down (and sometimes even you), and it will suck.

Haters Will Hate Thee

Haters Will Hate Thee

But I don’t know why any of those have ever been a reason not to try to better yourself at whatever it is you’re opting to do. Be it writing code, playing an instrument, learn a sport, lose weight, pick up a new hobby, and so on.

So, with that said, look for good company with which to surround yourself, don’t feed the trolls, ignore the haters (because they will hate – it’s what they do :), and write code, review code, and generally just try to participate in activities that help others as well as yourself get better at what you do.

Maybe this comes off a bit like a PSA, but I’m okay with that. It’s what I wish I had known when I first started.


Join the conversation! 5 Comments

  1. Maybe this seems like a silly question, but how would one even get started with a code review? How do you find the right people to review your code? I am 100% self/internet taught here – I have no doubt I do things the hard way entirely too often.

    I’m a little concerned that the amount of things to critique will be overwhelming… how do I get constructive critiques… someone that can look and prioritize their comments on big issues vs. nitpicking. Or just what issues should be addressed first and which are less critical.

    I’ve primarily done custom themes for clients… so I’m not writing plugins, and don’t likely need someone of your level to do the critiquing, not that you couldn’t be helpful… just thinking of allocating knowledge resources appropriately :).

    Do I post code on GitHub and send links to those who are willing to review? I need the basics!

    • It’s not a silly question at all – in fact, I think it’s a really, really good question.

      For some, code reviews can come in the form on code comments to code that’s been stored on GitHub. Some people will just flock to the codebase and make their contributions – in that case, you don’t really have to ask :).

      In other cases, there are people who don’t mind helping, but they don’t really raise their hand to say “Hey, I’m here to help if anyone needs me,” :). To that end, I always default to “it never hurts to ask.”

      What’s the worst that can happen, anyway? They’ll say no.

      Another option would be to simply tweet out that you’re looking for a second set of eyes and see if they’re willing to review the code you’ve shared. Some won’t mind at all and those who don’t have time, likely won’t respond.

      I’m a little concerned that the amount of things to critique will be overwhelming… how do I get constructive critiques… someone that can look and prioritize their comments on big issues vs. nitpicking. Or just what issues should be addressed first and which are less critical.

      This comes from experience on the reviewers part, in my opinion. For example, those who are going to nitpick are likely going to be those people who are really, really good and familiar with WordPress, but the nitpicking should come after the larger issues have been identified and commented.

      Those who nitpick do so because they spot all of the issues that can be resolved. Those who give a high-level review are either doing so because they don’t have the time, or because they lack the experience.

      I’ve primarily done custom themes for clients… so I’m not writing plugins, and don’t likely need someone of your level to do the critiquing, not that you couldn’t be helpful… just thinking of allocating knowledge resources appropriately :).

      Understood :) – but themes are still code, too, you know? That said, the thing about code reviews is that they are largely oriented more towards the programming community rather than the design community.

      This isn’t to say that designers can’t do it – they can! – it’s just not evangelized as much in frontend work as it is in application-level languages. And that’s just the nature of the industries.

      But I argue that front-end development has its own degree of complexity: there are Sass/LESS/CSS files, JavaScript files, templates, partials, functions, and so on – there’s plenty to review.

      Anyway, a bit of a long comment, sure, but there are a number of different ways to go about approaching it. In no particular order:

      • Place code on GitHub
      • Ask someone via Twitter or email
      • Contact someone who you know does code reviews and ask them (or for referrals)
      • And so on…

      Of course, others may have things to add, as well. This is what I’ve found to be useful in my experience.

  2. I can say 100% that having people look over my code has done nothing but benefit me as a developer. I’ve had a SEO company review my code to make sure I was doing things properly for search engines, I’ve had WordPress guys look over my code (or answer questions I’ve had) and help me do things better and I’ve had people help with regular css/html issues as well over the years.

    Another way I’ve learned a lot with code is by ripping apart themes and plugins for WordPress, figuring out what pieces of code make certain things happen and then working on my own plugins and themes utilizing what I just learned. Tutorials are great, but I think there’s something about the feeling of digging into code and figuring it out yourself.

    To me, it seems like a lot of emphasis has been put on the “business” side of things and people forget we’re all normal humans under the suit and tie – especially freelancers who don’t conform to the suit-and-tie lifestyle anyways.

    So timidness and politically correct speech floods the industry and makes it feel like some people are unapproachable or too business-like for the guy with a mohawk to talk to.

    Lately, with more people writing more about things like this (and your Thoughts on WordPress developers, Communities and Products article), it opens doors and bridges the gap, bringing the newer developers into an area where they’re not so afraid to ask for help and in the end, this benefits the development community as a whole, because everyone is progressing and less bullshit is being pushed.

  3. Great article couldn’t agree more. Seriously as a self taught developer for a few years now it was not until last year that I “put myself out there.” I started volunteering at local meetups to share some knowledge. I worked the genius bar at WordCamp wondering how I was going to fake my way through that; “genius?” ya right.

    I learned that I know what I work on and I don’t know what I don’t work on. That didn’t make me better or worst. It was the universal truth of all developers. Like when a couple goes to counseling only to realize their problems are the same as everyone else’s. My confidence since as changed so much, it has literally been the difference maker in my current growth trend. Only wish I was pushed in the water sooner by an older/experienced dev. So had to comment to say how true the insight of this article is. Love your stuff, publish more than I can keep up with, but always can relate to your topics.

Leave a Reply