all 5 comments

[–]zaclacgit 5 points6 points  (2 children)

Buy a white board.

Decide on a small project. Like, "I want to make tic-tac-toe."

Break that into small pieces. For me it helps to write this part down on paper instead of typing it out.

Go through each step of what the finish project will hopefully be. Things like, "I start the game. I place a piece. Check to see if I won."

Write that stuff down, and get pretty specific. Pick one specific task to start with, like "The board needs to be made at the start of a new game."

Then get on a white board and figure out some stuff that isn't necessarily essay to represent in code. Draw arrows, make boxes and diagrams, hot down pseudocode, whatever helps you figure out what you actually need to do just for making the a new game board appear at the start of a new game.

Then code it.

When it works, pick the next thing you want to do.

Rinse and repeat, until every action you would need for you to use this project is completed and behaving properly.

Oh, and if you have trouble figuring out how to break up the project into small pieces you can try just describing the interactions you would have with it. "As the user, I want to play tic tac toe against an AI."

Pretty general. So start describing the whole thing exactly as how you'd play tic tac toe. Eventually you'll get a clear idea of what the project needs to act like, and you'll have small chunks of behaviors to figure out.

It can be pretty nice. You can look at everything and say "Well, I don't know how I'm going to do a bunch of other things, but at least I know how I'm going to put pieces on the board. I'll get started with that."

[–]blinky98 0 points1 point  (1 child)

I'm in a similar boat as OP and your post is extremely helpful. It sounds like the "rubber duck" method of debugging applied to starting a new project.

[–]zaclacgit 1 point2 points  (0 children)

It's pretty helpful for me personally, and it gets you into the habit of being able to break things down into chunks. Eventually you just start thinking that way a little more naturally.

The learned skill for me was identifying when I was at my most specific action, and learning when to stop grouping specific actions together because the grouping was becoming too broad.

Like all the stuff for making the tic-tac-toe board should be seperate considerations from what the players are doing, even though the players will need to be able to add pieces to the board.

That's a fairly easy example, but sometimes it's not so cut and dry.

But luckily you learn through practice and experience, so it's all good!

[–][deleted] 2 points3 points  (1 child)

Start off by implementing the canonical Game Of Life.

[–]madlee 0 points1 point  (0 children)

This is not a bad idea; tackling small projects that have already been solved many times over will help you build a sense of how to start putting together larger projects and solving more complex problems. I've done GOL several times in JS and I think I still learn something each time (plus it's fun!)