bradcomp

Hey foxhop. How would we reach out? You don't have an email on your profile.

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.

[0]: https://github.com/kbknapp/clap-rs

I really like Different Kinds of Darkness by David Langford. http://www.lightspeedmagazine.com/fiction/different-kinds-of...

Definitely this xkcd: https://xkcd.com/1171/

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.

I've been digging into Haskell in the time I have to program at home. Im going through the course at http://www.seas.upenn.edu/~cis194/spring13/lectures.html.

In addition to the classes, I've been trying to use it to write small programs and whatnot.

While I can't use Haskell at work, I can say working with it more regularly has definitely improved the JavaScript code I write on the job.

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.

I think aptitude is overrated compared to overall drive / obsession. You should pursue programming if it's something you want to pursue.

Do you like solving problems? How stoked are you when you figure out the cause of your bug? Would you pursue it even if it wasn't lucrative?

Project Euler has some good puzzles, they are somewhat math related but cover a lot of interesting concepts and can be fun to work through.

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.

I have been listening to Partially Derivative and Talking Machines, both data science related. Talking Machines is more industry focused whereas Partially Derivative is more fun. Also Reply All, a show about the Internet. Non tech I listen to the History of Philosophy podcast.