One of the most important things I tell newcomers to programming over and over is to start with the easiest puzzle pieces, over and over. It’s so vital to success that you can cut problems into sub-problems and then solve them and fit the solutions back together.
This almost never means that you start writing at the top of the file and continue for 200 lines without changing or deleting a line. It’s an iterative process.
Often when I build services and something that’s going to run for a while, I start by doing the simplest version of what I want to do.
Let’s say you want to build a web form that reveres text and gives it back to the user, you’re looking at a couple of different steps like:
- build interface for user to input text
- build server route to accept the POST or GET request
- build the logic to reverse the text
- build the part that sends the response with a pretty stylesheet
Now what’s the part that you’d find hardest about that? Do you know what all the words mean?
If not, you’ll need to get a quick overview, you might consider using a framework STOP!
Ignore everything of that list you’ve done before and jump to the part you really want to do, write one simple function that upon running your file or accessing your route does the specific thing you want it to do.
var a = "myword"; var b = a.split("").reverse().join(""); console.log(b); # output: "drowym"
Next question, how do you test if your function or your way of doing it works? Do you fire up a boilerplate generator for some web framework?
node in the command line.
The point is, just do stuff and don’t do it in your project. Cut out all the unknowns until you have to deal with them. Try learning one thing at once. After you have something working, move on to the next part. With every step you’ll remember something more, often not all of it.
When you’ve dealt with a number of components at once, move on to more complex tasks or do things right where they’re supposed to go.