One example of my experiences with problem solving, specifically in regard to a relatively simple problem, was during this web development course’s early weeks of foundations in which we had just started learning HTML and CSS. the problem faced was that a section of code, which was not technically wrong or error producing, didn’t achieve what I had intended. At this point in my learning journey my ability to reflect on a relatively large section of code was very rudimentary and time consuming, this along with lack of error message initially resulted in me taking a brute force trial and error approach of incrementally changing, commenting out, and rethinking lines of code. Through this method I managed to narrow down my troublesome code to several lines which I then meticulously read over and over until realising that I had misspelled a class within an element, one simple correction and everything worked perfectly!
Not having a thorough understanding of the code I was writing at the time brought a sense of frustration through knowing I would potentially have to comb over larger sections of code to find the mistakes origin. If anything, this taught me the importance of formatting code with comments, indentations, and spacing, if I had done that adequately I am sure finding the relevant line of code would have been far easier.
Another problem-solving experience I have, one slightly more elegant and not relating to coding was during my previous job. During one of my shifts a customer had come in with a faulty product and rightfully wanted to get it replaced under warranty, the catch however was that the moment they entered the store they were already rather disgruntled and furthermore weren’t happy when informed that the warranty procedure could take 3 to 5 working days to complete. While initially at the time it would appear that the problem in this scenario was the faulty product, after a series of listening and looping with the customer I found that in reality the real problem for the customer was that they would have to go 3 to 5 days without the product, which was something they weren’t prepared for.
With this problem not being within the world of coding, many of the resolution techniques discussed below didn’t apply. That being said in a similar fashion to conferring with peers or coaches, and after putting in considerable effort to try and diagnose the products faults and see if they were fixable on the spot, I ultimately discussed the issue with my colleague and any options available to reduce the warranty process. After several iterations of toing and froing the product was ultimately replaced an hour later.
Ultimately, while it was my job, it was a lot of effort going the extra mile to get this problem resolved sooner rather than later. that being said, being able to see the mood of the customer change from grumpy and disgruntled on arrival to being thankful for my effort after explaining, attempting, and achieving to shorten the process was rewarding. This is what I think made this problem resolution elegant, the fact that given the negative circumstances when the customer entered the store, by the time they left the outcome was the best it could be.
Tying this back to coding, and problem solving in general, id say the main thing I took out of this experience was that a problem is not always as it seems. As stated, on arrival it would be easy to say the problem was the faulty product, which in part it was, however more importantly was that the faulty product was a driver of the larger problem of the customer having to go without it for an extended period of time. Being able to understand this driver meant that not only the initially apparent problem was resolved but more importantly its root cause, emphasizing the need to sometimes take a step back from a problem, look at the whole picture, and decipher whether you are looking at the problem, or just the portion of it that is being presented.
Currently I would consider my use of pseudocode to be minimal, and when it is used it is not used for problem solving per say. The scenarios I use pseudocode tend to be where im leaving my code unfinished or buggy for a period of time (such as if I decided to finish for the day and pick it up again tomorrow), because of this its more used as a book mark for my thought processes before stopping work so that I can refresh and pick those up when I come back to it later without having to dig through the code and try and figure out where I was going or what I was up to.
The rubber duck method is something up to this point that I’ve never used, and also never heard of before researching it for this course. From that research I understand the rubber duck method to be a form of “sound/black board” where you talk out aloud your thought process or code step by step in order to try find any holes in your thinking or logically where bugs may be arising from. As stated, if never used this concept for problem solving, however during several of my experiences in learning JavaScript I would do a similar practice of reading line by line out loud to try and understand what the sample or “teachers” code was doing.
Reading error messages is something I tend to look at very rarely at the moment, mainly being an avenue of exploration when other methods aren’t working out for me.
Console logging would be one of my lesser used tactics for problem solving, however used more often than error messages. Most of my use of console.log is more often oriented towards just checking that my function or query outputs what I want it to output before I code that output to be sent to or returned to wherever its needed. Because of this I wouldn’t necessarily say that I use this feature as a way to problem solve, more so as a way to ensure that I don’t have to problem solve now or later.
Googling would be one of the first things I do when approaching a small problem that I know (or expect) google will answer quickly and simply. The types of problems I use google to help overcome are usually small such as googling a specific piece of code to check I have the correct syntax (like whether it uses ‘:’ or ‘=’, or ‘[]’ instead of ‘()’). Besides that, I would also use google to search for new code statements I haven’t used yet but can easily explain such as searching “JavaScript code to detect a left click”. Most of the time these simple searches can produce a quick and accurate result.
Trial and error is one of the more common ways I approach a problem in circumstances where i have several ideas regarding how I could go about solving that problem. This trial and error approach would first see me trying most or all of my potential approaches before moving on to another problem solving technique if nothing came from that.
While I would definitely consider asking peers and coaches for help, I must say this is one of approaches to problem solving I use the least. My lack of using these support avenues is not out of fear or anything similar but rather about efficiency. I tend to save using these avenues for problems that can’t be overcome by any of the other methods mentioned in this blog post, while the quality of support is greater than alternatives, it’s a very time dependent option in which ill need to wait for a peer or coach to get a grasp on my problem, and then wait for a response after that. The way I see it is that If I can get the solution I need faster, and without disturbing someone else, then I will use that avenue, and then return to these options if that doesn’t work out. Much of my approach to this technique relates around the current remote work environment, in a scenario where I have a peer or coach available, and in close proximity (such as on campus or in the office), then I am much more inclined to incorporate this technique earlier rather than later.
The majority of my reflections around a process I’ve undertaken don’t relate to a problem-solving process, rather a reflection towards an overall work process regarding work that’s been completed or is to be completed. For example, while learning technical aspects of this course I often realised in retrospect that a specific task has taken longer and been harder than expected, from this reflection I then attempt to adapt how I plan my future daily or weekly work process in order to accommodate for these variances, and ultimately allow myself some extra time to work through tasks if that scenario were to arise again. This also helps prevent frustration I often face when a task does in fact take significantly longer than expected.