Problem Solving

Sprint 5.5

18 September 2018

  1. Tell a non-tech friend about a time you got blocked on a simple problem.
  2. I was getting an error message every time I tried to do anything with git.
    The problem solving techniques I used were to first google the error message, then I tried a few things, then I asked my peers for help. Then I googled some more, tried a few more things, and finally figured it out!
    Throughout the process I felt OK as I knew that I had plenty of time to resolve the issue as I had finished my task before schedule and knew there was going to be a way to resolve it eventually, even if I had to ask the teachers.
    I learnt more about the way that git works and that mistakes lead to a deeper knowledge of something.

  3. Tell a non-tech friend about a time you solved a problem in an elegant way.
  4. I had to make a counter which counted how many blue dots, how many green dots, and how many invisible dots there were, as the dots were changed.
    The problem solving technique I used was I kept referring back to the resource materials, trying something new, referring back to the resource materials, trying something new, etc. Each time I could feel myself getting closer, though knew instinctively that I hadn't quite cracked it yet, until finally it all clicked into place.
    I felt slightly anxious as I've been struggling with the JavaScript material, and felt as I wasn't coping with the pace. However, once I had figured it out it felt great.
    I learnt again that by trying different things again and again that it gave me a better understanding of looping in JavaScript which I had really been struggling with. By making mistakes I could eliminate my misunderstanding and gain a new understanding of how it worked. I'm still not confident in my knowledge of JavaScript, but I am more confident in my ability to learn.

  5. Reflect on how you feel using the problem solving techniques and process:
    1. Pseudocode. I should be more formal about using pseudocode. My version of pseudocode is to take a break and then think about what the program should be doing step by step, and how to tell it to do that. I feel like if I were to write it down rather than just think it, it may be more useful and un-muddle my head a bit.
    2. Trying Something.This seems to generally be my first step when I have a block. Just try something and it may give you that trigger moment of how to begin or proceed.
    3. Rubber ducky method.I haven't used this one yet. I need to try it. I feel like I am doing something similar when pseudocoding.
    4. Reading error messages.This is always really helpful, but sometimes I have found that it has pointed me in the wrong place and made me focus on the wrong thing. For example, it will point out the problem to be the first thing on line 5, however the problem is I've missed a bracket or semicolon on line 4. Now that I am aware of this I am more confident with error messages.
    5. Console.logging.This still really confuses me. I think I have a better idea after sprint 5 but console.logging has gone way over my head.
    6. Googling.I am very confident in googling.
    7. Asking your peers for help.I am less confident in this but have done it. It is very useful as they will draw your attention to things you have missed and you can ask further questions unlike googling where you get some information but can't clarify further.
    8. Asking coaches for help.Not so confident. Haven't tried yet.
    9. Improving your process with reflection.I am doing that now as I write this and I think it has been very helpful to write this all out and see how I can improve.