One of the things about programming in the same “environment” for an extended period is that you get comfortable with the way you tackle similar problems.
Case in point:
When you start writing a plugin, you likely have an idea as to how you will implement something before writing it.
I’d venture to say that this begins to happen while the client is describing their problem. I don’t think there’s anything inherently wrong about this. In fact, I believe that it’s probably a good thing as it’s a sign you’re learning your way around the API, how to structure files, assets, and so on.
But at what point do we start coasting on autopilot? Or, perhaps a better way to ask it, is when are we just going through the motions of solving different-but-similar problems?
We Should Be Creatively Solving Problems
For most of us, the things we’re building for others are going to likely be slight variations on problems we’ve already solved or problems that have been solved by other people. (Thus libraries, right?)
On top of that, we have reusable components and libraries of our own that we import into new projects top help us with certain, repetitive tasks. And that’s a Good Thing™.
At what point, though, do we start to question our methods?
Like anyone, there are other programmers I respect, admire, and whose work I try to study to improve myself.
Some of these are people who most developers probably know (like Joel Spolsky or Bob Martin). Some we may know personally or from afar in our circles. At some point in our hobby or career, we have learned at least one new thing from them.
But after we get to a certain point where we’re satisfied with what we’re able to accomplish, I think it’s easy to get comfortable and stop working on improving our pursuit of getting better at what we do.
On the other hand, I think it’s also possible that we start to think creatively about new ways to tackle problems that we experience as we grow our skills. Personally, I often question myself when I start to do this.
I mean, why would I try to come up with a new way or new technique for handling, say, loading dependencies in my projects when there are already a plethora of patterns, strategies, tools, and libraries to make this possible?
I won’t digress on this question, but I think it’s okay to pursue our ways of tackling problems. Sometimes the ways above of dealing with a problem might be overengineered for what we’re trying to do. Or perhaps a third-party tool doesn’t quite do what we want so we have to modify it a bit.
Project Specific Libraries
There’s nothing wrong with writing a project-specific library. Sure, you can generalize it later, but if you’re going to be maintaining a project over time, then I think it’s okay to have work within the context of your project.
So I’m rambling on working out our ways to solve a problem when a solution may already exist. What’s my point?
We’re scared of sharing the work we’re doing because we’ll seem inferior or even dumb to our peers.
Because there are those who will always show up in the issue tracker, comments, on Twitter, or whatever to say:
Why are you doing it that way, when this way or this utility can handle it for you?
And that’s always going to be there, but the effect that it can have on people trying out something new, trying to learn something new, and trying to grow their skillset through experimentation can take its toll.
Push Forward, Anyway
I don’t think I’ve said anything new nor do I think I’ve said anything that will contribute to changing this.
But part of the reason I bring this up is because, despite having done this for at least a decade, there’s still intimidation of talking about an idea of tackling a problem despite having existing, alternative solutions for it.
With all of that said, it wouldn’t be particularly honest of me if I didn’t discuss and share my code, though, would it? So in the next post, I’ll aim to put my
money code where my mouth is with some work from an existing project.