Thanks Joe .. didn't know about the channel. Will check it out.

I ask someone to draw me a diagram of higher-level architecture as an intro to know what is communicating with what. Then I dive into the code and I start understanding it in one part of the application - you can go and fix easy bugs as proposed. Once you have basic under of one part of the app, you can proceed to next part while looking back at the higher architecture.

I don't consider mentioned code a bad or newbie practise. I prefer to write the code this way, because it tells you more explicitely what are you testing. You might get wrong behaviour using this approach, consider this: if ({}) { console .log( 'true' ) } else { console .log( 'false' ) } // true if ([]) { console .log( 'true' ) } else { console .log( 'false' ) } // true if ({} === true ) { console .log( 'true' ) } else { console .log( 'false' ) } // false if ([] === true ) { console .log( 'true' ) } else { console .log( 'false' ) } // false Also, comparing objects in Javascript using double-equals can create unwanted behaviour, hence it's recommended to use three-equals operator: console .log( 99 == "99" ); // true console .log( 0 == false ); // true Read more here https://www.impressivewebs.com/why-use-triple-equals-javascipt/

I'm not sure if that meant to be "writing tests" or TDD itself. IMHO 40% more bugs is definitely possible (if you have 10 bugs, then 4 more; if you have 5 bugs, then 2 more;) .. I don't like "religious approach" either but I find myself writing fewer bugs when I write tests first.

Here's what Eric Elliot (one of the famous JS developers) wrote recently on TTD: What happens if you don’t want / like / can’t use TDD? 40% — 80% more bugs in production. What happens if you don’t want / like / can’t have other people reviewing your code? 33 hours of extra maintenance for every hour that would have been spent on code review (note: the studies these numbers are pulled from used static types.) Basically, skipping TDD and code review is a ridiculously bad idea — even if you use static types. It is well accepted that types make a software more robust. Define “more robust”. If you mean fewer bugs, it may be true that’s the popular consensus, but it’s not based on any real evidence that I’m aware of. A lot of people once believed the world was flat, too. True, that you can try to accomplish robustness through other means besides types. TDD, code review, x, y, z, etc. Yeah, but there’s some good evidence to support those bug-reducing methods… not so with static types. I have been doing it for a long time and it has proven itself to make my code more robust (without TDD and code reviews). I absolutely believe that you feel like static types help you write better code. I felt that way, too! Static types provide a very effective Linus blanket. They make us feel better, but static types don’t reduce bugs by much. View full conversation here: https://medium.com/@_ericelliott/40-80-more-bugs-in-production-6c4d6d55edae#.q7mb9agr2