Monday, February 27, 2017

What Tutorials Don’t Tell You: How to Approach Projects

What the tutorials don't tell you

I often hear that people who follow tutorials find themselves unable to approach JavaScript projects on their own.

One reason this happens is that tutorials give you a neat set of steps rather than the actual process of figuring out those steps on your own. Another reason people struggle with projects is that they compare their intermediate steps with someone else's finished product and get discouraged.

The truth of approaching a project isn't as neat as the tutorials (mine included) make it seem. The reality is that rather than belting out lines of perfect code, projects are done in small pieces with plenty of trial and error and a healthy dose of searching through reference materials.

In this article, you'll learn how to approach JavaScript projects on your own.

Important note: As you go through this article, you'll see some code examples. If any of them seem new or unfamiliar, it's okay to skim over them for now. The purpose of this article is to have you understand the overall process of approaching a project rather than getting distracted by technical details.

First Get Comfortable With the Basics

At a minimum, you'll want to get familiar with some of the basics of JavaScript (and programming in general). This might include variables, functions, if statements, loops, arrays, objects, DOM manipulation methods, such as getElementById, querySelectorAll, and innerHTML. You can Google these or look them up on MDN when you're done with this article.

Once you're comfortable with these concepts, you'll move much faster because you can focus on creating your project instead of worrying about how to write an if statement.

A lot of people rush past this step, and everything takes longer as a result. It's like attempting to play Level 3 of a video game without getting comfortable with the controls back in Level 1. Lots of avoidable frustration.

Make a Plan

How JavaScript Projects Happen

Instead of jumping in and trying to do your project in a series of linear steps, take some time to look at the big picture first. Make a general plan. What sorts of things need to happen? For example, if you're trying to make a countdown clock, you might need a way to measure time, a place to hold the data, somewhere to display the numbers, and maybe a way to control the clock.

At this stage, you don't want to get bogged down in technical details because you're still thinking through the general ideas of what you want. As long as you have an overall plan, you'll have guideposts that will prevent you from getting too badly lost. In software design. this technique is often referred to as a use-case analysis.

Write It Without Code

Now that you have your plan, you'll want to figure out the details. My favorite way to do this is to write specifically what you want each part of your project to do. The key is to write it not in code but in plain language. (This is called pseudocode.) That way, you can think clearly about what your project is doing without getting distracted by syntax details.

For a countdown clock, your notes might look something like this:

  • Get current time
  • Specify end time
  • Find difference between current time and end time to get remaining time
  • Repeatedly get the remaining time for each step of the countdown
  • Show remaining time on screen at each step of the countdown

You can break individual parts into smaller pieces like so:

  • Show remaining time on screen at each step of the countdown
    • Divide time into hours, minutes, seconds
    • Show hours in one container
    • Do the same for minutes and seconds

Once you have your logic written out, you'll have a much easier time writing code. This is because it's simpler to write the code for a concrete step such as "subtract current time from end time" than it is to write the code for a whole project like "build a countdown clock."

Also note that you won't need to have a perfect series of steps written out at the beginning. This is a fluid process where it's okay to add things, remove things, get things wrong, learn, and improve.

Continue reading %What Tutorials Don’t Tell You: How to Approach Projects%


by Yaphi Berhanu via SitePoint

No comments:

Post a Comment