thelackthereof

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 starting 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?

THE LACK THEREOF

Various musings of Brock Wilcox (@awwaiid)