Forem: The Odin Project

Pursuing Best Practices is a bad practice (When You're New)

Carlos Diaz — Tue, 15 Apr 2025 18:38:51 +0000

“I need to do this right, even though I don’t know what right is. What if I’m making mistakes that become habits? If I’m not doing it right, does this mean I don’t have what it takes to be good at this?”

Throughout my learning, I said this to myself for pretty much every line of code I wrote. I needed to see the whole, correct solution in my head before I could start typing. I may not have known what correct was, but I told myself I’d know it if it happened to pop into my brain. And I’d sit there, pondering, typing, deleting, reading, and rereading. And after all that, I still couldn’t conjure up the correct code in my brain.

I wish I had the words to wipe away these thoughts. I don’t. I don’t believe you’ll get to the last line of this feeling cured. The thoughts will come and go. While I don’t have a fix, I can offer some thoughts about why this happens, what it’s doing to our learning, and how we can think about things a little differently.

I struggled with math as a kid. When I was in elementary school, we’d take turns going up to the board to solve multiplication problems. 5 * 3, 3 * 7, 8 * 2. Ugh. I remember a day where I went up and got it wrong. I knew everyone was looking. I wrote a number, erased it, tried again. I just didn’t get it. I could hear my classmates chuckling. My teacher asked me to go back to my seat. And later having to show my parents how many problems I got wrong on my homework didn't help. All that messed me up. I learned some math. But it felt like the bigger lesson was:

Don’t even try unless you know the answer.

I can’t claim this is the case for everyone. But in my experience, I couldn’t start something until I knew I was right. Being wrong had consequences. Laughing classmates, disappointed teachers, angry parents. I was trying to protect myself.

This fear of being wrong didn't stay confined to math class—it became a pattern that shaped how I approached learning.

So years later, in learning to code, I’d regularly have a blank text editor along with a blinking cursor while hoping for inspiration to strike. But in wishing the right code could pour out of my fingertips, I’d not write much code at all. And in the moments when I'd begin typing something, I'd delete it because I sensed it wasn't correct.

“Is this code correct? Are there too many lines here? Am I using this HTML element correctly? What is the best practice?”

“None of this is remotely useful. Who would want to hire someone that can’t even get something basic built? Why don’t I just know how to do this? I must be stupid.”

This obsession with perfection clouds our thinking. Learning to code is hard enough. Expecting perfection at things you've just started learning can make it feel impossible. And that’s what drives us to seek out best practices. We want to write code that would be useful. We want to use HTML elements in the way they are supposed to be used. We want to show people we’re not stupid. We want to be right.

Let’s imagine someone new to math who wishes to get really good. Their first step is learning about numbers. Later, they begin wrestling with adding numbers. Imagine them being frustrated at struggling with adding numbers when they found out about numbers only recently. It’s unreasonable and really unfair. Skills in a thing are an outcome of regular practice over time. No one is born just understanding everything they've never seen. Or if we want to be accurate: The only people who 'just know everything' are fictional geniuses in movies or people who aren't being honest. We should hold ourselves to high standards. But striving for those “best practices” in ideas you just found out about isn’t practical.

And while we might have the best intentions, the best of the best practices may not do much for us when we’re learning the basics. I've had countless conversations with beginners who seek feedback on their first projects. They often arrive with professional-grade expectations for code they're writing while still learning the basics. When I ask if they're new to JavaScript and if this is their first project, they confirm both points—yet still expect their work to meet professional standards.

If you just found out about functions and logical operators and don’t yet know how to actually use those, how useful would a design pattern be in that moment? If you just found out about arrays, would a best practice be useful in that moment? Sure, fancy concepts like design patterns and code efficiency are generally useful. But in the moment of learning foundational concepts, those fancy ideas just aren’t very useful. You’re learning how things work. And that’s different from learning how to use those things well.

There are occasions where someone shares an exercise that has far too many lines and wants to learn the best practices to eliminate lines of code or make their code more performant, or make their code 'right.’ Except, their code is perfectly fine. They use what is needed and every line describes a necessary operation. Imagine this scenario where we reverse a string:

function reverseString(str) {
  // Step 1: Create an array to store each character
  const charactersArray = [];

  // Step 2: Loop through each character in the string and add it to the array
  for (let i = 0; i < str.length; i++) {
    const currentChar = str[i];
    charactersArray.push(currentChar);
  }

  // Step 3: Create a new array to hold the reversed characters
  const reversedArray = [];

  // Step 4: Loop backward through the charactersArray
  for (let j = charactersArray.length - 1; j >= 0; j--) {
    const currentChar = charactersArray[j];
    reversedArray.push(currentChar);
  }

  // Step 5: Initialize an empty string to build the final result
  let reversedString = '';

  // Step 6: Loop through the reversedArray and concatenate each character
  for (let k = 0; k < reversedArray.length; k++) {
    reversedString += reversedArray[k];
  }

  // Step 7: Return the final reversed string
  return reversedString;
}

I’ve seen learners who are new to programming, new to JavaScript, new to manipulating data who will whip that up and think they are failures because they didn’t come up with const reverseString = str => str.split('').reverse().join('');. Note: I'm not suggesting fewer lines is universally better - readability matters more than being concise when writing code. Just trying to illustrate the point.

Imagine you just found out about strings, variables, logical operators, arrays, and loops. If the starting point were the one-liner, the mental leap towards understanding is a huge one. When we’re learning basics, there’s value in understanding the intermediate steps.

I recall an occasion where a learner heard about the idea of DRY (Don’t repeat Yourself) and halted their progress because their code had some repetition. Their code wasn't even functioning correctly, yet they were more concerned with making it adhere to professional standards than making it work at all. They could absolutely take a detour for generalizing logic. But if logical operators and functions feel tricky, is that really the most important place to invest? It’s really hard to recognize the value of a best practice when we don’t have a lot of practical experience.

The irony is that truly understanding why best practices like DRY matter requires first-hand experience with the problems they solve—experience you can only gain by writing 'imperfect' code. This creates a paradox for the learner pursuing best practices so early on.

This striving for best practices too early robs us of opportunities to practice, experiment, make mistakes, and make observations. It’s uncomfortable, especially if you’ve had learning experiences like mine.

But here’s a thing to know: in most cases, making a mistake during learning will not cause your computer to explode. The worst that happens is you get an error message, or your code doesn't run, or maybe you see some undefined values. And all that presents is an opportunity to investigate and learn something about our code.

During learning, experiments and mistakes are more valuable than best practices. If you are frozen and not writing code because you need to be right, you won't have the opportunity to just try something and make an observation. Incorrect code can teach us something. For example:

function addNumbers(a, b) {
  a + b;
}

const result = addNumbers(5, 3);
console.log(result);

If we expected to see ⁠8 as the output but see undefined⁠ instead, that's a learning opportunity! It gives us the opportunity to reflect on what we expected and investigate what is actually happening — in this case, discovering that functions need explicit return statements to provide values. But if we never wrote the code, never experimented, never observed, and just tried to imagine things... developing an understanding of how functions work would be real tricky.

Mistakes reveal gaps in our understanding and present opportunities for experimentation, observation, and discovery. And we get none of that if we refuse to try.

Additionally, the stress we put on ourselves for not just knowing makes learning harder. I won’t go into it here, but feel free to Google “learning, stress” to read about how that can make our learning experience especially hard.

So what can we do about it? Here are some reminders for your next coding session:

Mistakes, or not knowing, are an opportunity to experiment, observe, and learn.
A mistake or not knowing doesn’t mean you are stupid. You are new. It is a signal that you have encountered something to learn. As we strive to improve, we should want to experience these learning moments as much as possible.

No one is born knowing how to do this.
Everyone needs to put time and effort into learning something. People who claim this has always been easy for them are not telling you everything.

Try before you feel ready.
There’s a difference between being ready and feeling ready. People mistake how they feel with their capacity. You were ready the moment you knew what to experiment with.

Everyone starts somewhere.
Even professionals will write code that may feel messy just to get something working first. You can’t improve code that doesn’t exist. Get it working first.

Reframe the task.
When you get to a project, remind yourself of the goal. The goal isn't to produce professional-grade code that follows every best practice. The goal is to develop an understanding of the recently introduced concepts. Projects are experiments where we discover, make observations, and build mental models — they aren't examinations where we prove our worth.

We don't scold toddlers when they walk poorly or tell them about the "best practices of efficient locomotion." Their wobbly steps won't win any awards for proper form or athletic excellence. We celebrate their attempts because we understand those imperfect steps are essential to their development. When they face-plant from a misstep, we don't tell them to optimize their gait before trying again.

Similarly, your first rock-paper-scissors game doesn't need to be a masterclass in best practices. Your string reversal function with seven steps isn't a failure because it could be done in one line. These "messy" first attempts are exactly how we build the foundation that later makes best practices meaningful. Without that foundation, best practices are just empty rules without context.

Best practices weren't created first and then used to write good code. They came out of years of people writing imperfect code, making mistakes, and discovering better approaches through experience. The best practices will be there when you are ready.

Give yourself a chance to learn.

Why Learning to Code is So Damn Hard

Rachel Moser — Sun, 16 Mar 2025 13:04:55 +0000

This article was written by Erik Trautman, the founder of The Odin Project.

What every beginner absolutely needs to know about the journey ahead

Quincy Larson was just a "guy in a suit in an office" and decided he wanted to learn how to code. So he asked around. He started by picking up a bit of Ruby then found himself skimming through other languages like Scala, Clojure and Go. He learned Emacs then Vim and even the Dvorak keyboard layout. He picked up Linux, dabbled in Lisp and coded in Python while living on the command line for more than half a year.

Like a leaf in a tornado, the advice Quincy received jerked him first one way and then another and then another until he'd finally taken "every online course program imaginable". By the end of it all, despite having ultimately landed a software development job, Quincy:

... was convinced that the seemingly normal programmers I ran into were actually sociopaths who had experienced, then repressed, the trauma of learning to code.

Ouch. Does that sound familiar?

Phase I: The Hand-Holding Honeymoon

It's really hard to blame anyone for coming into the programming industry with outrageous expectations.

On the one hand, you've heard rumors of how difficult programming is since you were young, like old wives tales meant to scare children into studying social sciences instead.

On the other, the "Learn to Code" movement has done a fantastic job of breaking down barriers and showing people that code is actually quite harmless. Tools like Codecademy and Treehouse reach out with the gentlest of touches to assure you that you too (nay, anyone!) can not just learn to code but become a full-fledged developer as well.

Suddenly the problem isn't fear, it's an overabundance of hopes and high expectations.

And, for the most part, these introductory tools do a great job of guiding you like a child in a crosswalk past the big scary variables and conditional statements and through the early phases of programming syntax. As you conquer one after another of their gamified challenges, your confidence rises. Maybe you can do this after all! How hard can it be? You're basically a developer already!

Here's the problem -- you're in what I like to call the "Hand Holding Honeymoon" phase. Though you may feel like the end is around the corner, you're only a fraction of the way there. This is just the beginning...

Charting The Path Ahead

Before we dive into Phase II, let's look at the bigger picture.

In this post, I'll walk you through the four phases of the typical journey into coding and what you'll need to do to survive each of them. You'll also see how two key factors -- the density of resources and scope of required knowledge -- define this journey.

The trek towards job-readiness can be plotted in terms of how your confidence level changes as your capability increases:

This is a relevant relationship because your confidence is highly correlated with your happiness and because the point where your confidence and capabilities match is the best proxy I have for the sweet spot when you're officially "job ready".

We'll look into the unique challenges of the remaining 3 phases in a moment, but this is what each of them essentially involves:

The Hand Holding Honeymoon is the joy-filled romp through highly polished resources teaching you things that seem tricky but are totally do-able with their intensive support. You will primarily learn basic syntax but feel great about your accomplishments.
The Cliff of Confusion is the painful realization that it's a lot harder when the hand-holding ends and it feels like you can't actually do anything on your own yet. Your primary challenges are constant debugging and not quite knowing how to ask the right questions as you fight your way towards any kind of momentum.
The Desert of Despair is the long and lonely journey through a pathless landscape where every new direction seems correct but you're frequently going in circles and you're starving for the resources to get you through it. Beware the "Mirages of Mania", like sirens of the desert, which will lead you astray.
The Upswing of Awesome is when you've finally found a path through the desert and pulled together an understanding of how to build applications. But your code is still siloed and brittle like a house of cards. You gain confidence because your sites appear to run, you've mastered a few useful patterns, and your friends think your interfaces are cool but you're terrified to look under the hood and you ultimately don't know how to get to "production ready" code. How do you bridge the gap to a real job?

I've interviewed hundreds of aspiring developers over the past several years and heard echoes of the same story again and again. My goal for this post is that you approach the learner's journey with both eyes open and enough of a plan that you can avoid the common pitfalls of those who have come before you.

Let's get back into Phase II...

Phase II: The Cliff of Confusion

So, you're in Phase I -- the "Hand-Holding Honeymoon" -- checking off badges and completing coding challenges while your confidence and capabilities grow. This isn't so bad... what's all the fuss about? You've arrived at the "Peak of Irrational Exuberance"...

Be careful! You’re about to overstep a precipice that’s broken many strong aspiring learners and relegated them to the “coding is too hard” camp. The precise moment this leap occurs is the first time you sit down at your keyboard, open up your text editor, and try to build a project from scratch without any of the fancy in-browser editors, scaffolded code or helpful hints.

Crap.

You might stretch this out a bit by following tutorials, but no one has ever reached the skies without leaving the ground, and, at some point, you're going to have to create magic from a blank text file. You've just entered the second phase of learning, where confidence comes crashing down to earth -- the "Cliff of Confusion":

So you build. You fight and scratch your way to a barely-functional solution but there's something missing. You're at a war with bugs that makes Starship Troopers look benign. It feels like each victory was gained only by a stroke of lucky Googling and your confidence that you can ever figure this stuff out plummets.

This is a particularly frustrating phase to see as an educator and to all participants in our industry. Programming may not be perfect for everyone, but we want you to make progress because sometimes the unlikeliest of stories become the grandest successes.

When the hand-holding ends and students are pushed off the cliff and told to fly, too many potentially awesome people are spiraling onto the rocks of frustration without learning how to flap their wings.

The scary part is that you haven't even gotten to the meaty stuff yet. This second phase, the Cliff of Confusion, is still very early. Once you've finally squashed enough bugs to end the eighth plague of Egypt and actually finished a couple of projects -- thus marking the end of Phase II -- you're still just getting started.

For those who are truly ready to make a career out of this, surviving the Cliff of Confusion is often the point where you decide to go all-in with your new life. But too many are left behind. And, unfortunately, you're just about to enter the "Desert of Despair".

The Two Key Factors at Play

So what really marks the difference between one phase and the next? Why was Phase II (the Cliff of Confusion) so awful compared to Phase I (the Hand-Holding Honeymoon)? Understanding this will help you realize that it's not your fault at all if your journey looks like what we've just described.

Basically, there are two key forces at work in every phase -- Resource Density and Scope of Knowledge. Let's see what these are before exploring how they define Phase III.

Factor 1: Resource Density

As I said above, when you first start out, it feels like there are a million resources out there trying to hold your hand and pull you into coding. That's because there are!

Search for "Learn to Code" and you'll be hit with a wall of helpful and useful tools, texts, videos and tutorials. And, frankly, they're great! Never before have there been so many ways to start learning to code.

Unfortunately, in later phases the density of resources drops off fast. Anyone who's made the jump from beginner to intermediate can attest that there is a BIG difference between the amount of resources available when you first start out versus when you're first looking for help building things on your own without too much hand-holding.

This problem exacerbates as the amount of knowledge increases rapidly entering Phase III, and is one reason why we call that phase the "Desert of Despair". Once you get past this and start to become comfortable with what exactly you need to search for, the resources return and you're able to work with more technical tools like industry blogs and screencasts. Part of this is just understanding which questions to ask.

Here's what the Resource Density looks like in each phase (greater line density indicates more resources):

Factor 2: Scope of Knowledge

Now let's talk about a related issue -- the Scope of Knowledge. This represents the total breadth of new topics you need to learn in each phase. Here's what it looks like:

When you first start learning, the set of things you need to understand is narrow. Everyone, regardless of goals or language or background, needs to figure out what a for loop is, how to build conditional logic, and other basic structures of programming syntax. There ultimately aren't even that many of these fundamental concepts so the Scope of Knowledge during that phase is very narrow.

As soon as you get away from the basics, you see a rapid broadening of the Scope of Knowledge as you need to begin picking up things that are more difficult like understanding errors and when to use the code you know know how to use. This is different because there is no "correct" answer to a clear question... things get fuzzy.

When you progress into the third phase, the scope of knowledge balloons wider. You now need to understand what tools to use, what languages to learn, underlying CS fundamentals, how to write modular code, object-orientation, good style, and how to ask for help (to name just a few). Every trip to Google or Hacker News takes you down another set of rabbit holes and overwhelms you with more things you don't know but feel like you should.

You don't know what you don't know.

Only when you've finally found some traction and left the desert does the scope again begin to narrow. By that point, you've found your chosen technology and its place in the ecosystem. You finally (pretty much) know what you don't know and can plot a path through it. You will continue to increase focus as you push onward and into the beginning of your career.

Phase III: The Desert of Despair

With an understanding of these factors, you can see that the Cliff of Confusion is really just a turning point. The pain caused by the toxic combination of a rapidly increasing Scope of Knowledge and a falling Resource Density results in what I call the "Desert of Despair".

In essence, this desert is where you know there's an end somewhere but you don't know how to get there:

The desert is long and fraught with dangers. You'll find yourself drawn to "Mirages of Mania" along the way -- dozens of tempting resources which appear to hold the solutions you're looking for but which will deposit you, once again, in a place where lonely sand extends to each horizon line.

Maybe you sign up for a couple MOOC courses from Coursera or Udacity or edX. Or you find a tutorial which purports to take you all the way. You thought you learned the lessons of the Hand Holding Honeymoon -- that there are no easy answers -- but the temptation to seek salvation is too great and you fall for the promise that this one will get you to the finish where the others did not.

You can't learn this stuff in a week or a month or a single college class no matter what anyone says so stop falling for that!

There is a LOT more to learn than you probably expected. Even if you're able to get some apps running, it's hard not to feel lost in the greater scheme of becoming a true professional. It's difficult to measure your progress. How do you know what you need to learn or if you're even learning the right things?

Even if you're pointing the right direction, it's hard to measure your progress. You might feel totally lost until the very moment when you're finally able to build something that looks and acts the way you expected it to. But, with enough perseverance and a good compass, you'll eventually get your first few "real" projects launched and you'll realize that you're finally starting to get it.

Sure it's been hard up until now, but maybe this web dev stuff isn't so bad after all... Everything's coming up Milhouse!

Phase IV: The Upswing of Awesome

You've made it through the desert and your confidence is growing. Your Google-fu is excellent and you're finally able to understand those detailed industry blog posts and screencasts. Maybe you've gone deep into a particular language or framework and you have confidence that you can build and launch a functioning application.

This is the "Upswing of Awesome":

All may seem well to the outside but you know deep down that you're not there yet.

You can make that application work but what's happening beneath the surface? Your code is duct tape and string and, worst of all, you don’t even know which parts are terrible and which are actually just fine. Your periodic flashes of brilliance are countered by noob mistakes and, worse, a creeping suspicion that you still don't have a damn clue what you're doing.

This is a bipolar phase. You feel like half of you is a bulletproof developer and the other half is a thin veneer of effectiveness covering a wild-eyed newbie who is in way too deep. The further you progress, the more a gnawing sense of uncertainty grows that someone is going to "out" you as a fraud.

You feel like you should be a developer already but the distance between the code you're writing and a "professional" work environment couldn't feel further away...

Eventually, though, you'll make it. There's too much momentum not to! The Desert of Despair is behind you and the Cliff of Confusion is a distant memory. You're finally, truly, on the upswing. You're learning faster and more intelligently than ever before and, eventually, you will have absorbed enough best practices that your swiss cheese knowledge coalesces into a production-grade skill set.

The Upswing of Awesome always takes longer than you expect it to and it feels interminable because you're so close... but you will get there. If you're persistent enough in the right ways (the topic of a future post for sure), you will convince someone to pay you to keep learning. The job is yours.

What it All Looks Like

So now you've seen the road ahead and the reasons why it can be difficult. When you combine all four phases we just covered with the factors that define them, it looks something like the following chart:

It's one thing to know the path and another to walk it. Let's get you started on the right foot.

How to Make it Through Alive

The journey seems intense and, frankly, it often is. It's important that you understand what you're in for, particularly if you go it alone. But you don't have to. There are ways to short-circuit most of these problems. Learning to code is rarely as easy as people make it out to be but it's also rarely as difficult as it seems in the depths of your despair.

In this section, I'll introduce the key tactics you can use to keep yourself pointed in the right direction.

Surviving the Hand-Holding Honeymoon

The plethora of available resources in the Hand-Holding Honeymoon make it a lot of fun. They do a great job easing you into the kind of logical thinking you'll need to cultivate over the coming phases. It's a great time to start learning to code so try to enjoy it and keep these two tips in mind:

Start by trying out different resources to find how you learn best and what sorts of projects are the most interesting to you. Maybe it's Khan Academy's quick challenges, Codecademy's in-browser exercises, or Thinkful's one-on-one mentorship experience. Be open minded at the start and ignore anything about what you should learn... all code is the same at this phase.
Then pick one resource and stick with it once you've found your fit. Work through to the end of their introductory course arc, which should give you all the foundational knowledge you need to write basic scripts and apps. Then get ready to start building on your own.

Surviving the Cliff of Confusion

Almost everyone will experience the Cliff of Confusion because the only way to become a developer is to, well, develop. You can pretend to be building by signing up for tutorials (or tutorials which masquerade as "complete" courses), but you're just putting off the inevitable. Tutorials are a good way to bridge from more high-touch introductory offerings but you'll need to wean yourself off the pacifier and face the real world at some point.

Three tips for making the transition to building on your own:

Work with someone else, even another beginner. You'll be surprised how much easier it is to debug an impossible error when sharing two pairs of eyes.
Read other people's code to get comfortable with good patterns. Try to understand why the author did what they did. You wouldn't try to become a novelist without reading books as well, would you? We'll focus on this in an upcoming post but, for now, keep your eyes open for any small problems or projects that other people have written solutions for.
Start small and build constantly. You should have interesting big projects in mind for the future, but you'll need to get comfortable debugging and searching for resources with bite-sized challenges. There's really no substitute for experience.

Surviving the Desert of Despair

Once you've become comfortable debugging, your biggest problem becomes the fire hose of required knowledge and a total loss for how to learn it all... the Desert of Despair. In this case, what you really need is a strong path forward. The Mirages of Mania represent all the interesting side paths and rabbit holes and get-skilled-quick schemes which ultimately waste your time.

So the keys to getting out of the Desert of Despair are:

Have a strong goal for what you want to accomplish because otherwise you will end up chasing your tail learning all kinds of interesting but ultimately unproductive things. If you have the time to spare, by all means skip this...
Find a strong path which leads directly to the goal you've set and verify that it will actually get you there. This is where you need to dig deeper than the marketing slogans and smiling faces on course websites or book jackets to ask "will this help me accomplish the goal I've set or not?"
Focus and avoid distractions because, if you're the kind of person who's interested in learning to code, you're also the kind of person who gets interested by learning all kinds of other awesome things. When coding gets difficult, you need to be able to push forward instead of just trying out the next cool-looking thing.

If you're able to identify a path and stick with it, you'll eventually push forward to the next phase instead of spending months or years chasing mirages across the shifting sands of the this desert.

Surviving the Upswing of Awesome

The Upswing of Awesome is one of the trickiest transitions. You can develop applications but you really want to become a web developer. Getting past this phase and into a job requires you to do three things:

Seek and follow best practices for programming. You need to understand the difference between a solution and the best solution. Best practices are a major difference between hacking on your own and building production quality code in a real job setting.
Check your assumptions because you've probably skated by with some gaping holes in your knowledge that you didn't even know you had. You need to diagnose and fix these holes.
Tackle the unsexy skills that are rarely addressed but highly important for transitioning into a professional setting. This includes things like testing, data modeling, architecture and deployment which are really easy to breeze past but which are totally fundamental to good development.

The key to accomplishing these things and pushing through the Upswing of Awesome is to get feedback. Students who have learned entirely on their own may be productive but rarely have the kind of legible, modular, and maintainable code that makes them attractive in a professional setting. You need to work with other humans who will challenge your assumptions, ask piercing followup questions, and force you to fix the leaks in your bucket of knowledge.

So... Can it be Done?

This all may sound overwhelming but I promise that many others have persevered and survived this journey before you. By understanding the road ahead, you're already in a good spot to take it on with a focused plan and access to the right kind of help.

Obviously there isn't space in this particular post to dig as deeply into each phase of the journey as we'd like or to provide the kind of granular how-to advice you deserve. That said, this is a journey with which we're quite familiar and about which we're highly passionate so we want to help in any way we can.

Special thanks to Peter DePaulo, Javier Noris, Michael Alexander, Andy Brown, Saul Costa, Phil Nachum and Quincy Larson for sharing your experiences and for helping to debug these thoughts.

This article was written by Erik Trautman, the founder of The Odin Project.

Updates to the Node course: PostgreSQL, Prisma and more!

01zulfi — Thu, 18 Jul 2024 19:08:58 +0000

We've heard your feedback on Discord and GitHub, and we're thrilled to announce the first set of updates to our Node course.

Follow our progress on the Node Revamp GitHub project board.

What's Changed

New In-House Lessons: We've replaced MDN's LocalLibrary tutorial with brand spanking new lessons on routing, views, controllers, and forms.
Tech Stack Update: MongoDB and Mongoose are out; PostgreSQL and Prisma ORM are in. Additionally, the SQL course from the Ruby on Rails path has been added to the Full Stack JavaScript path before the Node course.

What If I'm Mid-Course?

In Progress: If you're not currently working on a project, pause and complete the newly added SQL course. Then start the Node course from the beginning, doing the lessons labelled as "New" (they will be labelled as such for the next 2 weeks). Additionally, following lessons underwent huge changes, complete them again if you already did:
- Authentication Basics
- Testing Database Operations

Future projects should use the new tech stack instead of express-generator or Mongoose from the old lessons.

Mid-Project with MongoDB: Finish your project, then follow the advice above.
Completed Project(s) with MongoDB: Refactoring to PostgreSQL is optional but recommended if you want to resubmit your project.
Completed the Node Course: It's up to you to decide if you want to revisit the new lessons.

Contribute

The Odin Project is a community project, and this course would not have been possible without its contributors. They deserve a big round of applause. The work is not over yet, the course needs to be updated and improved regularly, and this is where you can help. From fixing a typo to adding a new lesson, every contribution matters!

Special thanks to:

fcasibu
MaoShizhong
jasonHYLam
Bryan Fines
Christian Medina

Memorization and learning to code

Carlos Diaz — Wed, 30 Aug 2023 03:03:14 +0000

Memorization equals learning.

For many of us, it’s how our understanding was assessed. We were praised for memorizing the alphabet, numbers, the four nucleotides in DNA, and x is equal to negative b plus or minus the square root of b squared minus 4ac all over 2a. I imagine that somewhere out there my former math teacher is smiling.

Many of us have held on to that belief. I did when I was learning my programming basics. I spent so many hours attempting to memorize the syntax of a for loop. So many evenings where I’d try to recite the names, syntax, and return values of array methods. And many nights where I read and re-read the documentation on React, wishing I could just tattoo it to my brain.

I’ve spent the past few years helping people learn to code at The Odin Project and I’ve noticed a lot of people there are doing the same. At least a few times a week folks come in to our Discord server to ask about the best note-taking techniques or to express concern about moving to a new topic for fear of forgetting what they just committed to memory.

Here’s a hard truth: the concept that you spent hours trying to memorize that you feel has finally stuck- you’re going to forget it. Don’t freak out though. That’s ok. That’s normal.

The greatest concern I had once starting my job as a software engineer was whether I had enough in my brain. I was afraid of pairing with more experienced engineers at work because I didn’t want them to discover how little I knew. When we did pair I was embarrassed that I couldn’t recall a syntax for a some method or recall the return value of another. There was a pairing session I had with my colleague, John, where this all changed.

While pairing on a task, the idea of localStorage came up. I mentioned that I used it a few times in the past, hoping to impress my new co-worker. John invited me to tell him about it. There isn’t a way to dress this up: I FREAKED OUT. I couldn’t think of a thing to say. I apologized and said I forgot everything about it. But I gave myself a few seconds to think and finally told him there was a way to set and retrieve information but I had nothing beyond that. I was afraid of his response. I was expecting he’d say it’s crazy I hadn’t memorized everything about localStorage and go tell my boss that hiring me was a mistake. Instead, John shared something like this. His exact words are hazy but the spirit of it was:

“That’s ok. I haven’t used that in years myself. Let’s google it together and figure this out.”

The conversation continued and I remember little about the technical stuff. The fact that he didn’t flip out was shocking and that stuck with me. At the end of the pairing session, we discussed the need of revisiting documentation. John shared that he googles and reads documentation regularly. And shared that it is very normal to not have everything memorized. I always imagined that great engineers knew everything. I imagined they carried all their knowledge all the time and could recite any of what they held in their brain whenever they wanted. After all, I was under the impression that memorization equaled learning, which in turn led me to believe that I was only as good and skilled and useful as my memory. John taught me that this is far from the truth.

Now that I’ve been in the field for a few years, I find that I very much agree with the sentiment that John shared. I regularly forget how to use stuff. I forget syntax, return values, even names of methods. If I haven’t used Flexbox in a while, I’ll need remind myself on how to center a div. But rather than freak out, like I used to, I know that I can visit documentation to refresh myself on things when I need it.

When we are actively engaged with a topic, that topic is easy to carry in our working memory. And the hope is that our efforts in studying a thing will move that thing into our long-term memory. For many, falling short of putting everything we engage with into our long-term is failure. Moving things from our working memory to our long-term memory is hard. And to make matters worse, working memory is not unlimited. This means that as we become familiar with one thing, another thing will fall out of that working memory. This causes concern to a lot of people. We end up returning to things we feel we’ve forgotten every time we learn something new. Except in revisiting that thing we forgot, we now risk forgetting that thing we just learned. Then we’re in a cycle where we’re constantly trying to hold on to everything at once. And if we’re constantly trying to hold on to what we know, what room do we have for learning new things in peace?

In the real world, no one holds on to everything all the time. We’re more likely to hold on to the general idea of a thing and less likely to hold on to the details. And in the adventure of learning to code, there is little difference in the utility between perfect memorization and being vaguely aware.

Knowing that it’s possible to remove the last element of an array is just as good as having the syntax of JavaScript’s pop method memorized.

❗ FULL DISCLOSURE ❗: As I typed the sentence above, I was like: “is the pop method even the one that removes the last element of an array?" Me 2 years ago would have freaked out and felt real sorry for myself. Not this time. I cracked open a browser tab and looked at the documentation and confirmed that was the case. Cool!

As we engage with ideas over time, we’re more likely to move larger concepts into our long term memory than the finer details associated with those concepts. As with the example above, we’re more likely to remember that there is some way in JavaScript to remove last element of an array instead of perfectly memorizing everything about the pop method.

We can’t memorize everything. But we can become aware of a ton. Equipping ourselves with awareness of what to research is good enough for getting through learning. Over time, and with lots of practice and mistakes and experimentation, things will stick.

Being vaguely aware is enough.

Disclaimer:

Having some stuff memorized by the time you get to interviews is useful. But by the time you get there you'll be surprised by how much has stuck. The thoughts I’ve shared here are specifically for folks actively in the learning process.

Coding Education for All: Join us in supporting The Odin Project

Kevin Mulhern — Mon, 31 Jul 2023 14:50:20 +0000

Today, we are delighted to announce a significant milestone in The Odin Project's journey – we are becoming an independent and self sufficient entity.

Since 2018, The Odin Project has been financially supported by Chegg, and we are immensely grateful for the resources they have provided us.

Going forward, The Odin Project will be completely funded by community donations through Open Collective. A platform designed for transparently collecting and managing funds for open-source projects just like ours. Open Collective will allow The Odin Project to secure vital financial resources directly from the community of developers and learners that benefit from the platform.

For over a decade, The Odin Project has been providing free and open-source web development courses to thousands of aspiring developers worldwide. Through our comprehensive curriculum, project-based learning, and inclusive community, The Odin Project has empowered countless learners to kickstart their careers in the tech industry.

We firmly believe that access to quality education should never be a barrier, and The Odin Project embodies this by offering a wealth of tools to anyone with the passion and dedication to learn. But to continue on this mission, we need your help!

By donating, you're not just giving financial support to The Odin Project; you're supporting people in their pursuit of knowledge and a fulfilling career. Your contributions will enable us to:

✅ Expand and enhance the curriculum to cover the latest technologies and industry best practices.

✅ Pay for the platform's hosting, improve user experience and accessibility, making it even more learner-friendly.

✅ Foster a vibrant and supportive community where learners can grow and collaborate with like-minded individuals.

🎁 Every Dollar Counts 🎁

No matter the amount, every dollar you contribute makes a real difference. Even the price of a cup of coffee can help us bring more valuable content to learners worldwide! Your generosity will ensure that The Odin Project remains free and accessible to all, providing a stepping stone for passionate individuals to launch rewarding careers in web development.

🌐 Donate Now

If you can't donate at this time, you can still help spread the word! Share this post with your friends, family, and colleagues, and let them know about The Odin Project's mission and the impact they can make.

This journey wouldn't be possible without our amazing community. Let's celebrate this monumental step! Thank you for your continued support and passion for what we’re doing!

New React Course Announcement

01zulfi — Wed, 19 Jul 2023 17:50:31 +0000

We have some exciting news for you today!

We are launching a brand new React course that we have been working hard on for a long time. It has some of the existing content, but most of the lessons are completely new. It covers more React concepts and uses the most up-to-date tools in the industry.

The old lessons have been labeled as "OLD" so you can easily tell them apart; they will be gone by 24th July 2023. You can still find the old lessons in our curriculum repository on GitHub. If you were doing the current React lessons or had finished them, we strongly suggest you start over with the new course. We promise it will be worth it. You don't have to redo the projects.

React course on the Full Stack JavaScript path
React course on the Ruby on Rails path

Happy Reactin'!

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.