DEV Community: amsfreeman

Imposter Syndrome and the Final Phase of a Coding Bootcamp: Inevitable Perhaps, but Possible to Overcome?

amsfreeman — Fri, 18 Aug 2023 19:59:09 +0000

In my previous blogs, I have not had much of a chance to introduce myself, as I have spent my time focused on what I was learning, and tackling difficult coding topics.

However, I just finished week 13 of my 15 week bootcamp and I am in the final "phase" of my bootcamp, so I felt like it would be a good time to step back and talk a bit about myself, how I got here, and dealing a bit with the stress and imposter syndrome that I am feeling.

Firstly, to briefly introduce myself. My name is Amelia, or Amy to my friends, and I am 30 years old. I currently live in Kansas City, MO, but recently returned from living in Munich, Germany for about a year and a half. While I was there, I learned German, and also considering trying to get experience in coding, but it did not work out. When I returned to the US, I was discouraged and unsure what to do next. I had always had this interest in coding and software development. But was it really the right path for me?

I began by working on coding independently, but it was hard to stay on task day after day with many other things in life pulling my attention away.

That is when I decided a bootcamp would be a good fit for me. I did tons of research on different bootcamps, making excel spreadsheets, and looking at career outcomes, schedules, and other data. Ultimately, Flatiron felt like a great fit for me. The schedule matched something that was achievable for me, and the career services and prospects seemed good as well.

So far in this bootcamp, there have been numerous ups and downs. But I should have seen that coming. In our introduction, we were warned about imposter syndrome.

Merriam-Webster dictionary defines imposter syndrome as, "a psychological condition that is characterized by persistent doubt concerning one's abilities or accomplishments accompanied by the fear of being exposed as a fraud despite evidence of one's ongoing success"[1].

I personally feel like Flatiron explained it just as well as Merriam-Webster if not better. They explained that when you do not know what you do not know, you can feel okay with not knowing, but once you start to know some, and you realize all that you do not know, you will start to feel this imposter syndrome. It will come both in comparing your knowledge to the full knowledge you hope to gain, and in comparing yourself to others.

Imposter syndrome has confronted me week after week, and I have continuously had to decide if I should listen to it or ignore it.

I will admit, there were times where I fell into doubting myself, doubting my abilities, and worse of all, feeling like I would never learn enough or know enough. But I had to keep moving, and not stay stuck in these feelings, as due to the pace of the bootcamp, there was always more work to do and more to learn.

Trying again the next day (or something even later that night) became a cornerstone of my work at Flatiron. I learned that moments of discouragement and imposter syndrome would occur, but that the key for me lay in being able to feel those feelings, and then set them aside and keep on working.

In short, the only way out was through.

Now I am in the final phase of my bootcamp. This phase has no more labs to do, no more mandatory lectures, no more new things to learn. Instead, now it is time to show what I have learned.

This has felt quite daunting. A whole project, all by myself? Impossible! The imposter syndrome is strong. Am I doing enough work day to day to reach MVP in time? Is my work good enough? Unique enough? Impressive enough?

Doubts lurk around every corner. Luckily, my process from my work throughout the bootcamp has come back to me. I can have these thoughts of doubt, feel like an imposter, but I have to keep going, keep working, and most importantly keep coding!

Many people in my bootcamp have expressed some form of imposter syndrome at some point in these first 13 weeks of the bootcamp. So while it may not be universal, it is common.

In this final phase, with this final project, the stakes feel higher, the mountain looks bigger, the risk of failure feels worse. But just as before, the only way out is through.

Here's to getting through.

(Cross posted on Medium at: Imposter Syndrome and the Final Phase of a Coding Bootcamp: Inevitable Perhaps, but Possible to Overcome?).

References:
[1] Author unknown. "Impostor syndrome
noun." Merriam-Webster Dictionary. https://www.merriam-webster.com/dictionary/imposter%20syndrome?utm_campaign=sd&utm_medium=serp&utm_source=jsonld (accessed August 18, 2023).

Help! Something isn't working and I don't know why! : An introduction to console.log and ipdb

amsfreeman — Thu, 10 Aug 2023 11:12:42 +0000

In my current software development program we began working in JavaScript and then later in React, and I often found myself struggling to understand why something wasn't working with my code. I would often code and code and then finally look at the browser and be beyond confused when my code didn't work how I thought it would. Or would, there were errors, and the browser wouldn't load at all!

That is when I remembered we had been introduced to a particular function to help us. That is:

console.log()

According to GeeksforGeeks, console.log() is defined as, "The console.log() is a function in JavaScript that is used to print any kind of variables defined before in it or to just print any message that needs to be displayed to the user."[1]

Now what does that mean exactly?

The simplest way to understand console.log() is to think of it as a helper function, where anything you need to test can be printed to the console.

But what is the console?

The console is a something that can be accessed from most internet browsers and allows you as a developer to test JavaScript.[2]

In the console one can type and execute JavaScript code.[2] This allows one to test various functions and other aspects of their code. Additionally and more importantly for this blog, the console can print messages from the code that have been console.logged.

How does this help us? If we use console.log() as we code, we will be less likely to hit an error that we don't understand at all or make it too far while coding incorrectly.

Console.log() can be used as such:

console.log("Does this work?")

In this cause the console.log could be placed inside a larger block of code to check whether or not the code has run correctly.

Console.log() could also be used to log something that you don't know what it is. For example with an event listener, the console.log() function can be used as such:

console.log(e)

Here the console log will log the event object that comes from the event listener. Once you have access to that event object you can look at it and decide what to do next.

The true importance of console.log() come in the more you use it. Anytime you need to understand what is going on in your code in JavaScript it is a very helpful function to figure it out!

So that was all well and good for me while working in JavaScript. I learned to really appreciate and use console.log() a lot. But then we moved on to working on python. Without a browser, console.log() was gone.

With python, I could print things to the command line using the print() function. Quickly, I learned that print() can help.

For example, if I hit a print() statement, I know my code has at least gotten to that point. Additionally, without the browser print statements can be helpful to know what is going on. For example when running a seed file to seed a database, adding print statements along the way allows one to see what is going on, and a final message saying something like successfully seeded can help one to know that the database should now be seeded with the seed information.

But I still felt somewhat lost without console.log(). How could I know what variables, functions, and other items I have access to and how they are working?

In came ipdb. Unlike I originally jokingly thought, ipdb is NOT the internet potato database. No, instead ipdb is more similar to debugger in JavaScript in that it is actually a breakpoint in the code. But as I hadn't used debugger in JavaScript much, this reminded me more of console.log() in that it also shows one that they have made it to a specific point in the code and can allow one to inspect something.

Unlike console.log() ipdb is not automatically available. It must be imported as shown below:

import ipdb

Then in your code you can type ipdb.set_trace() at any point. This will stop your code, and push you into the ipdb session. Here you can test variables and functions.

Ipdb is certainly not exactly the same as console.log(), but it did help me a lot while feeling adrift in the beginning with python.

Now in my program, we are starting to work with full stack application, allowing me to use ipdb and console.log in the same project! This has allowed me to really see and appreciate the strengths and drawbacks of both, and I am happy to have both tools to help me with my coding!

(Cross posted on Medium at: Help! Something isn't working and I don't know why! : An introduction to console.log and ipdb).

[1] Author Unknown. “JavaScript console.log() Method.” GeeksforGeeks. https://www.geeksforgeeks.org/javascript-console-log-method/#article-meta-div (accessed August 10, 2023).

[2] Lisa Tagliaferri. "How To Use the JavaScript Developer Console." DigitalOcean. https://www.digitalocean.com/community/tutorials/how-to-use-the-javascript-developer-console (accessed August 10, 2023).

The Importance of Props in React

amsfreeman — Thu, 27 Jul 2023 14:10:40 +0000

In my software development bootcamp, we first learned Vanilla JS, before moving onto React. When learning React one of the first thing I encountered was passing props. Props? What were those? Here I will walk through what props are, and how to pass them.

Props is short for properties, and they allow one to pass information from a parent component to a child component. A parent component returns a child component. Props is the only way the child component can have access to data from the parent component. Props therefore is data passed from the parent to the child component, which allows the child component to make use of this data.

Additionally it is important to note, this props information flow can only go one way: Parent -> Child. Props cannot be passed like this: Parent <- Child. There is a way to pass information from a child component to a parent component, which is called reverse information flow, but unfortunately it is not as easy as props!

Now let's get into the passing of props.

Let's say we have a component called App, which is our top level component. In the below example, it has access to a books array, which was fetched from a localhost. App will then pass the books array to the child component BooksContainer within the return.

import {useState, useEffect} from React

function App() {
  const [booksArray, setBooksArray] = useState([])


  useEffect(() => {
    fetch('http://localhost:4000/books')
      .then(r => r.json())
      .then(allBooksArray => setBooksArray(allBooksArray))
  }, [])

  return (
    <div>
      <BookContainer booksArray={booksArray}/>
    </div>
  )
}

Next our child component will accept the props. There are two ways to do this. The first way is that the child component can accept the props using the key word props. That would look like this:

function BookContainer(props)

If props are accepted like this, props will need to accessed by typing props.(whatever) whenever they are used within this child component. Below is an example of using this syntax.

function BookContainer(props) {
  return (
    <div>
     {props.booksArray}
    </div>
  )
}

This works perfectly well and maybe be easier to understand as one is getting started working with props.

Another way to handle receiving props on the child component side is to destructure props. In this case the child component still accepts the props, but instead a {} is added and the name of the props is used. Below is an example of this.

function BookContainer({booksArray}) {
  return (
    <div>
     {booksArray}
    </div>
  )
}

This way may look a bit confusing at first. The props keyword is gone! But ultimately, destructuring props makes our work in the child component easier (no typing props.(whatever)!) and it make the code look cleaner.

Okay, so now we have our BooksArray in our child component. Yay! But it is still just an array! How can we get access to what is in the array? We need to map through it, which was the topic of my last blog (When and how to use forEach and map in Vanilla JS vs React by Amelia Freeman).

After that, we will pass props to our next child component Book, and finally we will return our bookComponents.

We can do that as below:

function BookContainer({bookArray}) {
  const bookComponents = bookArray.map(book => {
    return (
      < Book
        key={book.id}
        id={book.id}
        title={book.title}
        author={book.notes}
        summary={book.summary}
      />
    )
  })
  return (
    <div>
      {bookComponents}
    </div>
  );
}

Let's break this down a bit.

In this line we are accepting our props. Note they are destructed, as we have ({bookArray}) and not (props).

The next line {}> starts our map. Here were a creating a variable bookComponents, which hold all our books. We are then mapping through the book array.

Then in the <{}> we doing our actual mapping.

We are saying in the case below, that for each book, we want to return a title, an author, and a summary. We will also need each book to have an id. Finally, each book must have a key, which is required by React as a unique identifier.

(book => {
    return (
      < Book
        key={book.id}
        id={book.id}
        title={book.title}
        author={book.notes}
        summary={book.summary}
      />
    )
  })

Finally as mentioned above, the bookComponents are returned as so:

 return (
    <div>
      {bookComponents}
    </div>
  )

Next, we can accept props in our child component Book. That looks like this:

function Book({title, author, summary}) {
  return (
    <div>
      <h3>{title} </h3>
      <h4>{author}</h4>
      <p>{summary}</p>
    </div>
  );
}

Again, let's break this down. Our child component Book is accepting props, which here have been destructured into title, author, and summary. Finally, we are taking our props and returning them on our page. Title will be an

header, author and

header, and summary a

paragraph.

There are two slightly different ways to pass props from the parent component BookContainer to the child component Book, both of which are outlined below.

Alternate 1:
We could simply pass our whole book object from our parent component down to the Book component. We still do need to set the unique key here in the parent component BookContainer. If we wanted to do it this way, it would look like this:

function BookContainer({bookArray}) {
  const bookComponents = bookArray.map(book => {
    return (
      < Book
        key={book.id}
        book={book}
      />
    )
  })
  return (
    <div>
      {bookComponents}
    </div>
  );
}

When our child component book accepts the props, we would then need to pull out what we need (id, title, author summary) on the other side, in the Book component.

That would look like this:

function Book({book}) {
const book = {title, author, summary}
  return (
    <div>
      <h3>{title} </h3>
      <h4>{author}</h4>
      <p>{summary}</p>
    </div>
  );
}

Alternate 2:
The other thing is that we could use the props key word instead. We still do need to set the unique key here in the parent component BookContainer.

That would look like this in the parent component BookContainer:

function BookContainer({bookArray}) {
  const bookComponents = bookArray.map(book => {
    return (
      < Book
        key={book.id}
        book={book}
      />
    )
  })
  return (
    <div>
      {bookComponents}
    </div>
  );
}

And like this in the child component book:

function Book(props) {
  return (
    <div>
      <h3>{props.title} </h3>
      <h4>{props.author}</p>
      <p>{props.summary}</p>
    </div>
  )
}

As you can see passing props can be done a few different ways. Whichever way you understand best is a great way to start! As you continue to work in React and pass props, you will figure out which way works best for you!

Passing props is a vital piece to understand working in React. Only be understanding passing props, can we move onto reverse information flow and other more complicated aspects of React.

Hopefully this helps to give an introduction to props!

(Cross posted on Medium at: The Importance of Props in React).

When and how to use forEach and map in Vanilla JS vs React

amsfreeman — Mon, 26 Jun 2023 03:01:29 +0000

When I began learning to code in my software development bootcamp, we started with Vanilla Javascript. By the end of three weeks, I started to feel some confidence with Vanilla JS. I knew lots of ways to accomplish things, and I felt relatively comfortable with syntax. Then came React, and a whole new process to learn. Some old friends made reappearances, but there were many new things to learn. Today, I am going to talk about one of the things that took me awhile to fully grasp, and hopefully shed some light on this difference to others.

When learning Vanilla JS, forEach() was a trusted and helpful friend. Whenever, I needed to iterate through an array of objects and get information from each object in the array, forEach() was there for me. I seemed to use it constantly.

As an example of its usage, I would sometimes have information coming from an API or another source such as a db.json. Let's say that information was an array of book objects, and each book object had an id, a title, an author, and a rating out of 5.

So if I had this array of objects as shown below:

"books" : [
{
"id": 1,
"title": Little Women,
"author": Louisa May Alcott,
"rating": 4
},
{
"id": 2,
"title": The Picture of Dorian Gray,
"author": Oscar Wilde,
"rating": 4
},
{
"id": 3,
"title": Moby Dick,
"author": Herman Melville,
"rating": 3
},
{
"id": 4,
"title": Wuthering Heights,
"author": Emily Bronte,
"rating": 4
}
]

[1].

I could then iterate through my books with a forEach() loop and console log them as shown below:

function allBooks(arrayOfAllBooks){
  arrayOfAllBooks.forEach(book => {
    console.log(book)
})}

[1].

Perfect, wonderful!

However, there is an issue when working with React JS. Namely, forEach() returns undefined. On the other hand, map() works wonderfully in React as it returns a new array! Additionally, forEach() cannot be used with other array methods, but map() can. This allows map() to be used with array methods, such as filter(), which is also important in React[2].

Below there is a great way to use map in React, while using the same book data from above. The book container will contain all the books in the book array. The book components will take the full book array and map through it, returning book card after book card until the process is complete. In the mapping, passed down to the book card component will be each book, with an key, id, name, author, and rating. Finally, the book components will be returned inside of a div.

function BookContainer({bookArray}){
  const bookComponents = bookArray.map(book => {
    return(
      <BookCard 
        key={book.id}
        id={book.id}
        name={book.name}
        author={book.author}
        rating={book.rating}
      />
    )
  })
  return (
    <div>
      {bookComponents}
    </div>
  );
}

So we can see the importance of map() in React JS, versus forEach() in Vanilla JS. However, it should be noted that forEach() can still be used in certain scenarios in React JS. For example, forEach() can be used when you need to call a function for every element in an array. In this case, forEach() cannot be used within JSX, but must be used outside of it [3].

Ultimately, we can see the power of forEach() in Vanilla JS and map() in React. Knowing the difference between these and being able to explain why one should be used versus the other is important, and makes coding easier. While it took me some time to understand these differences, I feel that I am now well on my way to a deeper understanding, and look forward to using this knowledge to help my coding, both in Vanilla JS and React.

(Cross posted on Medium at: When and how to use forEach and map in Vanilla JS vs React).

[1] Author Unknown. "5 Ways Javascript Loop Through Array of Objects." Tutorials Tonight. https://www.tutorialstonight.com/javascript-loop-through-an-array-of-objects#foreach-loop (accessed June 25, 2023).

[2] Imran Alam. "What is difference between forEach() and map() method in JavaScript?" Tutorials Point. https://www.tutorialspoint.com/what-is-difference-between-foreach-and-map-method-in-javascript#:~:text=The%20map()%20method%20is%20used%20to%20transform%20the%20elements,used%20with%20other%20array%20methods (accessed June 25, 2023).

[3] Borislav Hadzhiev. "How to use the forEach() method in React." bobbyhadzblog. https://bobbyhadz.com/blog/react-foreach (accessed June 25, 2023).

A brief introduction to the lang tag and its importance

amsfreeman — Mon, 12 Jun 2023 02:08:00 +0000

As someone who recently returned to the US after living in Germany for a year and a half, and spent the majority of my time there learning German, I was immediately interested in a particular line I saw consistently in the head section of HTML.

That would be:

<html lang ="en">

Thoughts immediately popped into my brain. Could I write in another language? Which languages? How would this affect syntax and other HTML functionality?

I knew I had to know more.

After some simple googling, MDN Web Docs came to the rescue with this information,

"The lang global attribute helps define the language of an element: the language that non-editable elements are written in, or the language that the editable elements should be written in by the user. The attribute contains a single "language tag" in the format defined in RFC 5646: Tags for Identifying Languages (also known as BCP 47)"[1].

Okay, but how does that help us?

We now know which language this HTML code is in. As indicated in the above example, the language is English.

There is also the option for language subclasses, for example the below code would be considered British English and read in a British accent by a screen reader, if supported [2].

<html lang="en-GB">

But this extends far beyond English. Many languages are supported!

Language is indicated by the language subtag, which is a 2 or 3 character code. This code only indicates the basic language[1]. But as seen from [2] there are also options for subclasses such as British English ("en-GB") or US English ("en-US").

Another interesting piece that I discovered is that the 2 or 3 character code for each language is not the language as we would write it in English, but rather the language as it would be written in that language itself. IE., German's language subtag is "de" for Deutsch, which is the word German written in German. Spanish's language subtag is "es" for Español. And it goes on and on!

Furthermore, languages can be changed throughout the document, allowing the user to indicate a portion of text written in another language. In this case the lang tag can be embedded in other tags [2]. This could be especially helpful in a website with a portion in another language, or even a single word in another language contained within a larger text.

These language tags do not just help the initial software developer who writes the code, and all others who read it; it also helps accessibility, allowing a screen reader to know what language the webpage is written in and provide the best possible experience for someone using a screen reader [2].

Additionally, as indicated in [3] language identification allows a number of things to happen automatically. These include, "changing the look and behavior of a page, to extracting information, to changing the way that an application works" [3]. This in turn gives the user the best possible experience.

This post contains a basic overview of some of the benefits of using the language tag, as well as some of its functionality. There is still a wealth of information and details regarding the lang tag out there, and it is my hope in the future to continue to delve into this topic.

(Cross posted on Medium at: A brief introduction to the lang tag and its importance).

References:
[1] Author unknown. "HTML : lang." MDN Web Docs. https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/lang (accessed June 11, 2023).

[2] Author unknown. "Language Tags in HTML." PennState Accessibility: Accessibility and Usability at Penn State. https://accessibility.psu.edu/foreignlanguages/langtaghtml/#:~:text=The%20LANG%20tag%20(i.e.%20the,WCAG%202.0%20Guideline%203.1 (accessed June 11, 2023).

[3] Author unknown. "Why use the language attribute?" W3C Internationalization: Making the World Wide Web worldwide. https://www.w3.org/International/questions/qa-lang-why. (accessed June 11, 2023).