Ruby Video
Talks
Speakers
Events
Topics
Leaderboard
Sign in
Talks
Speakers
Events
Topics
Use
Analytics
Sign in
Suggest modification to this talk
Title
Description
Does your code work? Probably not. The libraries you're using probably don't work either. If you're lucky, the OS does, but even then you'll probably find something wrong if you look hard enough. Debugging is the reason that the last 20% of shipping a product usually accounts for 80% of the time. And yet, there are a million blog posts and talks about writing code, but very few about figuring out why it doesn't work right once you have. So, how do you find bugs? In this talk I'll explore a set of tools and techniques that have helped me diagnose defects in everything from php code to malloc implementations. One time I even used this strategy to diagnose an outage in a codebase I'd never seen that was written in a language I barely knew and a framework I'd never heard of - in less than 5 minutes. You'll walk away with this talk with everything you need to learn how to debug anything. Help us caption & translate this video! http://amara.org/v/FGYz/
Date
Summary
Markdown supported
In the talk 'How to Debug Anything' at GoRuCo 2014, James Golick discusses the complexities of debugging in software development, emphasizing that while many resources focus on writing code, few address the critical skill of diagnosing why code does not work. He highlights that debugging often consumes a significant portion of the time necessary to ship a product, especially given the rapid innovation in software engineering. ### Key Points Discussed: - **Understanding Software Bugs**: Golick points out that software is inherently buggy and unreliable due to the rapid pace of innovation in the field. He stresses the importance of accepting that issues will arise at all levels of the software stack. - **Debugging Methodology**: He proposes a consistent methodology for debugging, regardless of the programming language or system complexity. This methodology begins with an open mind, devoid of assumptions. - **Case Study Example**: Golick shares a real-world example involving a non-technical friend whose PHP website was down. Lacking access to the code or detailed system knowledge, Golick used system call tracing (strace) to identify the root causeāa missing file leading to a server error. This process took under five minutes and highlighted the effectiveness of systematic debugging. - **Tools for Debugging**: He advocates for using various debugging tools, emphasizing the utility of 'strace' for understanding system-level interactions and identifying failures. He encourages learning multiple tools based on the development environment. - **Third-Party Input**: One important rule is to seek third-party opinions during debugging sessions. This approach can provide fresh insights that may lead to quicker problem resolution. - **Finding the Right Source Code**: Golick discusses the challenges of accessing the correct source code and emphasizes its importance in effective debugging. - **Learning Through Debugging**: He concludes that debugging not only resolves issues but is also an opportunity for learning, particularly in unfamiliar systems or languages. ### Conclusion: Golick summarizes his debugging process with actionable steps: forget what you think you know, seek third-party opinions, find the correct source code, identify areas that need attention, and then proceed to fix the issue. The talk equips the audience with practical insights to improve their debugging skills, thus enhancing their software development practices.
Suggest modifications
Cancel