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.

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.