DEV Community: Briggs Elsperger

Understanding Callbacks

Briggs Elsperger — Tue, 15 Mar 2022 21:27:29 +0000

Understanding Callbacks

Callbacks seem to be a sticking point for people new to programming. Put simply, callbacks are functions that are passed into another function as an argument. With the many ways one can define a function in JavaScript, it's no wonder why callbacks get confusing.

Anatomy of a Function

JavaScript has many ways of defining a function, but they all follow a similar pattern and have the same pieces, they just look a bit different. There is more technical terminology surrounding functions, but we are going to gloss over them for now. (If you are interested, feel free to look up "Function Declarations" and "Function Expressions").

Normal Functions (Named Functions)

Normal functions, probably the first way you learned about creating functions. Understanding the anatomy of these will help you understand the other types of functions as well.

function funkyFunction(music, isWhiteBoy) {
  if (isWhiteBoy) {
    console.log('Play: ' +  music);
  }
}

This is actually called a function declaration and is broken into a few parts.

The function keyword
- This tells the JavaScript compiler you are making a named function
The name
- This is the name of the function, and what you will use when you call it. It is also used in stack traces.
The parameters
- everything between ( and ) is a parameter, these must be separated by commas if there is more than one. There may also be nothing between the () if the function does not take any parameters. The parenthesis are required.
The function body
- This is where the function actually does something. This code gets run with whatever values are passed into the parameters.

Calling a function looks similar to declaring it. When you call the function, you type the name of the function and add () after. (without the function keyword and the body). Inside the () you may pass it the values you want the parameters you defined to represent. These arguments are used like variables inside the body of the function.

// Calling a function
funkyFunction('that funky music', true);

// This prints "Play: that funky music" in the terminal.

Anonymous Functions

These are very similar to normal functions, with just a few differences. Anonymous functions are not 'named', and have a few different syntaxes. Even though they cannot have a name, they can be assigned to a variable. Even though when assigned to a variable they show up in stack traces, they are still considered an anonymous function. They may show up as 'anonymous function' in stack traces when passed into other functions as callbacks, however.

Anonymous functions are mostly used by passing them into other functions as a callback. This will become more clear later.

Each of the functions below are identical to the funkyFunction above in their 'funk-tionality'

// This example is still an anonymous function even though we used the `function` keyword, as it doesn't have a name.
const funkyFunction = function(music, isWhiteBoy) {
  if (isWhiteBoy) {
    console.log('Play: ' +  music);
  }
}

// This is called an arrow function, we'll get into these soon.
const funkyFunction = (music, isWhiteBoy) => {
  if (isWhiteBoy) {
    console.log('Play: ' +  music);
  }
}

An anonymous function is just a function that does not have a name, this doesn't mean that it cannot be called. Each of the above functions can be called exactly the same way:

funkyFunction('that funky music', true);

And this is because functions are 'first class citizens' in JavaScript and can be assigned to variables. Or passed as an argument to another function.

Arrow Functions

These are just a shorter way to write a function. They do have some special rules however, and understanding the rules imposed by arrow functions will help you understand callbacks. We're going to ignore the this binding rules for these functions for now.

If there is only one argument, the parenthesis () can be omitted
if arrow functions are one line, the brackets {} can be omitted.
- When omitting the brackets, the arrow function returns the evaluated expression without requiring the return keyword.

The functions below are variations of the rules above

const playThe = (funky) => {
  return funky + " music";
}

const playThe = funky => {
  return funky + " music";
}

const playThe = funky => funky + " music";

// You can call all of these functions like: `playThe('blues')`

Below are some examples of an arrow function without an argument. These functions are all identical as well. Notice the () in place of any named arguments. It is required because there aren't any parameters.

const playThat = () => "funky music";

const playThat = () => { return "funky music"; }

const playThat = () => {
  return "funky music";
}

Key Point

Take some time and study the function examples above and note how they are similar and how the same parts exist in both, with the exception of the function keyword.

What Callbacks Look Like

You most likely have seen, or even used, callbacks and not realized it. They are used frequently in JavaScript. Understanding JavaScript is impossible without understanding callbacks. Below is an example of something you may have run into before.

const notes = ['do', 're', 'me'];

notes.forEach((note) => console.log(note));

This is the forEach array method. This method simply takes a callback function as its argument. (Don't forget that forEach is a function itself).

There are many other ways to do the same thing (as is tradition in JavaScript), below are a few more ways to write this code:

const notes = ['do', 'ray', 'me'];

notes.forEach((note) => { 
  console.log(note);
});

notes.forEach(function(note) {
  console.log(note); 
});

// This one is tricky, but will make more sense later
notes.forEach(console.log);

How Callbacks Work

To state it once more: Callbacks are just functions passed into other functions as arguments (as a parameter).

Iterator Functions

Below is what forEach might look like under the hood, notice it calls the callback function each time it loops over an item.

function myForEach(array, callback) {
  for (let i = 0; i < array.length; i++) {
    callback(array[i]); // This is when the callback function gets called, or executed
  }
}

// You would call it like this:
const myArry = [2, 3, 4, 2];
myForEach(myArry, (item) => {
  console.log(item + 2); 
})

WHOA, hold up. Where did item come from?

This came from the function myForEach calling the callback with an argument. The line with callback(array[i]) is calling the callback function with an argument, which we defined inline as an anonymous function. Below are more examples of how this could be called.

const myArry = [2, 3, 4, 2];

// We do not need the `()` in this case, as we only have one argument and we are using an arrow function
myForEach(myArry, item => console.log(item + 2)); 

// We can pass arguments to this kind of anonymous function as well
myForEach(myArry, function(item) {  
  console.log(item + 2) 
});

// This time we are declaring the function we want to use as a callback
// Notice we define `item` as a parameter to be passed in when it's called by the `myForEach` function.
function printItemPlusTwo(item) {
  console.log(item + 2);
}

// `item` is passed into the function, we do not need to declare it here because we declared it elsewhere. 
// It is the same as the 'console.log' example above except we declared our own function.
myForEach(myArry, printItemPlusTwo);

Another good example of how callbacks work might be the .map method (read more on MDN), below is one way it might be implemented.

function myMap(array, callback) {
  const myNewArray = [];

  for (let i = 0; i < array.length; i++) {
    const callbackResult = callback(array[i]);
    myNewArray.push(callbackResult); 
  }

  return myNewArray;
}


// This could be called like this:
const addedArray = myMap([1, 2, 3], (arrayNum) => {
  return arrayNum + 2; 
});


// OR
const addedArray = myMap([1, 2, 3], (arrayNum) => arrayNum + 2)

Event Listeners (DOM)

Event listeners in JavaScript seem to be confusing to people, but after understanding callbacks, these should be a lot easier to understand.

Let's review what they look like, see if you can pick out the different things going on.

const element = document.querySelector("#myId");
element.addEventListener('click', (event) => {
  console.log(event.target.value);
  // `event` is passed into the callback from the `.addEventListener` function when it receives a 'click' event.
});

If you notice, the second argument (value you pass into a function) to addEventListener is a function. In this case it's an anonymous arrow function. This piece of code could have also have been written like this and it would behave identically.

const element = document.querySelector("#myId");
element.addEventListener('click', function(event) {
  console.log(event.target.value);
});

Part of what confuses people is the event object. Where does it come from? How does it get there?

This event object is passed into the callback function by the .addEventListener function. A function is calling another function.

This is because.... Callbacks are just functions passed into another function as arguments.

That means we can declare a function outside of the argument list and just add it by its name as well. Like so:

function myEventHandler(event) {
  // do something, probably with 'event'
}

const element = document.querySelector("#myId");
element.addEventListener('click', myEventHandler);

Notice how we didn't 'call' the function called myEventHandler? If we were to call it inside the parameter list, the function we called myEventHandler would run immediately and give the addEventListener the result of calling that function. (in this case, it would be undefined)

Conclusion

Callbacks are an important part of JavaScript, they are vital to understand, even with the onset of promises and async/await. Callbacks get called by another function, so you don't have to call them in the arguments, ( Calling a function is using a function's name and adding () to the end of it, like console.log() )

These are something that you will learn if you give yourself time, understanding how they work will make your JavaScript career a lot easier!

Early Return Pattern

Briggs Elsperger — Tue, 15 Mar 2022 21:25:06 +0000

Early Return Pattern

People new to programming sometimes struggle to understand returning early inside a function, especially early beginners when coming from a language like Ruby, which has implicit returns. Today we're going to explore what an early return is, and what it can be used for in the context of JavaScript.

Understanding `return`

To understand what an early return is, you must first understand what return does in a function. Put simply, return returns a value from the function; it could be anything. In JavaScript you can return anything- a string, an object, or even another function. When a return statement has been found, the function ends immediately and returns the value to whatever called the function.

function timesTwo(x) {
  return x * 2;
}

console.log(timesTwo(21));

In this example you would expect 42 to be logged to the console, and you'd be correct. The timesTwo function returned the result of x * 2 to console.log, and console.log printed the value to the console.

Early Returns

An early return is a return statement that is placed before some other code has been run.

function notFunkyFunction() {
  console.log('... And just when, it hit me, somebody turned around and shouted:')
  return
  console.log('Play that funky music white boy');
}

notFunkyFunction();

This function will only log '... And just when, it hit me, somebody turned around and shouted:' and will never log 'Play that funky music white boy' due to the return statement. Using this, we can do some neat things to make our code look cleaner.

Early Return pattern

Since we can use a return statement to end a function immediately, we can take advantage of it. Let's look at a traditional if else statement and how one might convert it to the early return pattern.

function healthBarColor(health, maxHealth, hasShield) {
  const percentLeft = (health / maxHealth) * 100;

  if (hasShield) {
    return 'blue'
  } else if (percentLeft < 15) {
    return 'red';
  } else if (percentLeft < 60) {
    return 'yellow';
  } else {
    return 'green';
  }
}

console.log(healthBarColor(30, 124, false));

In this case, we will find the value 'yellow' in the console. This looks OK, but it can be cleaner with the use of an early return. Let's refactor healthBarColor to use this pattern now.

function healthBarColor(health, maxHealth, hasShield) {
  const percentLeft = (health / maxHealth) * 100;

  if (hasShield) { return 'blue'; }
  if (percentLeft < 15) { return 'red'; }
  if (percentLeft < 60) { return 'yellow'; }
  return 'green';
}

console.log(healthBarColor(30, 124, false));

This code is functionally the same as the code above, but it is arguably more readable and is shorter. This works because when we return from a function, the function ends then and there and gives us the value we desire. We can clean this up even more though, with a quirk of JavaScript. In JavaScript, if you have an if statement that is one line, you can omit the curly braces ( { } ). That would look like this:

function healthBarColor(health, maxHealth, hasShield) {
  const percentLeft = (health / maxHealth) * 100;

  if (hasShield) return 'blue';
  if (percentLeft < 15) return 'red';
  if (percentLeft < 60) return 'yellow';
  return 'green';
}

console.log(healthBarColor(30, 124, false));

Now we have some clean, and easy to understand code that is still performant.

Gotcha!'s

Although the early return pattern can be very clean, there are times where it is contraindicated, mainly in non-functional style functions.

function attackedHandler(damage) {
  const armorStrength = getArmorStrength();
  let damageValue;

  if (damage > armorStrength) damageValue = calculateDamage(damage, armorStrength);
  if (damage === armorStrength) damageValue = damage - 10;
  if (damage < armorStrength) damageValue = 0;

  applyDamage(damageValue);
  setArmorStrength(damageValue);
}

This looks clean, but is a bad idea because each if statement has to be evaluated, even if the first one is true. This technically isn't an early return pattern, but it does mimic it, even though it is bad practice. To fix this, you would have to use the standard if else statement.

function attackedHandler(damage) {
  const armorStrength = getArmorStrength();
  let damageValue;

  if (damage > armorStrength) {
    damageValue = calculateDamage(damage, armorStrength);
  } else if (damage === armorStrength) {
    damageValue = damage - 10;
  } else if (damage < armorStrength) {
    damageValue = 0;
  }

  applyDamage(damageValue);
  setArmorStrength(damageValue);
}

Another time the early return pattern will not work is when you have to run code after the if else statement. The above code is a good example of this. If you were to return from the function within the if statements, the rest of the function would not run. This is called 'unreachable code' and would introduce bugs and logic errors in your program.

Conclusion

The early return pattern (have I said 'early return pattern' enough yet?), is a popular pattern and something you might see in other's code. Understanding why it's used and when to use it is important when it comes down to using it yourself. Now get out there and use this newfound knowledge to write better code!

P.S.

This pattern can be used with multi-line conditionals as well. The example below is perfectly fine:

function attackedHandler(damage) {
  const armorStrength = getArmorStrength();

  if (damage > armorStrength) {
    let damageValue = calculateDamage(damage, armorStrength);
    return takeDamage(damageValue);
  }

  if (damage === armorStrength) {
    return takeArmorDamage(damage)
  }
}

Conclusion

Briggs Elsperger — Sat, 12 Mar 2022 21:17:56 +0000

The Odin Project is around to help you succeed. The people who wrote the project are professionals and have very successful careers. Among the team are ex-teachers, Red Hat employees, large bank employees, and startup employees. The skills and expertise the team brings together for everyone to learn from is immense. There’s good reason to trust The Odin Project and the team behind it. Now, with that being said, get out there and become a success story.

Strategically building your portfolio

Briggs Elsperger — Sat, 12 Mar 2022 21:17:34 +0000

There is no degree or certification for finishing The Odin Project, but it does leave you with the potential for a killer portfolio. There are times when you should spend extra time on a project, and times when you shouldn’t. Not every project should be a portfolio piece.

Foundations isn’t a strong portfolio generator

People tend to spend a lot of time on the first few projects expecting them to be portfolio pieces; the problem with this approach is that you will be building more impressive projects very soon after Foundations. Save your time and energy for those projects. The capstone project for Foundations, however, is worth spending extra time on to ensure you are demonstrating the best of your abilities at that time.

Pick projects you like and use them as portfolio fodder

You will like some projects more than others. Building a portfolio can be a lot more effective if you spend the time on projects you are enjoying. Pick a few projects past Foundations that you really enjoy, go the extra mile, and make them your own.

Always spend extra time on capstone projects

Spend the most time on the final projects for each course. This will ensure you have strong portfolio pieces and will help you understand if you need to go back into the course and refresh.

Use git properly

Git is very underrated among budding developers. Don’t be afraid to experiment on your code; if you’re properly using git, you can easily go back to a working state (which helps immensely with refactoring). Use branches for experiments; if they’re successful, merge them with your main branch, otherwise, toss them out! Writing good commit messages means you will know what you were doing when you come back to the project in 2 weeks. This is a great resource on commit messages: https://cbea.ms/git-commit/

Applying to jobs

Briggs Elsperger — Mon, 07 Mar 2022 17:50:34 +0000

Getting a job is the goal of most people working through The Odin Project, so it would feel foolish to not talk about applying for jobs. Applying for jobs tends to take a lot of time; it’s best to do it strategically.

Avoid freelancing

Freelancing is often described as an easy way to break into the programming field. The problem with this mindset is based on a surface level understanding of web development. Wordpress, for example, makes it easy to get a basic brochure site live and visible. This is what makes people generalize about freelancing being easy. Don't mistake that simplicity for what is brought to you by TOP. Freelancing using the tools The Odin Project helps you learn requires much more knowledge and experience. The tools introduced bring more potential for difficult situations that can make freelancing a negative experience for all parties involved. Without the mentorship of experts, you may not be able to ship software that is scalable and safe for your clients. Certain practices can really only be learned at a company or through failure, and failure during freelancing could mean a lost revenue stream, or worse, a lawsuit. Freelancing also means you have the burden of becoming the marketer, the CEO, the financial department, and all of the other business development representatives at once. This can cut deeply into your time, and that time could be better spent becoming a stronger developer hired into a full time role.

Don’t apply too early

Applying too early wastes valuable time that could be spent moving the needle away from “luck” and towards “likely”, by gaining more skills. Generally, you should apply around the midpoint of Rails, or near the end of Node. Don’t rush yourself. If your strategy is to be “lucky”, consider that employers that are willing to hire someone with underdeveloped skills may be predatory and may not have devices available to help you grow as a developer. Foundations, and even the React sections, are not enough for you to be a strong programmer in most cases. More general programming concepts are introduced later in the curriculum that you will need on the job.

Check out the getting-hired section when you’re ready

After you’ve hit a place where you should be applying, make sure you go over the getting-hired section of the curriculum. Also check out the pins in the getting-hired section of the Discord.

Look at already reviewed resumes

Get in the Discord, in the getting-hired channel, and look for a pin that teaches you how to find resumes that have been reviewed. (In case it disappears: use the search and search for images in the getting-hired channel.). Base your resume on those: read all the feedback they’ve gotten and apply it to your own. Pay close attention to verb tenses, summaries, and what resume builders are being used.

Ask for a resume review

After looking at, and following the advice found in the getting-hired course and Discord channel, post your resume for review (make sure to use a screenshot of your resume; do not upload a PDF; do block out your address and phone number.). Expect some strong and terse feedback, but do not take it personally; everyone is there to help you succeed. Carefully select those you will listen to. Generally the Maintainers have strong advice. Once you’ve gotten feedback, post the updated resume and gather more feedback. Building and refining a resume is an iterative process.

Next up, Strategically building your portfolio. Then, the conclusion!

Learning Code

Briggs Elsperger — Sat, 26 Feb 2022 18:24:30 +0000

Ultimately we all need to write software in a way that is professional and extensible. This skill is something that will be developed over time; don’t expect to write perfect code on your first attempt, or even your 400th attempt. Constant improvement is the goal. Even professionals do not write perfect code. Constantly improving in a self paced course with minimal feedback can be difficult, but is not impossible.

Focus on the point of the assignment

If the assignment is focusing on Javascript, don’t spend 10 hours on styling. Focus on the task at hand and keep moving through the curriculum. This will keep things fresh and ensure you are constantly learning things rather than tweaking the font size for 2 hours. That doesn’t mean you should totally ignore other tasks around the main task, however. Spend some time styling your projects to some extent; just don’t waste your time on it. You’ll still want to practice other skills as you move through the curriculum so you don’t get rusty. Remember that TOP is meant to constantly build on the previous lessons.

Your approach should be different if you’re using a project as a portfolio piece, however, In that case, spend a good amount of time polishing and making sure it’s your best work. There is more about portfolio pieces in the “Strategically building your portfolio” section.

Run every piece of code you come across

Examples in TOP are meant to be run and played with. Try to pick each example apart yourself and see how it works. Modify it, break it, fix it, run it, bop it. Doing so will help you understand the concepts that are being shared during your readings.

One strategy to doing this effectively is to make assumptions about the code, and then check those assumptions. You should NOT make assumptions that you do not check. If something behaves in a way you do not expect, ensure you spend a bit of time trying to understand why. Avoid rabbit holes: sometimes things are explained later, often even in the next section.

Avoid rabbit holes

It can be tempting to go deep into a subject and feel like you need to become an expert right now. Avoid these feelings. There are a lot of chicken/egg problems in programming where you won’t be able to fully understand something until you understand something else first, but you can’t fully understand that something else without understanding the first thing. Do a bit of research, but if you’re finding yourself following a bunch of links, or on the 3rd page of Google, it may be time to move on from the subject. You can always ask in the chat.

Plan your projects on the macro level, use pseudocode on the micro level

Plan out, avoiding too much detail, how your project will look and function. Try to identify a few major pieces of the application and their interactions and create a wireframe to help with the visual aspect of the app. You should do this with every project; it’ll keep you on track and out of the weeds. It’s a mistake to go into too much detail in your application before writing it, but outlining some of the major systems that you’ll need to build can help in keeping your code organized. Resist the urge to over plan. You cannot predict everything you will run into in your application, and trying to stick to an over-planned project is going to slow you down.

Once you are at the implementation phase, pseudocode your functions before you write them in code. Pseudocode helps you think about a problem separately from thinking about the code. Separating the “problem” from the “code” is an effective strategy for preventing stalls. It also has you get thoughts down if you have to step away unexpectedly. Check this article out for more information: https://users.csc.calpoly.edu/~jdalbey/SWE/pdl_std.html

Don’t look at solutions until you’ve completed the project

Wanting to look at a solution to get yourself started is a normal inclination, but it’s one that should be resisted. Giving yourself the opportunity to struggle through something will help to build the pathways in your brain that will make problem solving easier in the future. Not allowing those pathways to be built means that more difficult problems (that likely will not have solutions for you to peek at) could become insurmountable. Instead, if you get completely stuck, ask in the Discord chat. People there can help guide you to an answer, rather than give you a solution outright and circumvent a learning moment.

Read Others’ Code

After you’ve completed a project, you should spend a significant amount of time reading others’ code and trying to understand it. Read good code, bad code, and everything in between. Ensure that you are looking at solutions that are NOT the top rated as well. At first it may be difficult to see the difference between good and bad code, but over time you will start to recognize the patterns that are strong, and those that are weak. Compare pieces of code to yours and identify the differences that make something easier or harder to read. Try to understand what was going through someone’s mind while writing the code, and what kinds of trade-offs they made. Make sure you run the code and tweak it and play with it as well, as this is where most of your learning happens.

It is also beneficial to read and review code to the best of your ability in the showcase on the Discord server. You can also spend time discussing why someone decided to do something a certain way.

Refactor your own code

Now that you’ve finished your project and have looked through others’ solutions for a while, spend a bit of time refactoring your own code using the lessons learned. This isn’t a process that has to be exhaustive, but spending time implementing some patterns that you found effective can really help you learn why those patterns were used, or how someone discovered them. Be sure you are not spending too much time on this instead of moving on. Additionally, don’t use anything from someone else’s code if you don’t understand it; either seek to understand it or move on for the time being. You never know when you’ll be asked about it.

One mistake people make is throwing their code out when they find they’re running into difficulty. Instead, try to refactor the code you have into the shape you ideally want it to be. There are times where throwing code out is useful, but that is usually in the beginning sections of TOP, on the very early projects. In general, avoid throwing code out as much as possible.

Be OK with OK

You’re likely new to writing code, so resist the urge to spend too much time trying to write things perfectly. If you have completed the requirements using the topics introduced in the sections prior to a project, you can consider the project complete. Being a perfectionist is a direct route to burnout and potentially to not finishing the course. If you are unsure if your project is complete enough, make sure that you post it in the showcase.

Write your unit tests

When you hit the sections of the curriculum that teach you how to write unit tests, write them. They are important. If you have not reached the point in the curriculum where tests are talked about in detail, remember they are something to spend extra time with. In addition to helping you write cleaner code, having unit tests in your code makes you appear more professional if a potential employer takes a look at your GitHub.

Use Git

Use it, it’s used everywhere, it’s one of the easiest ways to make yourself look like a professional, and makes it very easy to share code when you need help. Spend time writing good commit messages and using it as it’s intended. Read this https://cbea.ms/git-commit and come back to it often. Make sure your projects are pushed to GitHub enabling you to easily share code with helpers in the Discord server, or even to employers. Learning to effectively use git will also make life a lot easier when it comes to experimenting with code (which you should do a lot of).

Strategically building your portfolio

Foundations isn’t a strong portfolio generator

Pick projects you like and use them as portfolio fodder

Always spend extra time on capstone projects

Spend the most time on the final projects for each course. This will ensure you have strong portfolio pieces and will help you understand if you need to go back into the course and refresh.

Use git properly

Next up, Applying to jobs!

Reading Comprehension

Briggs Elsperger — Sat, 12 Feb 2022 15:48:39 +0000

Reading comprehension is a developer’s closest friend. Most of the information you will use comes from text documentation. Strengthening reading skills requires practice, so slow down and focus on what you are reading. When you notice your mind drifting, stop, step away for a moment, trace back, then reread what was missed. Getting bored is okay, but if you work toward strengthening your capacity to read, reading boring texts will get easier.

Read everything, in order

Be sure to read EVERYTHING in any TOP lesson. Each lesson has very important information that will likely be referenced later. The curriculum is careful to not include too many redundancies, so it can be useful to read over a lesson more than once. When learners have issues with installations, it’s almost always due to missing some nuance or skipping a step. Slowing down and focusing can really help prevent mistakes like this.

Generally, don’t take notes

Taking notes is often touted as a study strategy, but with programming you already have every piece of documentation at your fingertips via the Web. It is therefore not ideal to maintain your own version of the docs using your own notes. In addition, when you look something up there is a chance you might gather some tangential information related to the topic you are trying to understand; that information could then help you later when you need to do a related task. This doesn’t mean you shouldn’t write things down when watching a video or reading an article, but it does mean that you should not rely on your own material as a source of truth. Everything in TOP is an “open book test,” so rely on your Google skills and official documentation. If you do write notes, they should be conceptual and never aim to replace documentation. Sometimes people will write notes and immediately throw them away, using them as a focus strategy rather than a reference list. If this technique is useful for you, continue to apply it. The important thing is to not create notes that get you stuck or trapped.

Before acting on directions

Due to the complex nature of some of TOP’s topics, directions can be extremely specific, especially for installations. A strong strategy to avoid missing steps, or getting stuck without realizing the solution is in the very next step, is to read every step from start to finish before executing any commands or actions. If you do so, you will be more prepared to follow the directions, and you will recognize if a step has unexpected results, and avoid going too deeply down a difficult path. Of course, there may still be times you get stuck, and that’s okay. If you do, go ask for help on the Discord server. More on that below.

Learning Styles - “I’m a visual learner, so I learn best with videos”

It’s not uncommon for people to believe they have a “learning style”, and say they learn best by watching videos rather than reading. Usually what people actually mean by saying this is that reading articles is hard and not as immediately stimulating as a video. Learning from videos isn’t easier than reading, but may feel easier because it’s easy to turn your brain off, let the video play, then copy the code and run it at the end. Engaging your brain at every step of learning is critical. That isn’t to say that videos are useless; there are plenty of useful lectures that focus on conceptual information. But code-along videos are largely something to be avoided. They are mostly useful for the very beginning stages of learning to program.

Having a fixed mindset about “learning styles” can really set up roadblocks in your learning. Here is a helpful description of a study about learning styles: https://poorvucenter.yale.edu/LearningStylesMyth.

Instead of getting wrapped up in the idea of your “learning style”, allow yourself to learn from all of TOP’s suggested resources. You may find that learning from new types of resources is surprisingly (and far more!) effective.

Coming soon, Learning Code!

The Discord Server

Briggs Elsperger — Sat, 05 Feb 2022 03:58:40 +0000

The TOP community is one of the most important resources at your disposal. It’s a place to get some help with, and advice on, your code and your TOP journey. In fact, most of the advice in this guide is gathered from advice that has been given on the server. Due to the nuances of text communication and the amount of conversations happening, you should prioritize understanding the goals, policies, and procedures of the community; then you will be ready when you really need help with something.

Rules and FAQ

There are rules on the server, and it is in your best interest to read all of them. Anything that is not answered in the rules is likely answered in the FAQ. Ensuring you are up to date on both the rules and FAQ shows that you are acting in good faith in the server, and not being lazy. The rules are important and are taken seriously by the moderation team, who enforce them in order to keep the community safe and professional. The community is massive in size and global reach*.* The team at The Odin Project has iterated over the rules, with the intent of making them as fair as possible while still keeping avenues for professional discourse open and on topic. Ultimately, the rules are in place to help our learners get help as soon as possible while avoiding misunderstandings (both trivial and significant), and to keep the chat a friendly, safe, and welcoming place for everyone.

Culture

It’s not a bad idea for you to lurk in the chat for a while to understand what kinds of interactions happen there and how they are resolved. Observing and picking up on how people interact, before posting something that may not fit well with the culture of the community, can help you avoid an uncomfortable interaction with another member of the community or a moderator. Take your time when observing; culture cannot just be explained, so it’ll be your responsibility to make judgment calls on your posts. The members of the Discord server are forgiving and kind, so don’t expect to be bullied or have issues with not perfectly “fitting in”. Everyone on the server is there to help.

Despite the fact that it’s impossible to fully explain the culture, there are a few general tricks someone new to the server can follow:

Assume positive intent. Nearly all tone is lost when sending messages in a text setting. It’s usually best to assume that someone has the best intentions and is not attacking you or your work. Jumping to the conclusion that someone is trying to be rude is a surefire way to feel attacked when you most likely are not. Keep in mind that people from all backgrounds, from varying parts of the world, find their way to Odin, and that English may be someone’s second language.
If you feel frustrated or upset, make sure to take time to cool down before asking questions. Asking questions when you’re frustrated can make it harder to assume positive intent in others’ messages. Let yourself cool off, then ask your question as kindly and thoroughly as possible. It’s likely nobody wants to deal with you when you’re frustrated as well. Relax, and everyone can have a more productive time in the chat.
Don’t take “terse” messages as an attack. Often people send short messages for efficiency, not as an indicator they’re annoyed with you, or upset.
Using bot commands is a reasonable way to communicate; do not assume that they are impersonal or an attack. When someone replies with /question after you’ve asked a question, for example, the intention is to remind you to refresh yourself on the article and be able to ask something that can be more easily answered. This isn’t an attack, but an efficiency to save everyone’s time, including yours.
Behave the way that you would at a job; be professional and respectful.
- Being professional means:
  - Not posting random memes in any channel
  - Using reacts positively, instead of to tease people
  - Replying to questions in a timely manner
  - Not jumping into conversations that do not concern you
  - Not saying anything that could make someone uncomfortable
  - Understanding that others in the server are colleagues first, friends second
  - Using proper grammar and punctuation

Questions

It’s likely that you’ll have some questions, and the TOP Discord server exists for exactly that reason. This doesn’t mean someone should ask with recklessness though; there are strategies to asking a question in a way that makes it more likely to get answered. Here are some of them:

Don’t ask to ask; just ask. This article summarizes it nicely: https://dontasktoask.com/
Ask well thought out questions. Ensure you’ve done your research and can articulate a few things you’ve tried. Follow this guide religiously: https://medium.com/@gordon_zhu/how-to-be-great-at-asking-questions-e37be04d0603
Be available for discourse; don’t ask a question then leave to make dinner. Make dinner first, then ask your questions so you are around to answer follow-up questions and report back on suggestions.
Wait around 30 minutes before asking your question again. If your question hasn’t been answered within that time frame, consider that you may not have asked an effective question. There’s also a good chance that there simply was not anybody around that could help you with that question. Don’t forget that the people helping in the server are doing so on a volunteer basis (which means entirely without pay); be sure you are not wasting their time with a poor question.
Ask in the proper channel or expect to be redirected to the proper channel.
- Be careful to not speak over others getting help. There’s often another room for the topic. Try elsewhere so you don’t get buried, as long as there is a different relevant channel.
Post ALL of your code when asking a question; this can be in the form of the GitHub repository you’ve been pushing to, a repl.it, codepen, or codesandbox. Often the problem isn’t where you think it is, but in the context around it. Make sure you have the code handy when asking a question.
If you’re working on a large code base, try to recreate the error in a smaller environment. Sometimes this can help you discover where the error is, and if it doesn’t, it will help you frame your question when you ask it.
Thank the people helping you. A simple @username ++ will give a user a point; use this as a way to say “thank you”. This gesture goes a long way and people will remember it when you next ask for help.

Helping others

Go into the chat and help others learn. You likely have some debugging skills and can work with others to help them solve their problems. Helping out will bolster your own strengths and help prevent some specific weaknesses related to communicating about code.

Mindset

Briggs Elsperger — Sat, 05 Feb 2022 03:25:42 +0000

Managing your mindset while working through TOP is extremely important, more so than following any other single strategy. The first few sections of the curriculum (the ones about mindset) do a fine job covering how to manage the difficulty, and it can be beneficial to reread those sections when running into difficult times.

Get Gritty

There are many technical exercises involved when learning to program; they can be overwhelming and often make a learner feel as if they’re hitting roadblocks over and over. This feeling is something everybody doing the course should expect. The countermeasure for giving up when things get rough is grit, something every prospective programmer MUST develop. Read about grit here: https://en.wikipedia.org/wiki/Grit_(personality_trait).
Things will get hard, so spend some time with the articles at the beginning of TOP and get comfortable with encountering difficult things.

Take the time you need

Avoid rushing through the curriculum; rushing is a surefire way to burn out. Using the Pomodoro technique can help you stay on task while ensuring that you take the breaks you need. Hard deadlines should be avoided as well, as they will make skipping and rushing very attractive. Moving through the curriculum without having the prerequisite understanding of the previous topics will make each subsequent lesson more and more difficult to learn properly as you dive deeper into the course.

A TOP Strategy Guide

Briggs Elsperger — Sat, 05 Feb 2022 03:09:38 +0000

Becoming a TOP Success Story

The Odin Project is known to be very intense, but also has a track record of helping learners find consistent success. Its intensity is the “secret sauce” that helps people become strong developers. TOP is not easy, and for good reason. It strives to help learners get exposure to all the necessary skills to become a successful developer. The specific technical skills (i.e. hard skills) that you need to pick up are obvious, but it can be easy to overlook or neglect the equally important "soft skills" like mindset and communication. This guide will explain some strategies that have been employed to great effect by successful TOP learners. These strategies will help you develop both hard and soft skills.

With this first section, we'll be covering mindset.

DEV Community: Briggs Elsperger

Understanding Callbacks

Understanding Callbacks

Anatomy of a Function

Normal Functions (Named Functions)

Anonymous Functions

Arrow Functions

Key Point

What Callbacks Look Like

How Callbacks Work

Iterator Functions

Event Listeners (DOM)

Conclusion

Early Return Pattern

Early Return Pattern

Understanding return

Early Returns

Early Return pattern

Gotcha!'s

Conclusion

P.S.

Conclusion

Strategically building your portfolio

Foundations isn’t a strong portfolio generator

Pick projects you like and use them as portfolio fodder

Always spend extra time on capstone projects

Use git properly

Applying to jobs

Avoid freelancing

Don’t apply too early

Check out the getting-hired section when you’re ready

Look at already reviewed resumes

Ask for a resume review

Learning Code

Focus on the point of the assignment

Run every piece of code you come across

Avoid rabbit holes

Plan your projects on the macro level, use pseudocode on the micro level

Don’t look at solutions until you’ve completed the project

Read Others’ Code

Refactor your own code

Be OK with OK

Write your unit tests

Use Git

Strategically building your portfolio

Foundations isn’t a strong portfolio generator

Pick projects you like and use them as portfolio fodder

Always spend extra time on capstone projects

Use git properly

Reading Comprehension

Read everything, in order

Generally, don’t take notes

Before acting on directions

Learning Styles - “I’m a visual learner, so I learn best with videos”

The Discord Server

Rules and FAQ

Culture

Questions

Helping others

Mindset

Get Gritty

Take the time you need

A TOP Strategy Guide

Becoming a TOP Success Story

Understanding `return`