When first creating my blog, I had some problems using flexbox in order to lay out my blog the way I envisioned. For some reason, I couldn’t get the layout exactly right, it was close but for some reason I couldn’t get it flexing the way I wanted it to. It turns out this was a super easy fix, but it took me a lot longer than it should have because of my problem solving techniques. When I first encountered this problem I spent ages just trying to brute force it. I just tried to flex every single element hoping eventually I would run into the right one. As it turns out, this isn’t a very effective problem solving solution. In order for me to solve this I realised I had to slow down, and understand why it wasn’t working. I turned to google and did some more research on flexbox to further my understanding. Once I took the time to slow down and research, it turns out it was a really easy and obvious fix. In the moment it made me feel super frustrated, because to me it felt like it should be working, but it just wasn’t. Once it was solved however, it felt super satisfying and rewarding. It’s always a great feeling overcoming a tricky obstacle. Even though this caused me frustration at the time, this was a good learning opportunity going forward. I learnt that instead of rushing through the problems, it’s more beneficial to slow down, take your time, and analyse the problem and how you should solve it before just rushing straight into it and trying to brute force it.
I managed to solve the customer money problem in the JavaScript cafe stretch in a pretty elegant way. It was a relatively involved process with a few steps to set up. Instead of rushing straight into the problem like I usually do, I slowed down and decided to write pseudo code instead. This allowed me to break the problem down into little steps, in order for me to know where to put my focus. When doing this process, I felt a lot more in control. Usually when solving a problem my mind is racing trying to solve everything at once, but by having clear steps to work on, it makes it a much more easy and organised problem. However it wasn’t all perfect. I learnt that sometimes the first draft of pseudo code doesn’t end up working like you think it should. Sometimes you have to adapt the pseudo code, or change around the order of the steps. However overall this was a very productive process, and I will definitely be using it on future problems.
I am feeling pretty confident with this. I think it’s a very effective solution when trying to solve larger problems.
Trying something was always my go to, but I realised it can be much more efficient if you slow down and understand what you are trying, rather than plugging in random numbers.
I haven’t had much experience with this method, I will have to try and implement it for the next sprint.
I feel okay with this, but could also get better at