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

“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.