DEV Community: Kirsty Brewster

10 Lessons Learned From 10 Years of Music

Kirsty Brewster — Fri, 04 Jun 2021 00:26:59 +0000

While attending Flatiron School, and during my time of job searching, I’ve made my way back to insights and practices I had during my time as a musician. Here are 10 lessons I learned from playing music for 10 years.

1. Practice the fundamentals.

As a band kid, this meant practicing my scales during every session. It also meant practicing exercises like overtones in order to improve my sound. I had several books dedicated to basics like this that I would play through a little bit every day. While it doesn’t sound like much, this type of practice opened the door to me playing a wider range of difficult songs in various key signatures, as well as made me a better sight-reader.

When it comes to coding, practicing the fundamentals should mean that we don’t dismiss the simpler aspects of our chosen programming languages. For example, even though I’ve already learned the basics of JavaScript during bootcamp, I’m currently going through another JavaScript course on Codecademy. The things that might have slipped my mind, or not been as important during the fast-paced environment of bootcamp, are now solidifying themselves in my mind. I’m being reminded of techniques that make coding easier or simpler.

Fundamentals in coding can also be overarching concepts that apply to many languages, such as concepts related to Object Oriented Programming. Studying these concepts will make learning other OOP languages that much easier.

2. Take it slow.

When I would practice as a band kid, I would take competition music and slow it down to about half the suggested tempo. This allowed me to focus on the smaller details such as correct articulation and dynamics. I found this especially helpful on more technically difficult pieces, ones that required me to play more difficult patterns at a faster tempo. Going slow helped me gain muscle memory as well.

With coding, we should start creating projects that are relatively simple. This doesn’t mean that we have to only follow tutorials or not start our own projects because we feel we don’t know enough yet. It just means we should save anything that feels overly complex for later. Starting with less complex projects will allow us to give ourselves the time to hone the basics. For example, I’m currently coding my personal website, and I’ve chosen to do it from scratch. As a result, I’m getting the chance to really understand some HTML and CSS fundamentals, learn more about accessibility, learn some design concepts, and get practice with making my site responsive - things I didn’t have time to focus on during bootcamp.

3. You learn from experience.

When it came to competing for Region and All-State bands, I didn’t know what I needed to improve on in relation to my competition until I actually competed for the first time. After competing, I learned more about skills that I needed to practice more, and how I handled my nerves in high-stakes situations. I was able to take the experience and come up with a plan to tackle some of the things that I faced in competition, such as how I would handle my nerves the next time around.

There are so many things we could possibly be preparing ourselves for when it comes to interviews, but we can’t do it all at the same time. Every time you go in for an interview, whether you do well or not, you learn what you do well at, and what you can practice more of. I’m currently making a point to practice at least one new algo everyday because of an interview where I struggled on a more difficult algo question that was thrown at me. Use interviews as a way to assess which skills you’ll practice more often.

4. Practice performing.

When practicing music, it’s easy to stop playing and start over any time you mess up. This is something you can’t do in competition or during concerts, though. I knew that if I didn’t practice performing, I would inevitably stop during competition if I were to mess up. And for me, messing up could be the tiniest blip. I had to practice what I would do in a scenario like this, basically putting myself into a competition mindset, so that I didn’t make these mistakes for the real thing.

You should do the same for interviews. Nerves are a common part of interviewing, but there are certain things we simply can’t do in the middle of one. For example, while it’s okay to think about an answer, it’s not good to pause for an extremely long time like you’re caught off guard or never thought of a particular question before. Practice what you would do in this scenario. In this type of practice session, tell yourself that you’re not allowed to pause for more than 5 seconds or so, and improvise if you truly can’t think of a good answer. Odds are, your answer is actually pretty good, but you’re caught up in a perfectionistic mindset. Answering eloquently in a high-stress situation will come with time and practice, but we can also make sure to practice common interview questions semi-regularly until we’re comfortable and happy with our answers.

5. Immerse yourself in the right environment.

In school, I would practice for several hours a day because I had nowhere else to be and pretty much nothing else to do. My mom was a teacher and started work earlier than my siblings and I started school. As a result, we were dropped off more than an hour early and waited outside of the band hall until the band director arrived. We’d then practice until we had to be in class.

I also didn’t have a car, so when I had an early release my senior year...I went to the band hall and practiced until I had jazz band rehearsal. Pretty sure I wasn’t allowed to be on campus during that time, but… no harm, no foul.

If you want to reach certain goals in coding, make it difficult to do anything but code (in a healthy way, of course - see my blog post on prioritizing your hobbies). You’ll be putting more time into coding without even thinking about it. As a result, your skills will increase exponentially.

6. Give yourself breaks.

Back in high school, I never allowed myself a day off from practicing. I thought that if I skipped a day, my playing would suffer because of it. This was a bit extreme. I couldn’t even skip practicing on holidays like Christmas. As a result of this over-practicing, playing the saxophone became more of a chore than something enjoyable.

We should especially make sure to apply this to coding. Technology is constantly evolving, so we are constantly having to keep up and learn new things. While this is great for someone like me who thrives on novelty and challenges, there can come a breaking point. Especially once we are in a work environment, we shouldn’t be coding all day and all weekend. This could cause burnout, and is something we should be careful about. Don’t practice to the point of not even enjoying the thing anymore.

7. Find a mentor.

My high school didn’t receive a ton of funding. As a result, I never received private lessons, which was a thing at larger schools. My family also didn’t have the money to schedule our own private lessons, so I did what I could with the resources available to me. However, when I got to college, I finally had the chance to sign up for private lessons. I learned so much, and realized there was still so much I could improve upon in my playing. Even small changes, like keeping my fingers closer to the keys, or slightly changing my embouchure for a better tone, could make me a better musician.

When it comes to coding, try to learn from mentors, and get different perspectives on how to solve certain problems. You never know what you could learn!

8. Don’t be afraid of being a beginner.

Try new things! We can’t grow if we stay stuck in our comfort zone. My very first blog related to coding was about what I had learned as a musician. At some point, I developed the identity of a “good” saxophone player, and it prevented me from wanting to venture out and learn new skills related to playing my instrument. I didn’t want to be bad at a new skill, which would interfere with that identity I built for myself. As a result, playing became boring because it wasn’t about having fun anymore. It was about being a “good” player. While increasing our skills does open up doors and that sense of accomplishment is a great feeling, we shouldn’t let some image of ourselves being “good” anything get in the way of exploring and learning new things.

When it comes to coding, don’t be afraid to break your code. If something works, see what would happen if you changed certain parts of your code. If something breaks, you’re learning more about why something works when it does. Take a look at my previous blog post about this topic called “If it ain’t got errors, break it!”.

9. Have fun.

Relative to my last point, as a band kid, I had to be careful not to get caught up in being a perfectionist, and playing music the “correct” way. I reminded myself why I continued playing the saxophone in the first place, which was because I genuinely enjoyed it. I also eventually made sure to experiment and be a little bit silly with my playing sometimes.

When it comes to coding, we shouldn’t be so caught up in improving that we forget why we chose this career path in the first place. Every once in a while, sit down and work on a project just for the heck of it.

10. Be consistent.

Way back in high school, I didn’t even realize when I was improving at playing the saxophone. So how did I get better when that wasn’t really the focus at first?

I was consistent about practicing.

Trust that if you’re being consistent about coding, even just writing one line of code a day, the rest will fall into place. You’ll continue learning, you’ll improve, and people will start to notice.

I hope this was helpful! I try to challenge myself to balance these types of articles with more technical topics, but these kinds of blogs are just so dang fun to write! So I hope you enjoyed it. What’s an activity that’s given you unique insights into your coding habits?

Prioritize Hobbies in the Job Search

Kirsty Brewster — Mon, 31 May 2021 04:58:38 +0000

When on the job hunt, it can feel like we need to eat, sleep, and breathe code. Of course, finding a job is the priority at this time, so it can feel like we need to turn the heat up to 10, while simultaneously putting our relationships, hobbies, and health on the back burner. However, I’m here to tell you why it’s imperative to continue making your hobbies a priority.

Your Hobbies Keep You Interesting

Interviews

Let’s say you have an interview. More than likely, you’re going to exchange some niceties with the interviewer, but what are you going to talk about if all you’ve been doing is studying code and coding related concepts? A lot of the time, your first interview isn’t going to be with someone who is super technical and understands the ins and outs of code. You’ll probably need to talk about other things when engaging in small talk.

So what will you talk about?

Even something as simple as discussing a TV show you've been loving can create a connection with your interviewer. At the very least, it will give insight to your personality and how you might mesh with the team.

"Tell Me About Yourself"

This is a question you will most certainly get in an interview. Of course, you have to keep it short and sweet, but you can still weave in the interests that make you you. What led you to software engineering? Why is this a career you want now? For me, I have many previous interests with skills that carry over to coding. It makes sense to me now why I had those interests before, and why I gravitated to this field. I used to rock climb, which involved problem solving. I enjoyed and participated in music, creative writing, and filmmaking, which uses a lot of creativity. I weave these facts in whenever I make my pitch. It paints a fuller picture of who I am and why I want to be a software engineer.

We might think that companies just want to hear how we've spent all our free time learning new technologies and improving our skills, but I don't think this is actually the case. While it's valuable to keep learning about our craft, our other interests help in making us well-rounded creatives and problem solvers, which leads me to my next point.

Your Hobbies Make You More Creative

Utilize divergent thinking

Divergent thinking, according to Scientific American, is the ability to think of many ideas from a single starting point. According to studies, those who can better utilize divergent thinking come up with more creative and unique ideas. In one experiment, divergent thinking led to more unique ideas for how to use a brick. In another, participants who utilized divergent thinking came up with more creative ideas for an alien animal.

Your hobbies will help you come up with new blog and project ideas. Don’t just create tutorial projects. By maintaining your interests, you can come up with unique solutions to problems others might not have thought of before, and turn that into your next app!

Expand Your Network

People have lives outside of work. By attending events outside of programming, you open yourself to meeting people you might not have met otherwise. Whether they’re programmers or not, you never know where they work or who they could connect you to. When you’re on the job hunt, you want to tell anyone you’ve even had just a 30 second conversation with that you’re looking. People love to help. Whether or not that leads to a job, you might just make a new friend, which is always nice. :)

Relax and Prevent Burnout

While you might be treating job hunting as a full-time job right now, your hobbies are the time to relax and reset for the next full day of work. It's important to turn your work brain off at a set time each day. If you work to the point of burning out, you won't want to code at all, not even for fun, and that definitely won't be helpful in the job search.

Final Thoughts

Sometimes, we have to make sacrifices in order to do well in certain areas of our lives. Being on the job hunt might feel like we need to hunker down and put everything on the back burner until we find a job, but I hope this article convinced you of the importance of taking care of yourself and how maintaining your hobbies plays into that.

What are some of your non-coding hobbies? :)

Inner and Outer Joins in SQL

Kirsty Brewster — Thu, 20 May 2021 17:30:52 +0000

I'm currently refreshing my knowledge of SQL and am starting with inner and outer joins. With any type of join, there has to be a relationship between two or more tables. This is done with a foreign key, which connects data from one table to some data from another table. A join then returns the shared data from both tables.

I'll go over the different types of joins throughout this blog post, but first, let's view the tables we'll be using as examples. This is an example from W3Schools. Check out their tutorials here.

Table 1: Customers

id	first_name	last_name
1	Ana	Trujillo
2	Antonio	Moreno
3	Ernst	Handel

Table 2: Orders

id	customer_id	order_date
1	1	05-19-2021
2	2	05-20-2021
3		05-21-2021

Inner Join

Our first example is an inner join. This type of join will compare some tables using a foreign key, as mentioned earlier, and return only the matching info from the queried tables. In this case, the foreign key that connects our orders table to the customers table is the customer ID.

We could write our join clause like so:

SELECT Customer.first_name AS "customer_first_name", Customer.last_name AS "customer_last_name", Order.order_date
FROM Customers
INNER JOIN Orders
ON Customers.id=Orders.customer_id

This would return:

customer_first_name	customer_last_name	order_date
Ana	Trujillo	05-19-2021
Antonio	Moreno	05-20-2021

Notice how I renamed some of my columns. This is called an alias. We can do this to better keep track of which table each column is from.

Outer Join

An outer join returns what an inner join would, but also includes rows without matching info from the other table. There are three different types of outer joins.

Left Outer Join

The left join returns all the data in the left-most table (or table 1), plus the shared data from table 2. If any info returned by table 1 is not in table 2, it will return NULL instead.

SELECT Customer.first_name AS "customer_first_name", Customer.last_name AS "customer_last_name", Order.order_date
FROM Customers
LEFT OUTER JOIN Orders
ON Customers.id=Orders.customer_id

customer_first_name	customer_last_name	order_date
Ana	Trujillo	05-19-2021
Antonio	Moreno	05-20-2021
Ernst	Handel	NULL

Right Outer Join

The right join does what the left outer join does. Just flipped. It returns all info from table 2 (or the table to the right), plus the shared data from table 1.

SELECT Customer.first_name AS "customer_first_name", Customer.last_name AS "customer_last_name", Order.order_date
FROM Customers
RIGHT OUTER JOIN Orders
ON Customers.id=Orders.customer_id

customer_first_name	customer_last_name	order_date
Ana	Trujillo	05-19-2021
Antonio	Moreno	05-20-2021
NULL	NULL	05-21-2021

Full Outer Join

The full join will return all info from both tables. It's essentially reproducing all info, but in one table instead of two. Again, if any info isn't shared by the other table, NULL will be returned.

SELECT Customer.first_name AS "customer_first_name", Customer.last_name AS "customer_last_name", Order.order_date
FROM Customers
FULL OUTER JOIN Orders
ON Customers.id=Orders.customer_id

customer_first_name	customer_last_name	order_date
Ana	Trujillo	05-19-2021
Antonio	Moreno	05-20-2021
Ernst	Handel	NULL
NULL	NULL	05-21-2021

Where do we go from here?

Using a join for two tables is as simple as it gets. Once we get used to it, we can start joining more than two tables! We might have situations where we want to relate two tables to each other with a third table. For example, we could have a table called 'Kittens', a table called 'Owners' and another table called 'Adoptions' to keep track of owners and which kittens they adopt. This is called a 'many-to-many relationship', whereas the customers and orders example throughout this blog is an example of a 'one-to-many relationship'.

Why use join queries then?

Join queries are a way to retrieve certain information from related tables. From the kitten adoption example, our 'Adoptions' table only holds the owner ID and the kitten ID. We'd use a join query to be able to view more information about the owners and the kittens.

Hope this was helpful! It was certainly a good review for me.

Resources:

Code Challenge Retrospective

Kirsty Brewster — Mon, 17 May 2021 04:22:23 +0000

I recently finished an application for a frontend internship which included a coding challenge. I actually found it to be fun and learned a lot in the process. Here are some of my insights from the experience.

The main deliverables of this challenge included fetching movie data from an API whenever a user input some search term. I would then need to display those movies along with a button next to each one to allow users to nominate movies. If an item had already been nominated, the button needed to be deactivated. Users could also only nominate five movies, and needed to receive some type of indication that they reached their max. If they wanted, users could remove a nomination from their nominations list.

Besides those main deliverables, we were encouraged to add an extra feature or two, or improve the design. One feature I thought of was simply allowing users to navigate through their returned search results. This is because whenever the data was fetched, unless a page was specified, only the first 10 results were displayed. So, I set out to include next and previous buttons.

On the surface, this feature seemed like it shouldn't be too difficult. However, the more I thought about it, the more intimidated I got. I didn't even know where to start. So, I got out a piece of paper, and started to pseudocode.

This helped so much.

I didn't need to think about syntax or which components the code would live in. I just needed to focus on the bigger picture of what was needed to get this feature to work. Once finished, I managed to accurately plan out what I needed to put into code. This prevented me from forgetting important variables and in general just running around in circles through my components.

Lesson 1: Always pseudocode before tackling a tough feature.

Next, I wanted to add a fun feature. Maybe some confetti to rain down the screen when a user hit five nominations? I found a library called react-confetti and started following a tutorial. Based on the tutorial, I got confetti to rain down the screen when a user's nominations reached five; however, the problem was that the confetti wouldn't stop falling. I only wanted this to be a short animation. I sought out the documentation and tried several methods which did not work. It ended up being a very simple solution. Simply setting recycle to false prevented the confetti animation from looping.

Lesson 2: Slow down, and read the documentation.

I also ran into a weird bug while coding.

In order to disable my nominate button, I set the disabled attribute to nominations.includes(movie), checking to see if the movie object was in the nominations array. When first nominating a movie, the disable feature worked fine; however, when I tested an edge case of a user completing a new search for the same movie, the button would become active again. This bug would allow for a user to nominate the same movie multiple times, which I didn't want.

For context, the way I built my search feature is that a new fetch would happen each time my search value changed; I didn't want to store too much unnecessary data. As a result, my movies array was almost constantly updating. (I realize this might not have been the best way to do this. If I had more time, I think I would turn the search input field into a form, so that I only fetched data when a user submitted a search term. I want to minimize those fetches too.)

At first, I found it weird that comparing the movies in my nominations array wasn't returning true when comparing an identical movie that was being displayed in my results. How were these objects not the same? They had the same title, same IMDB ID, same everything. What gives?

The reason hearkens back to a basic fact about JavaScript objects. When you create an object, it is stored somewhere in memory. The object is given a reference which helps locate where it's stored. If you were to create two objects with the exact same data, and then compare them to each other, you'd see something like this:

const objectOne = {data: "some data"}
const objectTwo = {data: "some data"}

return objectOne === objectTwo
=> false

Since these two objects have references to different locations in memory, the computer does not view them as identical.

In my case, my nominate button disabled correctly the first time, because the movie object being referenced in nominations.includes(movie) was quite literally the same object saved in my movies array. When I fetched the movie data with a new search, I saved a new movie object to my movies array. Even though the data inside each movie object was the same, this new object had a different internal reference. To the computer, these objects were not identical.

I still didn't want to save all of the movies from the OMDB API to overcome this problem. Instead, I decided to compare the IMDB ID of the nominated movie and the movie in my search results. I put this code in a function that would be referenced by the disabled attribute in my nominate button. The resulting code looked like this:

const checkForMovie = () => {
    let disabled = false;
    for (let i = 0; i < nominations.length; i++) {
        if (nominations[i].imdbID === movie.imdbID) {
            disabled = true;
        }
    }
    return disabled;
}

JSX for my nominate button:

<button onClick={clickHandler} disabled={checkForMovie()}>Nominate</button>

We may not always remember these coding basics, but they hopefully come back easier each time we use them. Since I had previously learned this fact about objects at Flatiron School, I remembered after a little bit of thinking. I thankfully didn't have to go on a Google scavenger hunt to find the answer to what was going wrong.

Lesson 3: The basics never go out of style 😎

Finally, because I was creating this project on a bit of a time crunch, I had to prioritize and let go of features and design aspects that weren't important to the overall challenge. I speak of this concept in more depth in my most recent blog post. I'm especially proud of my growth in this area. I started with HTML only - just getting things onto the page, moved on to a basic design, and finally added the extra features that I wanted.

Lesson 4: Prioritize, prioritize, prioritize.

Overall, this was a great experience. I learned some new lessons, was reminded of old ones, and I got to work with an external API! I had never done that before, but this helped make the idea of it less intimidating. I will definitely use external APIs more often in future projects.

What programming lessons have you learned recently? :)

Project Work: How to Create More in Less Time

Kirsty Brewster — Mon, 10 May 2021 03:46:38 +0000

While working on my final project at the Flatiron School, everything seemed to be in place to allow for a productive experience. My classmates and I would meet everyday for SCRUM, where we would discuss our goals for the day. At the end of every day, we would go over what we had accomplished, so as to keep ourselves accountable. Finally, we had deadlines for when our MVP should be finished, as well as when our entire project would be wrapped up.

However, there are two major concepts that would have helped me in creating a project that I would have really been proud of after my time at Flatiron.

The 80/20 Rule

Several times while working on my final project, I would get caught up in small details that really didn't matter that much to the overall vision I set. Worrying a bit too much about the color scheme, line spacing, the inclusion of icons, creating a landing page. While these might have been good to add at some point, there were definitely more important things to focus on first. These smaller tasks were more of a distraction. As a result, I didn't end up including some of the stretch goals I had for my project.

So what is the 80/20 rule? This is the concept that 20% of our efforts get us 80% of our results. This concept, also called the "Pareto Principle", comes from Vilfredo Pareto, an Italian economist and philosopher from the 1800's. He observed this phenomenon in a few different areas. First, he noticed that 20% of the pea plants in his garden were producing 80% of the healthy pea pods. He also noticed in his home country of Italy, that 80% of the land was owned by 20% of the population. And finally, he noticed that 20% of the companies in his country were generating 80% of total production.

The 80/20 rule in action.

When it comes to our personal projects, the 80/20 rule is about prioritization. First, break your project down into steps that lead to the final product. From there, identify the most important steps. This is where you need to put the majority of your focus. You could argue that "the devil's in the details", but trying to give 110% into every little detail in your project is more rooted in perfectionism. Sometimes it's even a tactic we use to procrastinate on a problem we deem too difficult in the moment.

Parkinson's Law

Parkinson's Law is the idea that work expands to fill the time allotted. After I finished the MVP on my final project, I didn't really feel like I added any significant features. In all honesty, I was a little aimless and probably gave myself too much time to do things like add form validations and error messages. While these were useful features, I feel like I could have taken less time to finish them.

Parkinson's Law in action.

Set time limits for each task that you tackle on your project. If you give yourself a full day to implement a feature, you'll probably take all day. If you find yourself comfortably finishing a task in your given time frame, maybe try to cut that length of time in half the next time you try that task. If you find yourself stretched thin in a given time frame, increase it the next time around. There's a happy middle ground somewhere. It's all about experimentation.

Even with deadlines, it's probably inevitable that you'll find yourself stuck on a task. If you've spent a lot of time on such a task, go back to the 80/20 rule and ask yourself if what you're stuck on is really that important to the overall goal. If it's not, maybe it's time to move on.

In my case, I should have done this for a lot of design related tasks. However, we can't really throw design completely out of the window. People care about the look of a site or app. In that case, make design it's own category in the larger picture of your project. Now go back to the 80/20 rule: Out of the steps we could take for designing our project, what are the most important? Got it? Okay, maybe...we don't need a landing page all that bad? Or maybe we don't need to worry so much about the design of our buttons? However, if you're someone who wants to do more UX type of work, maybe it's beneficial for you to spend a little more time on design. Use your best judgement based on what your broader goals are.

Final Thoughts

While you might be thinking that each project you make needs to be the absolute best it can be, remember that knowledge comes with practice. You could spend your whole life trying to create the best app and never achieve it. You have to experiment and learn through trial and error. In the arena of creation, quantity leads to quality. Even if you create something and think it could be better, take that thought and apply it to the next thing you create.

Hopefully these concepts can help you prioritize and get more done in less time. I wish I had thought of them while I was still working on my final project at Flatiron! I'll definitely be taking what I learned from the experience and applying it to future projects. Heck, I even applied these concepts to this blog post.

Resources:

React Router: How to Render Routes Without a Link Component

Kirsty Brewster — Tue, 23 Feb 2021 21:09:16 +0000

While creating my most recent project, I came across a situation in how I wanted to use React Router. React Router provides the options to easily create links that link to a specific component and also render a URL defined by the coder. However, what if you don't always want to use links? My partner and I thought it would be cool to have a card in our RecipeContainer that, when clicked, would take a user to the NewRecipeForm.

So how to get our component to link to our NewRecipeForm route?

After some time of research, I found out that we could use an object called 'history' to render our specific route upon a certain action (i.e. clicking on a card component). There were two different ways to do this, depending on if our component was a function or a class. I had built this particular component as a function, and so I implemented a hook called 'useHistory'. This hook allowed me to push a URL into the history object, so that upon a certain action, I would be taken to that URL.

Voila! It worked! Surprisingly easily. Now we can do the same thing in a class component. Let's say that I want the recipes page to render once my EditRecipeForm (a class component) is submitted. I can create a function called 'renderRecipes' which uses history.push to render the recipes URL. I can then call this function after my form has been submitted.

Great! Using history works in a class component too! However, I ran into some trouble when I tried the same thing in our RecipeModal, which was also a class component.

Each RecipeModal had an edit button and a delete button. I wanted the edit button to link to a route for the EditRecipeForm, but I kept getting the error, "Cannot read property 'push' of undefined". Basically saying, there is no history object. But why?

The solution was surprisingly and frustratingly simple.

BrowserRouter has its own history object, so any component rendered within this router has access to that history object as long as we pass it down as props. This was the case for our RecipeContainer, as you can see when we view props for RecipeContainer using Dev Tools.

However, if we look at our props for our RecipeComponent and RecipeModal, we can see that there is no history object. It didn't get passed down from the RecipeContainer to the RecipeModal.

I didn't figure this out in time before our project was due, so I just ended up changing our RecipeModal from a class component to a functional component and using the 'useHistory' hook again; however, if I had passed down that history object to the RecipeModal, my previous attempt would've worked just fine.

Passing history prop from RecipeComponent to RecipeModal

Success! :)

Now I understand history in React Router just a little bit better and I hope anyone reading does too!

How to Debug in React

Kirsty Brewster — Tue, 16 Feb 2021 03:37:52 +0000

When I started learning React, it looked completely foreign. I couldn't recognize where the JavaScript was and that made debugging feel foreign too.

One thing that will make debugging feel easier, though, is knowing that we can still use Vanilla JavaScript in React! React is just a library (which is written in JavaScript!) that gives us access to different functions and extensions (like JSX). We have to follow some new rules which can feel tricky at first, but will make certain aspects of debugging a lot easier. Knowing how to diagnose an issue while learning a new coding language can make things seem more manageable.

One great new tool we have access to is the React Dev Tools. This is a browser extension that allows you to inspect your components in React. This becomes helpful when you want to inspect the state or props in a component. For example, props and state was very confusing when I first started learning React. I would pass some props down the same way I saw in class, but wasn't really sure if it was working.

Fear not! Even if you don't understand what props are, like I didn't, you can take baby steps and just make sure you are passing props down correctly by inspecting a components props and state.

Seeing props and state laid out like this also helps us visualize what props and state are. For example, we passed some props down from our App component to the RecipeContainer. Even though those recipes are a part of App's state, once they are passed down to the RecipeContainer, they do not become part of RecipeContainer's state. They are now props in RecipeContainer.

Seeing props like this also becomes useful when we want a child component to have different functionality based on two different parent components. Take this Flatiron Stocks lab for example. Whenever we click on a Stock component that belongs to the StockContainer, we want to add it to our PortfolioContainer. When we click on that same Stock component in the PortfolioContainer, we want that stock to be removed from our portfolio.

Unless we create buttons, we can only put one click action on our stock card.

A work-around would be for the PortfolioContainer and the StockContainer to pass down a remove and add function, respectively, to the Stock component. However, when we pass this function down, we give the function the same prop name. So now, depending on where this prop came from, it has different functionality in our Recipe component.

This might be hard to grasp just looking at our code, but when we look at our Dev Tools, we can see all of the individual Recipe components laid out, each with a different function, based on its parent.

We can also use console.logs to debug! As I said earlier, we get to still use JavaScript code in React. The difference comes in how we write our console.logs and where. First of all, a React component always has to render valid JSX. For now, what JSX exactly is doesn't matter, but if you see code that looks like HTML in your .js or .jsx files, know that you have to wrap any Javascript code in curly braces.

If you are writing Javascript outside of your return statement, no curly braces are needed! It's just like regular JavaScript.

Lastly, we can still use debuggers.

Since a lot of what happens in React works asynchronously, we might write out some code that in theory should run, but we just don't see anything happening on our screen. Adding a debugger helps you pause your code and you might see something happen that you weren't seeing before. If that happens, you'll know it's a timing issue, which can be solved by adding something like a setTimeout function to your code that needs to wait for another event to fire off first.

Without debugger (Example from a Flatiron lab)

With debugger

Fixing the issue

These are just the basics of debugging, and, of course, you'll run into more complex issues that require some more research. Knowing how to diagnose what might be going wrong in the first place is a good place to start, though.

Happy Debugging!

A Simple Guide to Scope in JavaScript

Kirsty Brewster — Wed, 27 Jan 2021 19:09:20 +0000

In Javascript, scope refers to the methods and variables we create and where they are available in our code.

If we don't declare our variables in the correct way, it can lead to some weird behavior. However, if we're aware of some of these peculiarities, it can make debugging much easier in the future. Knowledge is power!

Let's create an app where users can view info on various movies.

Here is the first variable declaration in our .js file. This variable lives outside of any functions; therefore, it has global scope. We will be able to call on this variable anywhere else in our code from now on, such as when we fetch our movie data.

We can also declare variables within functions.

Doing so makes that variable only available within that specific function. If we try to access that variable outside of the function, we'll get an error that that variable has not been declared.

Because of function scope, I don't have to worry about overwriting any of my function-specific variables anywhere else in my code. I can even declare variables with the same name inside of other functions if I want to.

Another type of scope we have available is block scope. This means that you can declare variables -- within an if/else statement, for example -- and it won't be available outside of that block of code.

Here's something else that's important when it comes to scope: we have to use let and const to declare our variables.

If we write variables without these declarations, they automatically become global scope. That means, if we're not careful, we can accidentally overwrite some of our function-specific variables outside of those functions.

The world certainly doesn't need more articles on scope in Javascript, but these were some of the insights I gained once I started exploring some of the scope peculiarities I was curious about.

If you want a more thorough understanding, I highly recommend checking out this article by Dr. Axel Rauschmayer.

Personal Empowerment Protocol: The Importance of Self-Agency in Programming

Kirsty Brewster — Wed, 20 Jan 2021 22:06:13 +0000

For a long time, I was a very indecisive person. I had trouble even picking a career path because I was afraid of picking the wrong one.

What I was lacking was a sense of self-agency.

I needed others to tell me what the correct path was, whether that was friends, family, or even society as a whole. I didn't trust myself to make decisions that would benefit me. It was only when I self-reflected and finally acted on what I thought was best for me, that I gained more confidence to trust my own decision-making abilities.

What is self-agency? Here are some examples from Psychology Today:

Asking someone to eat dessert with you so you don't feel guilty.
Borrowing societal definitions of success, beauty, etc. w/o considering your own.
Asking for dating advice before defining your own thinking.
Following the advice of self-help experts without thinking for yourself.
Using social media “likes” to boost your confidence.
Using your spouse as a buffer at family gatherings (or even a friend at a party).
Asking your therapist for advice.
Using an impressive job title to boost your confidence.

There's a lot of the need for reassurance in these examples. Self-agency, in essence, is a skill in which we don't require that reassurance. We have faith in our abilities to handle various tasks and solve tough problems.

Where does programming come into this?

When I first started at Flatiron School, we learned about the Personal Empowerment Protocol, which goes:

1.) Read the error: See if you understand what the error is telling you (errors are there to guide you!) and try to solve the problem on your own.

Step 1 of the PEP is self-agency in action. Especially when we're beginners to a coding language, we might feel like we really don't know anything. And that might be true if we're starting from scratch. However, once we have a handle on the basics, it's amazing what we can figure out using our limited knowledge. Even if there's an easier solution out there than the one we come up with, we've just practiced a skill that's needed when we inevitably run into problems that don't have an easy answer.

2.) Google the problem

Googling can be considered its own skill. We have to know how to even word our question in a way that the solution we want will come up in our search results. While we might not always find the solution that exactly fits our needs, we can get pushed in the right direction, even if that just means understanding our error better.

If you've given the first two steps on this list your best shot, but still can't figure out what to do, don't fret! The PEP still recognizes the importance of asking for help/guidance.

3.) Ask a neighbor

Google coming up with a whole bunch of technical mumbo-jumbo that you don't quite understand yet? Been at this problem for half an hour already? Ask a neighbor! Neighbor in this case refers to a "table-mate" when studying at Flatiron, or in my class's case, "zoom-room-mates". If you're not in any classes, reach out to friends who are programmers or any online communities! Teaching is one of the best ways to learn something, so no one is going to shy away from helping. If someone else can teach you in a way that you truly understand the subject, they'll gain more understanding as well. It's a win/win situation!

4.) Ask a teacher

The teacher is there to guide you. Or maybe you're not in school and this person is one of your superiors wherever you work. Either way, this person has more experience and can more than likely solve the problem you're having very quickly. However, you don't want to skip ahead to number 4 because of this. It helps to remember that in programming, you can be an expert and still have to resort to numbers 1 and 2 on this list! Coding languages are constantly evolving, so as programmers, we have to be okay with constantly learning. That's why we love it, right?

When my class had our first chat with Career Services, we were told that those who were most successful in finding a job once they graduated had a similar pattern of thinking: they were confident that if they didn't know something, they could figure it out. That is essentially what we are training ourselves to do when we use the Personal Empowerment Protocol. We are teaching ourselves that when we actually try and solve a problem on our own, we are surprisingly capable of more than we originally thought. It's a positive cycle where we gain more confidence that we can do it again in the future.

There's nothing wrong with asking for help; however, that shouldn't be our automatic way of approaching problems. What happens if someone can't help us in the ways that we're looking for? The long-term cost of foregoing self-agency can be that we give up more easily when we can't get help from others, rather than taking things one error at a time on our own.

If you give it some practice, the Personal Empowerment Protocol will make you a better programmer in the long-run. I guarantee it!

If it ain't got errors, break it!

Kirsty Brewster — Thu, 17 Dec 2020 15:02:41 +0000

When I started my first coding project at Flatiron School, I got this feeling that I hadn't felt in a long time. It was this itch to keep coding because I was enjoying myself so much. I wanted to add more and more functionality to my project. I told friends and family that the last time I remembered having that feeling was when I played the saxophone in high school.

Back then, I would practice everyday for hours on end, and nobody had to tell me to. I wanted to practice.

I really started to progress in my playing abilities during my sophomore year. I didn't even notice until one day, while I was practicing some audition music, I heard outside my practice room, "Who's that playing?".

A head poked through the door. "Oh! You sound really good."

Not gonna lie, it felt really good to hear that and it did boost my confidence.

But there's a fine line to walk between confidence and fear.

At some point I started to develop the identity of a "good" saxophone player. To the point where I didn't allow myself to try and learn new things on saxophone because doing so would make me a beginner again and I'd be "bad" at playing my instrument. Unless it was something that was put in front of me that I had to learn how to play, I didn't venture out and learn new things. I didn't get creative. I was very rigid. Not surprisingly, playing the saxophone started to become less fun.

When I was working on a mini coding project last week, I got all of my main deliverables to work. Great! I had some extra time, so I thought of trying things that were outside the scope of what I knew so far.

Maybe I should try to add a login screen. Maybe I can work on the design and make this website look pretty. Maybe I can try to embed some videos on my website.

Short of a few half-hearted attempts, I didn't try any of those things.

Looking back at my project, I wish that I had ventured out and really tried out some of those ideas, even if they didn't work out in the end. Unfortunately, I had gotten that similar feeling of when I played the saxophone: I didn't want to be bad at coding. My code was working! Why mess with it?

But I should've messed with it. That's the only way to get better. I have to keep reminding myself that it's okay to break my code. My classmates and I are reminded in class to view errors as the default for our code. If we see errors, that's a good thing! We're learning what to do and what not to do. And the errors are guiding us.

I'm inspired by my classmates because I see them get creative and try new things. It's pushing me to do the same. You can't be creative if you're afraid of being wrong.

I wish that I had learned this back when I was a little band nerd in high school. It would have probably prevented me from burning out. I was just too perfectionistic and I never allowed myself a day off from practicing. Now, when it comes to coding, I know to allow myself mental breaks and to allow myself to break things.

Coding is way more fun that way.

I still pick up my saxophone to play now and again, but now I just do it for the enjoyment. :)