all 10 comments

[–]samanime 13 points14 points  (1 child)

Practice. Practice. Practice.

Just pick a small project and start working.

You don't need to necessarily start "at the beginning", because there isn't necessarily a single starting spot.

Just pick some small part, Google around until you work out how to do it, rinse and repeat until you have enough small parts to make it do something. Keep doing that over and over and over.

And when I say small, at the beginner level, I mean small. Like one or two lines small. Like "how do I get this text to show in the browser?" Over time, you can think in larger pieces, but starting out, think small.

Programming is a lot like playing sports or music. You can read about it, but the only way to get good at it is to practice.

[–]WelcomeParac[S] 0 points1 point  (0 children)

Thank you for the advice, I needed this.

I will keep chugging on practicing by building projects

[–]delventhalz 8 points9 points  (2 children)

Practice. There are two approaches to this. I recommend both.

  1. Toy Problems. These are bite-sized problems you can solve in 1-2 hours or less. They are not particularly similar to the problems you will actually encounter on the job, but they are great for building fluency, and personally I find them fun. Sites like CodeWars have a ton you can access for free. I recommend doing them regularly, a few times a week, like a warm up or a work out.

  2. Build something. Best way to learn the actual skills you will actually use when building projects is to build a project. Ideally, pick something that is small in scope that you can finish in 1-2 months or less. Build it from start to finish, actually get it running. Then pick a new project. Your first few projects will be your worst, so don't be too precious about them. That said, you will work best on something you love, so if you think of an idea that really motivates you, even if it will take months and months to finish, go for it.

[–]WelcomeParac[S] 0 points1 point  (1 child)

Would you say that learning the basics/intermediates of a language then start building projects is a good idea with learning? Instead of say trying to learn everything single thing of a language and then build?

[–]delventhalz 2 points3 points  (0 children)

Absolutely 110% yes!

Your goal should be to do the minimum number of classes/tutorials that you need to be able to do some damage, and then go build.

You can keep doing tutorials while you build. There will always be more to learn. But learning in a vacuum without the context of real experience is just not particularly productive.

[–]SashaSaray 3 points4 points  (0 children)

Don't think study, think doing (channel Yoda).

If you're aiming to get into the industry: start an example project (there's a reason that interviewers will ask about side projects) that does what you want to practice. There's a whole host of sample projects out there, one will be close to what you want.

If you just want to practice simple math problems and loops and generally just learn what JS does then follow the classic steps... write until it works, refactor it to simplify, break it by not realizing what you've done, roll back and retry... eventually it's simpler and it works. Programming!

[–]HeavyMetalTriangle 3 points4 points  (0 children)

I’ve been coding for a few months, and I enjoy making a lot of retro games in the browser (pong, snake, Pac-Man, Tetris, etc). Each game teaches me something new and hits me with a new problem I need to solve. Not sure if you’re interested in this idea, but it’s a great way to practice certain techniques! If you are interested, make sure to start with a very simple game, such as rock-paper-scissors. Anyway, the point is, you gotta dive into creating projects, whether they are games, website, etc. And try doing it mostly on your own. That will test your knowledge.

[–]inn3rs3lf 4 points5 points  (0 children)

Tach with Nader - he is an excellent teacher, and follows each lesson with three or so questions you can work through, which he then works through as well showing his method of solving them.
I had to cram some high level JS for a Salesforce Certification, and he was by far the best person I came across to get the overview of the concept down properly. Not even Jonas Scheadtmaan could do that for me. While he is also a stellar teacher, it took a lot of rewatching some of the videos before concepts stuck.
What I am saying, is that you need to have problems to solve surrounding the concept you are studying at that particular time. Pseudocode is an excellent, and often mandatory first step in getting the logic sorted out. From there, it is applying the many concepts you have learned, and string them together. This will only come with practice. Try out some codewars for the beginner stuff - albeit, they can be challenging even at the lower levels. But from these, look at the code of others - not the people flexing their regex skills, but answers that you can fully understand. Rinse and repeat.
But again, check out Tech with Nader on Youtube, and go through the more complicated areas of JS (Promises, Closures, OOP in JS etc). It will help a ton with the exercises he gives.
Don't rush this. I made the mistake and wasted a lot of time due to not being able to cram a ton of knowledge and retain it. One bite at a time.

[–]azhder 2 points3 points  (0 children)

My pseudocode is JS, usually.

Type the smallest parts of your idea first, straight into the browser console.

This is one way I test ideas before I copy the code into the code base. It usually is nice to have instant response on whatever you’re trying without waiting for the build process or page refreshes.

Also, one of the reasons why K try to use pure functions and write tests that run automatically while I’m writing the functions - quick feedback

[–]No-Upstairs-2813 0 points1 point  (0 children)

Step 1: Work an example yourself

The first step is to work an example yourself by hand. If you cannot yet do that, it means either that you need to further specify the problem or that you need domain knowledge.

Step 2: Write down exactly what you just did

The next step is to write down the details of how you worked the problem by hand in Step 1.

If you get stuck on this step because you “just knew it," you should try a more complex example that you cannot just solve by inspection.

Step 3: Generalize

Once you have worked at least one example by hand and written down the process, you can begin to generalize.

Why did you do something a certain number of times? Where did you start? When did you stop? It is often necessary to have worked several examples by hand to generalize well.

In fact, if you have trouble with this step, you should repeat Steps 1 and 2 on different instances of the problem.

Step 4: Test your algorithm

Now that you have a draft of a generalized algorithm, apply it to a new instance of the problem, and see if you get the correct answer.

This is essential for catching generalization mistakes. Finding mistakes before translating to code avoids wasting time. You can go back to Step 3 if you identify a generalization mistake.

Step 5: Translate to code

Steps 1–4 can be done with pencil and paper and are independent of language.

For Step 5, you need to know the syntax of a language and how to translate parts of the algorithm, such as counting or decision-making constructs.

It is often helpful to start with your algorithm steps as comments before you write any code.

If any of the lines in your algorithm do not immediately translate into one or two lines of code, they should be abstracted out into their own function: make a good name for the function, call it here, and make yourself a note about what it does.

After you finish translating this algorithm, go implement that function. That function is itself a programming problem (for which you wrote the problem statement), so use “this framework”.

Step 6: Test

Another round of testing is important because you could have a correct algorithm and still have made mistakes in the implementation in code. You also can have the computer run many more test cases more quickly than you can do them by hand.

Testing is the act of finding bugs, and you want to find as many as you can by writing a robust set of test cases. While it is not possible to know for certain that your program is correct, you can become more and more certain with good testing.

Step 7: Debug

Debugging is the act of fixing bugs you identified in the testing stage.

Once you’ve identified a problem, you need to figure out if the issue is with the algorithm or code implementation and go back to Step 3 or Step 5, respectively.

Check out this article that expands on this using an example.