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.