Too Many Threads: A Scattered Approach to Coding
The internet is indeed a wonderful thing. You can get answers to virtually any question – some may even be true.
Web designers know this all too well, as we tend to search for guides on how to do all kinds of things. Maybe it’s a cool CSS effect we saw somewhere or how to connect with an API. Whatever coding challenge we face, we’re sure to find a number of examples and support threads that can help.
In theory, this is great. These resources are invaluable in terms of finding solutions for even the most complex issues. But for me, it has turned programming into a very scattered affair.
A Need for Speed
Here’s the situation. I know I have my own limitations as a programmer – and I’m okay with that. Maybe I’ve accomplished more than I thought I could in this area, but I’m still no expert.
Over the years, I’ve conditioned myself to search for easy solutions. Sometimes it’s a WordPress plugin or maybe a little script I found on GitHub. The hope is to either find a complete solution or at least a code snippet that requires only a few minor changes (well-commented by the author, of course) and move on with the rest of my project.
Once in a while, this actually works. But modern websites are getting more complex. They require a higher level of functionality and need to look good on every screen. Thus, finding exactly what I need has become harder.
Instead, I’m finding what appear to be mirages in the desert. It could be a Stack Overflow thread from a developer with a similar issue, or a blog tutorial. While it may look promising, there’s often some key element missing.
So, what do I do? I cut and paste code all over the place – making a mess and running around in a big old circle. Turns out I’m wasting time rather than saving it.
An Epiphany
The result of this method has been a bit of madness. Recently, it came to a head while trying to work with the Google Maps JavaScript API.
There are absolutely tons of threads regarding the things I needed to do (placing multiple markers on a map, for instance). Of course, none fit my situation perfectly. And, while I know some JavaScript, I wasn’t confident that I could write enough on my own to make it all work.
I ended up spending hours switching from one snippet to another with very little luck. Finally, it dawned on me that my approach was just not working. I was haphazardly trying to find a quick fix. And in the process, I was taking myself far away from any real answers.
This led me to try something different. Here’s what I did:
Erased the Mess
I had amassed quite a jumble of code, which I promptly deleted. Maybe that sounds drastic, but it wasn’t working anyway. A fresh start just seemed better at this point.
Wrote a List
Despite my attempts, I did not find a quick and easy solution. Part of the issue may have been that I hadn’t defined any clear description as to what I needed the script to do.
So, I typed up a surprisingly short list of what my Google Maps script had to accomplish. Within that, I set some milestones.
For example, the first thing on the list was to simply display a map on a page. No markers, no fancy options – just a map. The idea was to start small and take the rest one step at a time.
Slowed My Pace
There is a part of my personality that makes me crave ruthless efficiency at work. I feel like every second wasted is keeping me from the rest of my to-do list.
Coding doesn’t really work that way, however. Just like good design, it requires some trial and error. You need patience to do it right. And you don’t generally accomplish everything in one shot.
In that spirit, I slowed down physically and mentally. No more rushing about. I promised myself that I would avoid support thread hopping – at least until I had a firm idea of exactly what my sticking points were. For the most part, I stuck to it.
A Better Approach for Better Results
It’s amazing what hitting the reset button on a coding project can do. Starting over and slowly tackling one piece of the puzzle at a time led to a less stressful process. While I still hit some roadblocks, it was much easier to research and experiment with a single issue, as opposed to everything at once.
I think there’s a bigger lesson in the whole experience as well. Web design, like much of our culture, seems so focused on having answers delivered on demand. And since there are an endless amount of resources out there, it’s easy to fall into a trap of hoping that someone else can solve your challenges with cut-and-paste speed.
But those resources are there to lend a helping hand – not do our work for us. Looking at the Stack Overflows and CodePens of the world are a great place to get ideas and inspiration. But they can’t remove every single barrier. In the end, we still have to put in the time and effort to make things work.
In my case, I think part of the struggle was that I learned to do a Google search long before I knew any fundamentals of code. As a result, I ended up reversing the order of how to get things done. I looked for complete solutions first, instead of just searching for the particular problems I needed to solve.
Hopefully, I’ve learned my lesson. Because another challenge is undoubtedly right around the corner.
The post Too Many Threads: A Scattered Approach to Coding appeared first on Speckyboy Design Magazine.