A brain-dump of various approaches to debugging (code) things that I like.

• Development is mostly debugging
  • You could even say that it is ALL debugging
  • Implementing a feature is fixing the lack of that feature
• Types of bugs
  • Syntax
  • 500 server error
  • Unexpected output
  • Legit issue that is not communicated to the user well
  • Configuration issue -- routes, library setup
  • Security issue
  • Generally undesired behavior
• Read the documentation
  • "Use The Source, Luke" -- Wise Sage
• Dead Debugging vs Live Debugging
  • Dead Debugging -- you can't (easily) run the code or modified versions
  • Live Debugging -- make a change, see result, breakpoints, everything
• What's even happening
  • Build your feedback loop
    • Write log entries to SEE what is happening instead of guessing
    • Build shortcut to getting to the critical point
      • This is a great spot for leveraging unit/feature specs
      • Have a fast way to re-start -- like a save point in a game
      • Re-send XHR in browser, or open in new tab! Copy Curl command!
  • Get some visibility
    • You can't debug what you can't observe or infer
    • Observing is easier than inferring
    • Log-based debugging (print "here")
    • Debugger-based debugging (binding.pry)
  • Why is it this way anyway?
    • Revision control ... did someone do this on purpose?
• State -- Best friend. Worst enemy.
  • Think about inputs, outputs, and state
  • Local variables, parameters, scoped variables, global variables
  • Look at the actual database / storage
    • The state that exists even when your program isn't running
  • State CHANGES over TIME
    • This is why multi-process debugging is so hard... competing timelines
• Model the world. Beware of assumptions!
  • Don't assume!
    • LOOK at the contents of variables
    • RUN methods and see what they return
    • LOOK at the code you're calling and what calls you
    • VERIFY that it's even running this code at all
    • LOOK at the revision history to get some time-context
      • Did this change recently?
      • Was this put here on purpose?
      • Look at the annotation, the commits, the commit-messages, the linked tickets
  • Verify assumptions
    • Add an "X" and see if it shows up on the page where you expect
    • Add a syntax error and make sure it breaks. Delete everything and make sure it breaks.
    • Hard-wire weird values in place of method calls
• Narrow the problem
  • Simplify reproduction steps
    • Try to figure out what you care about and what you don't
    • See if you can reproduce the issue without some of the nuance
    • Remove the weird bits one at a time
    • The less steps it takes to cause the problem, the less you have to think about
  • Figure out where this code even lives
    • grep!
      • ack, ripgrep (rg), atom/vscode search, ...
      • See some text
    • Trace from entrypoints
    • Trace backwards from the error if you have one
    • Read the stacktrace!
    • Copy some random text from the screen and grep for that
  • Bracket the issue
    • Hard-wire values
    • Interactive Unit Testing
    • Log state at various points of execution
  • Read the error message
    • Sometimes ... often ... it will actually TELL you what is wrong
    • Even when it is vague or lying it is a good stating point to trace backwards from
    • Often it comes with a stack trace -- read the stack trace!
  • Read the log entries just before the error message
  • Trace forward and backward from the error
    • Learning who calls what in any language is necessary knowledge
• Execution Environment
  • Use a completely different dataset / environment to reproduce
    • Go beyond "Works on my machine!"
  • Eliminate your environment as the unintended cause of the issue
    • Speaking of environments, use asdf or similar and don't install using sudo
    • Try a different browser, or incognito, or different OS
    • Ask a friend!
• Structured thinking
  • Try to think about less things
    • Chunk concepts into short-term memory
    • Take notes
• Modify the world
  • Don't suffer in the current world, switch to the one you wish you had
  • Build tiny scenarios
    • Create toy worlds to play in
    • H1 tags should be clickable ... make a new component with an H1 tag and an onclick and ... click it
  • Edit your dependencies!
    • bundle open
    • pry your way in
  • It's more obvious what a variable contains when it is hard-wired
• Actual bug hunting in a living application
  • Did this work before?
    • What changed?
    • Assumptions about the data
    • Assumptions about the external world
    • Why did it change?
    • Why did this ever work?
    • Do we have tests around this? What do they assume?
• Why does this work sometimes and not others?
  • SOMETHING about the state is changing
  • The ordering in the sequence of events
  • The datatypes
  • External state is changing (and depended on)
    • Time! My favorite. (TimeCop)
      • Especially time zones, DST, and holidays
    • Other systems
  • The world is deterministic but chaotic
    • Unless you are dealing with quantum physics
    • You are not dealing with quantum physics
• When you are stuck
  • Model the problem in detail
    • Draw pictures of the data-flow
    • Draw pictures of the data-structures
    • Sequence diagrams are good for complex interactions, especially timing issues
  • Science!
    • "Remember kids, the only difference between screwing around and science is writing it down" -- Adam Savage
      • https://www.reddit.com/r/mythbusters/comments/3wgqgv/the_origin_of_the_remember_kids_the_only/
    • The tool of last resort?
    • When things can't fit in our tiny brains
    • Write it as a test
    • Write it on paper
    • Write it on a whiteboard
    • Write it in code (aka Test Driven Debugging)
  • Ask for help!
• The problem is not in the language
  • You did not find an implementation error in Ruby (unless you are reading C code)
  • You did not find an implementation error in Linux (unless you are reading C code)
  • It is almost definitely not the framework
  • It is probably not the library
  • Prioritize your suspect list based on probability
    • How many people use layer X without issue?
    • Linux -- LOTS
    • Ruby -- Lots
    • Rails -- Lots
    • app/models/my_biz_logic.rb? Not so many
• How to practice
  • Pick something on the screen and find the code that makes it
  • Modify the code to see that you can affect change
  • Trace the code to see how it goes from Browser -> code -> Browser
  • Write failing tests that would have caught the issue
  • Try out different tools -- debuggers, REPLS, editors, git things
  • Read (trace!) code of your app, your dependencies, other applications
• Write More Tests
  • Unit tests are like robot-you that are validating assumptions all the time
  • Unit tests are a shortcut to get into situations quickly
  • Tests can contain bugs!
  • Feature (browser tests) verify that things fit together
• Key tools
  • grep/rg
  • Your editor
  • Pry/irb/byebug, js debugger+firefox/chrome
    • pry-byebug
  • rspec/capybara
  • diff -u
  • bundle open <lib> / gem open <lib>
• Crazy power tools
  • git bisect
  • rspec bisect
  • ruby -rtracer hiya.rb
  • strace / dtrace
  • wireshark/Proxy? xxd? decompiler?