Developers & the square peg in a round hole problem

As a developer, I have a problem. Many developers have this problem, actually.

When solving a problem, we sometimes stick with our initial solution a little too long after it proves to not quite be an adequate solution. This can be for a variety of reasons: Their is a perception that the solution will still be the best (for performance, code accessibility, efficiency, etc). The solution itself is unique. The solution is within the developer’s skillset.

Ultimately, though, there is a tendency to take these solutions too far after they’ve proven to be a square peg being jammed into a round hole.

I was recently working on an internal React project; I’ve worked in React quite a bit, but I’m no expert. Far from it, in fact. Still, I’ve got enough experience in code to be able to work effectively in a variety of languages & libraries that may not be my greatest strengths, which is pretty common for many developers (like learning a language, the more you learn, the easier it is to pick up on others). I was presented with a problem, and came up with a solution.

When I worked to implement that solution, however, I later realized it wouldn’t be as simple as I had originally believed. Turns out the libraries I was working with did some things I was expecting, but other things that I didn’t. Still, I pushed on, swearing that this solution would still be effective.

You can guess, but I’ll tell you right now that I ended up having to refactor my solution significantly after finally forcing myself to take another look at the problem and the tools available to me.

It’s actually a problem commonly found in many industries. Healthcare, construction, marketing and more all deal with the square peg in a round hole problem. Developers, at least, can easily refactor with minimal loss aside from maybe an hour or two depending on how big the problem is, and how long they try to jam that square peg into a round hole.

Here’s my advice: When your solution is failing, don’t forget to re-examine the premise for it early and often. You may realize that, after fully evaluating the solution once you’ve really started digging into implementation that it just isn’t viable. You’ll save yourself a lot of frustration and come out with a better solution in the long run.