Prove It.

Episode Summary

This week we walk through some awesome tips from Pragmatic Programer Chapter 3. We talk through debugging strategies, challenging assumptions and more.

Episode Notes

Stubs/doubles vs mocks

Stub is simple fake object. It just makes sure test runs smoothly.
Mock is smarter stub. You verify Your test passes through it.

Good stack exchange link on this

Tip 26: "select" isn't broken (debugging strategies)

JP: "what does your program think is going on": DON'T BLAME EXTERNAL FACTORS FIRST. It's probably your code haha!

John: why, when faced with a "surprising" failure, you must realize that one or more of your assumptions is wrong.

Tip 27: Don't assume it - prove it

JP: "routine" code isn't infallible! did you test all of the edge cases?

I really like the debugging checklist so here it is:

  1. Is the problem being reported a direct result of the underlying bug, or merely a symptom?
  2. Is the bug really in the compiler? Is it in the OS? Is it in your code?
  3. If you explained this problem in detail to a coworker, what would you say?
  4. If the suspect code passes its unit tests, are the tests complete enough?
  5. Do the conditions that caused this bug exist anywhere else in the system?

John: Duplicate the problem in tests.

Tip 28: learn a text manipulation language

examples of text manipulation:

JP: Funny enough, Hunt and Thomas like using Ruby (and Perl) to quickly hack short scripts

John: I want to push more into this - Just barely experimenting with self-creating API docs. Even just things like in ruby: writing a rake task to pull out all your custom objects and methods to start docs and get a clear picture has been helpful for me.

Tip 29: Write code that writes code

passive vs active code generators

passive = run once to produce a result
active = run every time you need a result. results are then thrown away

JP: meta programming? code gen doesnt have to be meta

John: Refactoring methods to "Find common resources" based on "Model" name - Reducess code significantly.