Discouraged about how my code looks 🙁

That comes with time. If I watch some Gordon Ramsay cooking video, what I make will not taste as good or look as good as what he did. Now keep in mind that he has hundreds of recipes off the top of his head.

It takes time. You will heuristically learn little tricks. You will just get a “spidey-sense” for these things. Until they develop a pill for this, you’ll have to do it by repitition.

I am working hard on scribbling down problems on a piece of paper, breaking the problem down into mini pieces, and solving them one at a time.

YES!!! Do that. You’ll get better at it.

My code worked just fine but I was overwhelmed by the fact that my solutions are 5-6 times longer than the ones provided in FreeCodeCamp.

You just came up with a more complicated algorithm. Or more accurately, they sub-contracted some out their algorithm to helper functions, like slice and regex.

I would definitely learn the prototype methods. You know there is one to reverse an array?

But you learned something by doing it manually. It’s like the apprentice pastry chef that showed up early to impress the boss by making all the ravioli by hand, only to have the boss come in and point out the ravioli machine. But that apprentice learned and practiced a skill, one he might need one day and one that will transfer to other tasks.

Is this something I should be worried about early on?

Aware? Yes. Worried? No.

Should I be focusing on refactoring my solutions as a newbie?

I wouldn’t obsess about it. I suggest to come up with your own solution, then look and see what others have done - understand their approach.

Do companies care how long my programs are when it comes to hiring?
Does writing shorter code make programmers stand out to their employers?

There is a danger here. Short is not always better. I think readable is much, much, much more important. Clear, readable, well organized code with good variable names will almost always be better. In some cases, I have a few extra lines just to make it more readable. Unfortunately, sometimes with algorithms, there is what I call the “cult of concision”, this obsession with the shortest code possible. Often that comes at the expense of readability.

Consider these:

const getIndex = record => {
  if (record && record.employee && record.employee.foo === true) {
    return 0
  } else {
    return 1
  }
}

const getIndex = record => {
  if (record && record.employee && record.employee.foo) {
    return 0
  } else {
    return 1
  }
}

const getIndex = record => {
  if (record?.employee?.foo) {
    return 0
  } else {
    return 1
  }
}

const getIndex = record => record?.employee?.foo ? 0 : 1

const getI = r => +!r?.employee?.foo

They all do the same thing: If record.employee.foo is true (or truthy) return 0, otherwise return 1.

Which one would you rather see in code? I’d rather see the second to last. It’s not the shortest, but I can tell what it does. (Part of that will depend on your comfort with some JS features).

The last one is shortest, but I have to think about it a lot more. What is “getI” getting? What is “r”? Wait what does putting “+!” in front of a variable do? I have to think about that the “!” does (negation) and then think about what a “+” does (unary plus operator, converts to a number) and I have to remember that true coerces to 1 and false to 0. Granted, “!” isn’t a problem, but the other two take me a few seconds. If I’m reading through 10k lines of code, every second counts.

I wrote a function very similar to that last one on my first job. (A little more complicated, but also “too cool for school”) I was so proud. A senior dev made me rewrite it. I resented that, it hurt my pride. Now, after having worked for a while, I 10,000% understand why she rejected it.

I don’t know, I’m babbling. You’re doing fine. Don’t worry about it too much. Just keep coding and learning. You’ll get better. Readability is more important than short, though sometimes we can improve readability as be shorten things - but there is a point of diminishing returns.

4 Likes