At one time or another, as a developer, we’ve all found ourselves hopelessly stuck on a coding issue we had to solve. Desperately searching stackoverflow on the off chance that someone might have the exact issue that you do (they’ dont). Only to to wake up the next day to find the answer was right in front of you the whole time, how could you miss it!
Here’s 5 things I’ve learned as a Front-End Developer that help me break through my worst mental blocks.
1. RUBBER DUCK DEBUGGING
If you’ve worked with other developers before, you should be aware of the phenomenon by now of trying to explain a problem to someone and within the same breath, realizing the solution to that very problem. Which is great, but no-one wants to waste their co-workers’ valuable time. Nor will there always be a coworker with the knowledge or availability you need to help in a pinch.
The simple solution is to re-engage in the same phenomenon with a rubber duck at your desk (if you have one) or any other inanimate object you want talk to. When your mind is forced to reframe a problem in a way that makes it explainable, you have to break apart into it’s basic components and often that is where the ‘aha’ moment comes from. There was something on a basic level you were missing. It’s silly, and your work-mates may look at you funny, but try it out! You’ll be surprised at how effective it can be.
2. ASK YOURSELF ‘WHY’ AM I DOING THIS?
Have you ever found yourself trying to build a feature or make an improvement no-one really asked for? While in nature this is good developer behavior, it doesn’t help anyone if you spend hours accomplishing much of nothing. Generally, we find ourselves here when there’s a small improvement we want to make that should only take an hour or less, but turns into a day long project. Usually due to tunnel-vision, lack of high-priority items, or simply the challenge of an issue that is hard to solve.
It’s good to ask yourself at any moment, why am I building this? Who asked for this feature and is it worth the amount of time I’ve already put into it? If you can’t think of a good answer, sometimes it’s ok to cut your losses and move on.
3. SWITCH TO PLAN B.
Much like the previous advice, it’s good to ask, why am I doing this – this way? Or if you like metaphors, why are you hitting that nail with a coconut instead of a hammer?
Take for example a recent problem of mine. I spent the better half of a week trying to make a well-known JavaScript library add a fancy image carousel to our new site. The site had some complex features that the JS library was never meant to handle. I tried a dozen different ways to altar and hack the library into working, but nothing turned out quite the way I wanted it. Eventually I realized building the carousel from scratch was much more feasible not to mention it only took a few hours!
The moral of the story here is I should have stopped somewhere on the first day and asked, is there a different way to approach this problem all together? If you hit a wall, don’t be afraid to approach a problem from a totally different angle even if you have to start from scratch.
4. PUT YOUR PROBLEM IN TIMEOUT.
Assuming there’s no time pressure, it’s ok to put your problem on hold for a bit. You may feel like you’re giving up, but simply putting the issue on hold and working on another problem gives your mind a break (without actually having to take a real one, but that works too). Better yet, working on a different kind of task all together might light up some ideas or concepts in your brain on how to retackle the original problem. I’d recommend putting a problem on a timeout for a few hours, or even a day if you can.
5. READ THE DOCS, NO REALLY.
This one doesn’t apply to everyone, but if you’re like me, this is the advice you need to hear from someone else. (because sometimes the truth is hard to take) Obviously reading the docs for any language, library, api, or tool you’re using is important. But, it’s easy just to hunt and pick for the exact snippet of code you were looking for to solve your problem. 90% of the time I jump straight to the function or line I’m looking for in documentation and honestly, 90% of the time this works. Much like finding the one missing piece of your puzzle.
But when this doesn’t, it’s easy to abandon the docs and try to jump into the source code, ask a coworker, or go searching on forums. The thing is, you may have already missed the answer. Try reading the whole section or even the whole documentation for whatever your using. Often there may be ways of solving the problem you didn’t even know the code was even capable of. Not to mention a stronger understanding of your code’s core concepts will give you more flexibility in how you use it.
//SUBSRIBE TO YOUTUBE