DEV Community: Carlos Diaz

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.

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.