I generally go through something like the following steps:
* I look at the readme if it exists
* I pull down the project and run any setup steps (install dependencies, start up database, etc).
* If there are tests, I try to get the tests to run (this may lead to additional setup)
* Once I get the tests to run, I make sure they are all passing
* If it's an application (as opposed to a library) I will get it up and running on my computer and play around with it as a user.
* Finally I will start scanning the source code - Starting with the main app, and digging down where it seems relevant.
* If I am looking for some specific functionality, I let that guide my perusal of the source, otherwise it's just looking at the major pieces - routes, views, models, etc. to get a feel for what the relevant parts of the app are.
I'm using Clap[0] for a command line project I'm doing in Rust. The API for it is fantastic, and the examples are very well commented. Overall it's the best library I've run across in a while.
The biggest thing I see is not considering edge cases.
They'll have a certain way they are checking a few cases (and maybe a couple tests), but they don't have the foresight to really try to break things. They will also make assumptions about how the code will be called, what entities will exist at that point, etc. that just don't hold in reality.
This typically manifests in code that works fine when they use it, and all the tests pass, but it breaks as soon as it gets up on the staging server, or as soon as somebody else tries to use it.
Also:
Not listening to feedback from senior devs.
Drastically underestimating the complexity of what they are working on.
If the puzzle questions seem like high school math, I second the idea of building something. Try to get a website set up if that interests you. If not, try building a command line tool to help you with something you do regularly.
The act of trying to build something that works is an incredible learning experience, and will teach you a lot about whether or not programming is something you should pursue.
Project Euler does have a lot of good puzzles, but as parent comment says, they're more math related. If you don't like them (FWIW I never managed to get into them) you shouldn't necessarily think that programming isn't for you, as it can also be about building neat software that people use. As others have said here, you should try to get a feel for if you enjoy programming and what sorts of things you enjoy programming, because there is a lot you can do with it. If you don't like the math side, try building a simple app or web page and see if that interests you
I'm definitely not obsessed with programming. I can force myself to practice regularly, though. All it takes is discipline.
I wouldn't pursue it if it wasn't lucrative; that'd be irrational. But I'm not interested in money alone. I also want time, and the ability to create things that generate some sort of business value. Does an investment banker like what they do on a day-to-day basis? Plugging stuff into Excel? No, that's mind-numbing. But they get their satisfaction from seeing a deal that they participated in featured on WSJ.
I also want a hard skill. Being an "idea guy," doesn't cut it.
Udacity's intro to CS course is really good. Not sure if it covers all your bases but it definitely hits most of them. Note I'm not talking about the programming foundations in Python course.
