DEV Community: charlesshrout

Imposter Syndrome 2.0

charlesshrout — Mon, 12 Dec 2022 18:57:05 +0000

In your first week of learning to code you will discover a common feeling among all software engineers, imposter syndrome. The almost inescapable fear that you do not and will never belong in the coding world. This feeling comes usually with learning any new material in a coding language. It's complex, foreign, and makes you step out of your comfort zone. Eventually, you come to accept and familiarize yourself with this constant never-ending building of knowledge off of previous knowledge and the imposter syndrome that was once so prevalent begins to fade away. At this point, many will feel their battle with this mindset is over and that the worst is behind them. In reality, a new feeling of not belonging will arise. I call it imposter syndrome 2.0.

This variation of feeling like an outcast will come in the form of debugging. It is the frustration of believing your code should be functioning properly yet it remains broken. Spending what feels like endless hours looking for some flaw in the logic or a syntax error that is not being directly reflected in the error messages. You will have nights where you spend an entire evening trying to fix a bug but fail to make any progress. This is where the second level of imposter syndrome kicks in. Failing to find a bug breaking your code will lower your confidence and in return make you question your ability to code in general. I am here to tell you this is a COMMON feeling and you should be grateful for the experience! Why? Because it is in that rabbit hole of searching but seemingly never finding an answer that you learn the most.

 def update
        shop = Shop.find(params[:id])
        if shop
          shop.update(shop_review)
          render json: shop
        else
          render json: { error: "Shop not found" }, status: :not_found
        end
      end

In my latest project (a coffee bean website), we needed to create an update method to allow the user to rate a coffee shop out of 10. Before actually approaching the execution of the code, I told myself this was going to be a fairly easy part of the project and would not take much time at all (20-30 minutes max). Needless to say I was wrong and it ended up taking an entire evening and half of the next day in class to end up functioning properly. While immensely frustrating, during that time I researched and learned more about not only this particular issue, but also overall knowledge of rails and how the back end responds to the front. Without receiving this error I would have never taken so much time to research a particular aspect of rails that will now help me in future projects! It turns out, we were missing a parameter permit for a table in the backend to be passed through another table controller.

        def shop_review
            params.require(:shop).permit(:review)
        end

All we needed to do was require the table of ":shop" BEFORE permitting ":review", an attribute of shop.

The main point for identifying another variation of imposter syndrome is not to scare away anybody who wants to learn to code, but rather explain that this is another common feeling that is not worth giving up over. Do not view an entire evening working to fix one bug as a "waste of time". Instead, take it as an opportunity to work on your debugging process and to look at mistakes as guides to eventually achieve clean, functioning code!

Understanding Project Management

charlesshrout — Mon, 21 Nov 2022 17:23:14 +0000

I, like most people, love the feeling of coming up with a project idea. Whether it be the project as a whole or the process of creating an idea chart with all the deliverables being written out, being able to plan out everything can be extremely satisfying. What's not as fun is the execution of the plan, especially when you're working with a group. Once the planning phase of the project is done, it can be difficult to determine what gets done first and (if you're in a group) who is doing what. In my phase 3 project, we encountered several of these types of issues.

Just like in most group projects, coding projects take lots of time and communication so it's important to be honest to other group members about what your capability is in regards to the deliverables required for that project. Additionally, it is even MORE important to have patience and respect with other members of the project, even when things are not going according to plan. Communicating frustrations or confusions effectively is the key to a healthy team dynamic. Take this block of code for example:

require 'pry'
class ApplicationController < Sinatra::Base
  set :default_content_type, 'application/json'

  # Add your routes here
  get "/post" do
    post = Post.all
    post.to_json
  end

 get '/posts/:id' do
  post = Post.find_by(id: params[:id])
  post.to_json
 end


  patch  "/posts/:id" do
    post = Post.find(params[:id])
  post.update(
    like_button: params[:like_button]
  )
  post.to_json
  end 

  delete  "/posts/:id" do 
      post = Post.find(params[:id])
      post.destroy
      post.to_json
    end

  post '/posts' do
    post = Post.create(
      phase: params[:phase],
      topic: params[:topic],
      location: params[:location],
      thread_post: params[:thread_post]
    )
    post.to_json
  end

  private
  # def post_params

  # end
end

This is the controller file we used to connect our back and front end together. While it really isn't a lot of code, the logic behind understanding how this sends and receives responses to and from the front end was essential to get our project running. Because of this, it was just as essential to make sure I knew exactly what my group member who was in charge of the back end was doing so I could adjust the front end accordingly. While we did not experience any huge merge conflicts, other groups around us did even some resulting in a deletion of important code. Simple solutions, such as being in the same room as your group while working, could have prevented these merge conflicts. Learning from mistakes is a necessary step in becoming successful in any career path, but proper and effective communication is what will truly set one apart from the rest.

Keeping it Simple

charlesshrout — Tue, 11 Oct 2022 04:34:06 +0000

If you had asked me a month ago to describe coding in three words they would have been something along the lines of direct, independent, and tiresome. I can now confirm only three weeks in that one of those words is accurate and I will let you guess as to which.

Learning to code has been one of the most difficult experiences in my life. This is mainly because in order to learn how to code, you need to think like coder first. Understanding this method of thinking is a strenuous task, especially when you only have a matter of weeks to figure it out. I found myself (and most of my cohort) feeling behind schedule and scared of failing within the first few days of class. Luckily, I had people around me reminding me that this is a common feeling when first learning to code and that I just simply needed to push through and keep trying. So that's what I did and eventually what I was learning and exposing myself to everyday was starting to make sense! Where I really started to understand more, or my "aha moment", was when I realized that coding is abstract.

You are not always going to understand why exactly one line of code works one way and another works a different way. Take this block of code for example:

const fetchReq1 = fetch ("http://localhost:3000/data")
.then(res => res.json())
.then(strainArray => {
    strainArray.forEach(strain => {
        buildMenu(strain)
    })
    strainDetails(strainArray[0]);
    setupCart();
})

It took me longer then I want to admit to fully grasp that JavaScript automatically knows that strainArray is the entire object of data being fetched because of the .then. With the .forEach(), JavaScript knows that strain is the parameter that represents every object within the array being iterated. And on top of that, if you included an undefined function within the .forEach() and pass the strain parameter as its argument, it will remember that parameter and its data when you write out the function later in the code. Such a simple concept in hindsight but because I was so dedicated to know how exactly JavaScript knew to do that, I remained confused for what felt like endless hours. Eventually I just accepted it as part of the language and something I would need to remember.

This is when I started to change my method of thinking when viewing code. It is more important to try to find the simplest solution than just a solution. In order to do this, you have to take a step back and view your project as a whole from time to time. It is incredibly easy to get lost on just a few lines of code that eventually can turn into something ugly. Look at this function:

const reset = function() {

        document.getElementById('strain-in-cart').innerHTML = 0;
        currentStrain.number_in_bag = 0;
}

At one point this function was 15+ lines long because I couldn't figure out why when I tried to clear the value of my "in-cart" number, my code only ended up visually showing a 0 but the original value still existed under the hood. As it turns out all I needed to do was target two separate areas of my code and set it to 0 (my db.json and the html). My mistake here was that I focused too much on adding layers to my code to fix the issue instead of taking a step back and seeing what could be accomplished in as few lines as possible.

Thinking about my next three weeks ahead, I have a goal I want to reach by my next blog post. My goal is to get to a point in my code where not only I am able to understand what it says, but am able to explain my code clearly and efficiently to collaborating teams members and instructors. If I start practicing clear communication with my code now, I believe it will help me immensely in my first job as well as prevent any bad coding habits.