I’d like to think that one of the struggles many developers feel when shipping code is a sense of “this could be better” before they push whatever button to send their code out into the world.

This Could Be Better: Code Review This

Yeah, okay, code review this.

It doesn’t necessarily matter if this is a hobby project, if this is a project for a corporate job, a freelance job, or if this is something that’s for an open source project. I say that because I think this is something that many of us feel with whatever it is that we release.

It’s a feeling of something is “not quite done” or “if I could just refine this a little bit more.” I know: This isn’t the first time I’ve talked about this before, and it’s likely not going to be the last.

And the feeling is not without merit. Other developers can make us feel like we’re doing something wrong (sometimes we are, sometimes we aren’t). But in our industry, I think there’s more of a spectrum of optimal-to-suboptimal. Though some may not agree, a friend of mine recently said it best:

The software industry is too vast and too fast to keep up with it all. But because it’s now that way, people find their niches and think that it’s the “best” or “only” way to get something done.

The further I get into my career, the more I feel this sense of obligation to make things as pristine as possible before sending it to a client, user, or just out for the world to use.

And though I think this is important, it’s important to make sure that I (and we) are doing this for the right reasons.

An example of a wrong reason might go something like this:

It’s not because it doesn’t meet requirements and it’s not because it doesn’t fulfill what was requested by the client. It’s because how others might perceive the work when they do not have the proper context.

So of course, I don’t think there’s anything wrong with wanting to make your code base or your architecture as robust as possible. We should all strive for that. But I believe that it’s important to contextualize appropriately and adequately scope your sprints, milestones, work or however you group your tasks together.

This Could Be Better

The thing is, the better we get at writing code, the less of this we should feel, right? Maybe. I mean, I’m doing better now than I was a half-decade ago but I still experience this, and I still get comments on open-source code that I share (be it on this blog, on GitHub, or somewhere else).

And don’t get me wrong: I welcome that critique, the feedback, and the suggestions. I haven’t always if I’m honest, but that was a lack of maturity on my part.

What I’m saying is that if you think “Hey, if I can just to get to that point in my technical abilities, then I won’t have to worry about [this] type of refactoring during a milestone.” And though that statement may be true, it does not mean that you don’t receive feedback from your future code.

There are always going to be things you can be doing better at every step of the way of every project on which you work. And there are always going to be other developers are who kind enough (yes, I said “kind enough”) to offer their feedback.

When I Know Better, But Do It Anyway

When it comes to working with wiring up actions and filters in WordPress, I typically take an approach that works like this:

  1. I have a class that defines the business logic. That is, this class is responsible for executing code on the data, and it doesn’t necessarily talk to WordPress.
  2. I have a class that’s responsible for defining all of the dependencies a project needs to render in the browser. This includes things such as stylesheets and JavaScript files.
  3. I have a class that’s responsible for orchestrating the communication between WordPress and the class that maintains the dependencies.

All of this is a good way to organize this because it keeps functionality segmented based on its responsibility. This has a lot of benefits as it relates to maintainability in the future of the project.

But I don’t always adhere to these rules especially if I’m shipping something simple, something that I know I’ll go back and refactor, and something that is nothing more than the very first release of a project (and I’m talking about a 0.1 – I’m taking about a 1.0).

Here’s some example code:

This function is in the same class in which the callbacks are defined. Does that look anything like what I’ve described above? Not at all. If someone were to read this code outside of the scope of this post or outside the scope of anything else I’ve done, would they critique it and offer feedback?

Probably. And I’m okay with that.

At one point, I used to feel this desire to want to say “no wait, hang on, I know all of this stuff, but I chose not to do it because of the following reasons” and then I’d give a defense as to why I didn’t do whatever they were suggesting.

I know, it feels like we’ve all got something to prove but at some level, it crosses a line from being productive and helpful to being some glorified contest or debate about our code. And then it crosses a threshold into being unproductive.

It’s easier said than done, but get out of that mindset. How much does any of this matter, really? 

I don’t mean the quality of the code, but I mean writing a lengthy justification for what you’ve shipped versus just staying heads down, focusing on what you’re doing, and slowly improving it over time.

If the person offers some insight you haven’t considered, then create an issue in your project management software and plan to resolve it. Otherwise, thank them for their time and keep on with what you’re doing.

The need to justify your decisions when shipping open source software especially incredibly small software doesn’t have to dictate how you’re spending your time.

And, as a slight digression, if you’ve experienced this on a small project, imagine what it would be like to maintain an incredibly large project.

The Struggle (Ask Why!)

If you’re embarrassed about placing your code on GitHub or embarrassed about how someone may look at it and then judge your abilities by it, I understand. Many of us feel that way.

The struggle is real, as they say.

But just as many of us feel that way, many of us also want to help others get better at the code they are shipping. So as embarrassed as you might feel or as embarrassing as it could be to have others publicly critiquing your code, this is something that I recommend pushing through.

Place that fear on the shelf. Ignore that snark saying you aren’t good enough and focus on what you’re good at doing and focus on getting better at doing it.

Besides, not everyone is going to offer feedback, code reviews, or pull requests that are offensive. Often, they are very matter-of-fact. And if you don’t understand why they are suggesting something, then ask them why.

This Could Be Better: Ask Why!

Above all else and regardless of how one delivers the critique – that is, politely or offensively – it may be secondary to the truth found buried in it. Try to extract that and move forward with your work.