Every Time It Turns To May, All My Sisters Fly To Me, To Paint

Every Time It Turns To May, All My Sisters Fly To Me, To Paint

"Blue Banisters" by Lana del Rey is one of the softest and the gentlest songs I know. And actually, there's a cover that I really like - and it's by me, lol 😂 back when I had long blue/green hair (kind of like the colour of the sea). But obviously I recommend the original (of course).

It's a beautiful song about femininity and about friendship. If you know anything about me then you'll know that I love softness and I love gentleness. I wish that the whole world could be soft and gentle, always. But one of the hills near my house in Luxembourg, (that I call the 'American Hill' because if you climb deep enough and far enough, it feels like you are in America), and one of my favourite parks in Liverpool (Sefton Park), and my FAVOURITE COVER ARTIST and probably my favourite singer in the world, Erato Benetou, all feel SOFT. They all feel gentle. They all have soft, soft, soft energies. And so do lots of my female friends. I try to bring softness back into the world again.

A picture from Lana Del Rey's  very beautiful, and very moving, "Blue Banisters" music video.

Coming Back to Rock Paper Scissors

I have been struggling with this project for weeks. I made the big mistake of getting outsider input with it too soon. Now it's all just stuck inside of my own head - jumbled. 

Some Thoughts

THIS PROJECT HAS REALLY SHOWN ME THE IMPORTANCE OF PROJECTS. 

AND IT HAS REALLY EXPOSED MY WEAKNESSES AS WELL. 

I have a one track mind. No really though. My neurodivergent little brain wants to think about only functions right now/or only else/ifs right now. When I have come to a project that is combining else/if statements (and ternaries etc.) with functions then it has completely thrown me.

Which shows that THE MOST IMPORTANT THING FOR PROGRAMMERS TO WORK ON IS THEIR PROBLEM SOLVING SKILLS. 

It's what Jules said to me last week when he was criticising chat GPT - computer programming is about learning to solve problems. It's not about learning the language. It's about learning to solve problems.

Problem-Solving with Artur

I raised the point with my team that I felt like I wasn't solving problems well enough. So naturally, Artur came to the rescue. 💚

The Easy Level at LeetCode

Okay so the very first thing Artur recommended to me was the Easy Level at LeetCode. I've know about LeetCode since before I ever wrote my first line of JavaScript (and possibly even Python too) but I have never looked at it - I have always saved it for when I was a "more advanced" engineer. I suppose it might be time to have a look at it though.

Here is Artur's approach:
  • Think about the problem and time-box 🕘⏰⏰
    • (The example that Artur gave was 20 minutes - use this time to find a solution or at least get an idea on how to solve it). 
  • Start with a simple solution, and see if it works in general.
    • This is something I am so scared to do even on my Codecademy courses - to even just try to implement a simple solution and see if it will work. I really need to work my way past/ and get past this fear. 
    • I need to somehow work past this fear of getting things wrong.
  • Then find the bottlenecks (i.e. the places where your code is slowing down your load and/or execution time) and you try to improve your code 
  • If you don't immediately have any ideas about how to solve or improve the problem
    • Most times that means that you'll have to learn something new
    • And you're going to have to look for the existing algorithms and solutions. 
    • Also, it could be that you don't immediately know how to come up with the solution
      • But you have some ideas around it
      • Or you have a feeling that you need to look at something and/or check something out. 
        • Then you can go and read about that idea. 
        • And see if it helps.
    • So therefore, you don't immediately have to jump to the solution.
      • Sometimes just some additional tips and/or context helps.
  • So you don't always need to immediately jump to the final solution.
    • As you try to understand.
    • It depends on the context.
      • You can either implement the solution yourself straight away.
      • Or you can leave it for later.
        • To give yourself the time to build up the knowledge in your head. 
          • And then in that case you can try to solve it again.
            • Maybe a couple of weeks later.
And what Artur also says which is really really really interesting is 
  • Some problems might seem unsolvable at first
    • And some of them really are!
  • But you must TRY TO DO SOMETHING WITH THE PROBLEM
    • Even if you don't really understand it at first!!!
  • Artur says that you have to trust your instincts!!! 
    • Or partially to rely on some similar solutions to previous problems ("heurystics").
  • Artur says that he did not actually realise the solution of some of the most complicated problems that he solves until the end. And that it was done more on intuition.
HOW FRICKIN' AMAZING IS ARTUR? 

Learning from Carlos

So Carlos is the name of the Web Developer from Brooklyn who is taking me through all the Codecademy projects (via YouTube video). I LOVE THIS GUY, I learn from him so, so much, he explains things so, so well. He is the only person I have ever encountered who loves detail as much as I do and he goes into such tiny detail and I love it. He finally makes things make sense for me. Just hearing him say it aloud really helps me to make it click. Here are a few things I learned from him today:
  • He just describes curly brackets {} as being the tool to "open up your code block".
  • He points out that in the example function, we use parentheses, because there are "two parameters".
  • He says that the function "takes parameters", an expression that it took me hearing out loud to process. 

Parameters and Functions

The project asked me to create an initial, simple function to say tell the human player, if they tied with the computer, that they had tied. I spent ages agonising over the fact that I couldn't find the proposed paramaters, proposed anywhere before only then I realised that THE PARAMETERS IN THE FUNCTION HAVE TO APPEAR TWICE, ONCE IN THE IDENTIFIER AND ONCE IN THE FUNCTION BODY.

I repeat, PARAMETERS need to go in BOTH the IDENTIFIER, AND IN THE FUNCTION BODY!!!

But I have to remind myself: it's not about being perfect straight away.

It's all part of the journey.

If/Else Statements and Curly Braces/Brackets {}

So you put the {} curly brackets around a function body (usually - unless it is an arrow function AND it's just a single line of code). But you also put them around the body of an else/if statement/switch-case-thingy/whatever. Which led me to think about the what the curly braces actually are. I can't remember if it was Matt or Jules who said it but one of them basically just said that the curly braces "contain a block of code" or something like that.

I spoke to Rosana about this today as well. Their explanation of this was:
  • In the case of a functions, they're just explicitly saying where the function body starts and ends. 
  • In other cases, e.g. like else/if statements, it's just for saying things like:
    • Where the 'if' execution starts and ends
    • It's like the opening and closing tags in an HTML element
      • <p> and </p>

toLowerCase() 

One thing I've learned about in the project so far was the toLowerCase() method. I've never seen this in JS before - only in Ruby and maybe Python. 

So what you can do is:

userInput = userInput.toLowerCase();

Although I am familiar with this it's good to revise it. So NATURALLY LIKE ALL GOOD AND SELF-RESPECTING SOFTWARE ENGINEERS (maybe) I went to the MDN.

So the MDN (my good old classic friend) says:

"The toLowerCase() method returns the calling string value converted to lower case."

It's nice and easy, you just (for some reason)
  • Have to put the full stop in front of it . (I don't know why).
  • Have to put the brackets after it (I don't know why and it is driving me INSANE). 
I went to Stack Overflow to check this. 

It says that "toLowerCase is a function as opposed to a variable."

I have reached out to Rosana to ask about this and maybe I will see what they say too. 
Update: they replied to me and said this: "It's because it's a function, yes. 

It's a function that belongs to the String object.

which is why you call it after a string: "SUSANNA".toLowerCase"

Wait WHAT so there is a String object? What? WOOOWWWWWWWWWWWWWWWWWWWWWWWWWWWW

To-Do List Update

My to-do list didn't shrink today, it grew.

Now I have added the following two or three items:
  • Write up how Reuben (a Senior Software Engineer at work) explained API's to me and how he FINALLY MADE THEM CLICK AT LAST.
  • Writing up what Matthew (also a Senior Software Engineer at work) said about tech security:
    • How devs mainly use tools and frameworks to implement these tech security things for them, and so they don't normally have to think about these kinds of things themselves
    • How the server should never trust anything that comes from the client-side if client-side means what I think it means
      • I.e. the side of the user.
  • If possible (can't guarantee) the tips that all of their team gave me about Integration Layers as I chatted to them today... 

Comments

Popular posts from this blog

Hello World

Yosemite

Two Lines of Thought, Makes Me Wonder What I'm Missing