Recently, I was talking with a fellow developer about the various strategies there are for writing code.

By that, I mean we’ve got a number of different paradigms such as object-oriented programming, functional programming, and procedural programming. We’ve got design patterns, strategies, ideas like SOLID, domain-driven design, aspect-oriented programming, and so on.

When it comes to these things – and as with most things – developers can be really opinionated (myself included) about which things are the best to use. To some degree, I think that there’s some part of us that wants to believe the thing that we’ve just learned is “the next great thing” as it relates to writing code.

Maybe that’s an amateur’s mistake, though. I mean, that’s how I felt earlier in my career – I remember whenever I learned, say, domain-driven design and all of the stuff that comes with it, I wanted to implement in all of my future projects because I thought it makes the code so much more readable.

But over time, my opinions have changed.

Sure, I still really like certain aspects of all of the aforementioned programming techniques, but I also know that I can’t apply them all in what I’m doing.

Coding Standards and Guidelines

When it comes to writing code in a particular language, framework, or foundation, I’ve basically got one rule of thumb: If there’s a convention and/or coding standard, then follow it.

You know, it’s the whole “When in Rome” thing.

When in Rome, Program Like The Romans

When in Rome, Program Like The Romans, Right?

As someone who has come from .NET, to Rails, to WordPress (with a few other languages in the mix), I’ve seen a lot of different coding conventions, and a lot of different ways to approach solving problems.

To me, that’s a good thing.

But the more I’ve progressed in my career, the more I’ve begun to appreciate the guardrails (read: coding standards and guidelines) that each language and environment offers.

In fact, I view it much like a style guide for writing for another site or publication. By that, I mean that sites that accept articles either for publication or for print will often have a style guide that define the rules by which you must follow in order to have your work published.

Deviate from the rules, and an editor will step in to correct your work.

PRETENTIOUS EDITOR IS PRETENTIOUS (OR YOU DIDN'T FOLLOW THE RULES!)

PRETENTIOUS EDITOR IS PRETENTIOUS (OR YOU DIDN’T FOLLOW THE RULES!)

I view programming languages and platforms much in the same way: Rails has it’s convention-over-configuration model (which I love), and WordPress has coding standards and guidelines for the various languages that go into working on WordPress-baed products, and I like that, too.

And at this point, I’m far less concerned with trying to shoehorn another environment’s conventions into my own current system.

Remember: The whole point of code reviews and coding standards is so that code looks like it was written by the same programmer. This makes reading, maintaining, and understanding the code much easier.

Yes, it’s hard to enforce – especially in a platform like WordPress – but it’s not impossible.

And so rather than trying to force new ideas into every new project that I begin working on, I try to refine the skills that I have for the current environment. If there’s an opportunity to introduce something new, then I will, but not out of disrespect for the coding standards and guidelines, but because the coding standards don’t have a definition, and it’s something that I think can serve better for the long haul in managing a project.

But the Critics Know Better. Always, Right?

One of the challenges, for lack of a better term, I suppose, with blogging, sharing your thoughts, approaches, and code as to how you solve problems is that you’re giving an audience a glimpse as to how you’ve solved a certain problem.

For some, this helps people; for others, it’s an opportunity to critique (in some ways good, in some ways bad).

There have been times where I’ve been told that I don’t understand what I’m doing because of the way that I’ve written my code even though it’s up to par with the environment’s standards.

There are also times where I’ve been told where things that I’ve done could be written better had I, say, followed some of Uncle Bob’s principles.

But the thing that I – and we – have to remember is that when we’re reading other people’s blog posts, there’s a lot of material that is being left out and we’re left filling in the gaps on certain things.

Specifically, I think that we end up drawing our own conclusions about why a developer wrote code a certain way, and if it doesn’t jive with how we’d do it, then they must be wrong.

But I don’t think it’s about the absolutes – at least not all the time. Sure, there are times where ignorance on a topic can generate bad code. I’ll be the first to admit that I’m guilty of this, but sometimes, design, programming, and/or implementation decisions are guided by the rules of the sandbox in which the user is playing, not by their lack of skill or ability to implement a solution.

Separate the Code From the Programmer

So as we end up reading through one another’s posts, gists, source code, and so on, let’s try to treat the code somewhat objectively and work to improve it rather than draw conclusions about one another’s skill level.

I believe that by helping to review and improve code, those who want to learn will be asked as to why a certain change is more optimal in what they current have because good programmers, I think, are inherently, insatiably curious.

Those who defend their implementation may be just as well-versed as the critic, but have a defense for why they opted to implement a solution in the way that they did, and, thus, they can each benefit one another.

And then, there are those who are taking a big step in sharing their work and not being aware of some of the  techniques for writing cleaner, maintainable, and easier-to-read code. Who are we to fault them, especially in the open source community?

Welcome the newbies.

Welcome the newbies.

It goes back to objectively critiquing the code: offer improvements, provide reasons as to why the suggestion is a likely better choice, and over time the developer’s implementation will get better.

And I’m not preaching this as if I’m the expert on this. I can guarantee the programming gods and my own peers know that. I’m sharing this from my personal experience.

But I want to get better, and help others do the same in whatever capacity I can.

So rather than drawing negative conclusions about things from which we don’t have all of the information, why not aim to chat and help those who appear to be making decisions that will ultimately lead to mistakes that we’ve made before?

It’s significantly more productive, a lot less arrogant (and even cruel), and ultimately benefits the community at larger.

Category:
Articles

Join the conversation! 5 Comments

  1. this is great Tom.

    an objective critiquing approach is much more helpful than a subjective one.

    • Thanks Michael! The truth is, I think it’s really hard to get passed our own biases and provide a purely objective approach. Perhaps I should’ve clarified that in the most.

      Regardless, being as objective as possible is what we should aim for.

  2. where’s the like button on this thing? ;-)

  3. Just awesome tom.. This post took 20 minutes to read, but I learnt something which I cant learn by wasting 20 days. Thanks man.

Leave a Reply

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