Here is a story of when I got stuck by something rather simple.
During week two of DevAcademy foundations I was tasked with creating a basic homepage for a website that would later host my blogs.
I had already been in isolation for several weeks prior to this doing an online web development course. In that course I learned about bootstrap, a CSS framework. The framework is nice because it does a lot of the heavy lifting.
I had the idea to create my homepage using the bootstrap framework as it was still (mostly) fresh in the think tank. One of the features I was really looking forward to adding to the homepage was the carousel, so my blogs could slide along the screen.
I knew what I wanted and that was to have the buttons you click on to go to the next blog, and previous blog, stretch all the way to the corners of the window.
This is where I got blocked.
I couldn’t figure it out immediately, so I played around in DevTools for far too long, thinking that I could just trial and error my way through it. After much frustration at not being able to solve the issue I tried to re-watch old tutorials about the carousel. But I sped through them, angry at myself for not remembering, which only made it worse as I didn’t get anything out of that.
After too much frustration I asked for help. Within literally 60 seconds my flatmate had come over to my laptop and analysed what I was trying to achieve. He goes:
“Have you tried increasing the padding?”
Problem solved. In less than 60 seconds. The Relief.
What did I learn from this? Don’t be afraid to ask for help. Which brings me to my since acquired favourite proverb:
"The person who asks is a fool for five minutes, but the person who does not ask remains a fool forever.” - Source unknown.
That was a comical start to problem solving as a developer. Since then I’ve learned that there’s this thing called google, and we now get along very well.
In this next story, my problem solving skills were considerably more thought out.
During week four of DevAcademy foundations I was practicing unit testing. In this particular test I had to write code that would:
I had a fairly good idea of what I thought the solution would be, and I was pretty amped. But this time before I got stuck into typing out the solution I thought I had best validate my assumptions with a quick google.
I opened a new tab for each array and string method I though I would need, to make sure I understood what they did.
Then I quickly jotted down what I thought the solution would be as pseudocode on some paper, paused, had one last look over it to make sure it made sense, AND then I wrote it into the code editor.
A spectacular failure, it returned a string with only ‘buzz’ words. So I immediately went to the tab that had the ‘.filter()’ open to have another read. I quickly realised my mistake, changed one symbol around in my code and BOOM, it worked.
This time around the problem solving process was much less stressful. I actually rather enjoyed it.
I learned a few things from this experience.
Those were just a few stories I wanted to share of my own experience with problem solving. The takeaway being, if one method isn’t work then try another!
Here are a bunch more problem solving methods you could adopt.
This is essentially where you write out the code in plain English prior to translating it into actual code.
I really like using this to get my ideas onto paper first so that I can make sense of them, rather than trying to go straight to the solution.
The method speaks for itself, give something a go.
Hands down my favourite method. I feel I learn best when I just give things a go and see what happens. But it comes with a caveat, you have to reflect on what your input was and how that relates to the output. Otherwise you don’t get nearly as much out of it.
So if you give something a go, I recommend taking a little time to understand what you did and how it gave you that result.
This is pretty nifty. The idea is simple, get a rubber ducky and explain things to it.
There’s another level of learning that takes place when you’re forced to explain your understanding to another being (even if it is a squishy yellow bath toy).
Honestly I’ve never tried doing this with an actual rubber ducky but I can see the benefit. I’ve played around substituting a rubber ducky with my flatmates and find it useful in exposing gaps in my understanding.
Pretty straight forward. Have a look at the error message and see what it’s trying to tell you.
I’m a big fan of this. More often than not it’s telling me my syntax is wrong and will even go so far as to point out what line I’ve made a mistake.
Other times it’s a little more difficult, but can at least point me in the direction of a more accurate google.
As you go through your code, console.log small bits of code, functions, variables, and so on. I pretty much do this out of habit now.
Console.logging helps you see what the the code is doing behind the scenes. I find it very useful in finding where things have gone wrong.
The internet has all the answers if you know what the question is.
I find the game with Google is to maximise the keywords you use. So say for example you wanted to find out how to filter a certain word out of a string, you could try; “filter string javascript”.
This may not get you to the answer off the bat but you’ll learn a little more that’ll help you get there in the end.
I like how googling things often has the side effect of providing you with information that you will find useful down the line, with other problems.
I find this approach useful for when you run into a problem that you can’t find the solution to on google.
In the past I likely wouldn't have asked for help, but now I see the benefit in it. Chances are someone else has been or will be stuck there too and then you both get to learn from helping one another. It’s a WIN WIN.
I’ve absolutely no problem with this one. This is what coaches are for, to facilitate development.
If all else fails, ask those who are the most experienced.
As I said in my ‘Trying something’ rant, I think this technique is fundamental in any area of development.
It can be done in a broad sense, where you reflect at the end of each day and ask yourself what you’ve learned, and what you could change next time. Or it could be done for individual tasks, with the same questions asked.
I liken it to journaling/ use journaling as a way to continuously reflect on what has been done. I’m fairly biased but If you haven’t tried journalling before I highly recommend it.
Thanks for reading!