Maybe it’s just me, but one of the things about programming is that many of us pre-occupy ourselves with is the need to find the right way to do something. Contrast this with the mindset of “I just want to get it working” and you’ll know what I’m talking about.

Basically, it’s never good enough just to get something working.

Of course, there are exceptions: creating prototypes, working on a small demo to show someone how something may work, and so on.

But when you’re working on a professional grade product, there’s a number of things that go into getting things to work – anything from the design of the product architecture through how the various functions, modules, or pieces of code are going to interact with one another.

When “Just Get It Working” Is Not Enough

Case in point: Yesterday, I shared a piece of code on how I opted to simplify a function into a single line. It received a number of comments (all of which I appreciate), and lead to a great conversation via Twitter with another developer whom I really respect.

If you opt to read through the conversation, you’ll see that we talk about a number of different things, and yet-another-alternative for how to achieve the functionality that is presented. And it’s good code!

The thing is, I bring this up not to highlight the community of other developers who are participating in the WordPress space so openly, nor am I bringing this up to try and give props to those who share their similar or contrasting ideas.

In short, I’m not sucking up. If I were doing that, then I’d be merging every single pull request that showed up in my GitHub repositories. But I digress :).

The Unique Dilemma of Programmers

Instead, I bring this up to demonstrate the point that when you get to a certain level of experience in programming, I think that we all find something unique happens.

Specifically, we find that there’s not always a single right way to do something – there are a number of different ways to do the same task each of which has their advantages and disadvantages over the other.

What makes this even more interesting is that intermediate-to-experienced programmers know when they are making immature – for lack of a better term – decisions. At some point, a line is ultimately crossed where the programmer knows and can justify the decisions they’ve chosen over other viable alternatives.

Even more so, they have a sense that something is well-written, well-architected, and well-engineered, while simultaneously knowing that it’s not any type of silver bullet that they – or we – all want it to be.

On Subjectivity and Maturity

In short, the point of this is to say that programming is an extremely fascinating thing in that when you first start, we’re all writing code that’s less than stellar; however, the further we get into the practice, the more we begin to see opportunities to make the code more readable and maintainable despite the fact that there is some subjectivity – not completely, but some – in what we’re doing.

Furthermore, I think another sign of developer maturity is the ability to take the criticism, opinions, and even feedback from others with differing opinions and to learn from them – not to shirk them or to find offense in having someone else critique what we’re doing.

One of the biggest advantages of open source is the conversations that can ensue from the how and the why something is done so that we may all get better at what we’re doing and contributing better work into the world.


Join the conversation! 4 Comments

  1. Great article. But perfection is a luxury that I can’t show as a freelancer. My motto is simple – if a client pays less then he will get bad quality coding. And if he is willing to pay more, I try to follow all the software engineering practices. God knows whether any of my clients ever found out that. Bad coded program takes less time to develop than a well designed program.
    I hope it is not a bad practice. After all everybody has financial necessity.

  2. I’m not sure OP really meant that, but I know developers that don’t take care of the code they write when their client doesn’t pay well or imposes tight/unreasonable deadlines. I deal those developers all the time and I think they may have a good point there, because sometimes you just need the money and can’t afford losing a client because he doesn’t want to pay or wait for well written code. Personally, when I’m dealing with those clients I just prefer to shorten the scope of the project, not lower the quality of my work, since I believe that is my key to keep being called for further projects.

Leave a Reply