Debugging Bootcamp : Debugging software by first principles

Debugging production. Debugging Distributed systems, large codebases, effective SRE, thinking like DevOps ecosystem

What you'll learn
Thinking based on first principles when dealing with complex systems. Reducing down indicators to root cause instead of implementing workarounds.
Methods to isolate root cause without rushing to attaching debuggers. Building observable systems and dealing with legacy code with minimal intrusion.
Debugging as a practical deduction based process. Not getting distracted by too much irrelvant information and customer pressure of getting to a resolution.
Factors to consider in production system analysis. Specially applicable to niche problems like distributed systems.
Examples of production fire fighting to highlight the need for open minded thinking and knowledge across domains. Embedded systems as well as distributed system
Understanding systems as permuatation of components. Applicable across all software from embedded to databases to distributed systems written in any language.
Factors to consider while dealing with systems with components owned by different teams
Different engineering communication channels that dictate the scope for debugging

Requirements
Working with systems that are already shipped for real customers. Commited to deliver the best possible software exprience to the end users.
Actively involved in shipping code and building tools. Procative engineers.
Bandwidth to follow up on the references. Enthusiasm to learn more and grow in career.
Patience to understand the impact of ideas being discussed.
Willingness to followup on ideas in daily engineering tasks.
Description
Debugging is more than just attaching a debugger to a running program. Identifying the correct root cause is a skill. In addition, the complexity of distributed systems and multi-language stacks makes debugging even harder. Often debugging stops at the following questions

What are the best tools for debugging software?

How can I debug a program that is crashing or freezing?

How can I debug a program with multiple threads?

What are the best practices for debugging software?

How can I debug a program with memory leaks?

Questions the course addresses

How domain plays a role in debugging?

What considerations do software engineers make while debugging?

How to deal with stressful production debugging scenarios?

How to approach SRE?

Can all scenarios be automated for ease of debugging?

How do monitoring and observability help in debugging?

Can bugs to identified at design time itself?

What makes distributed systems hard to debug?

Why is debugging generic skills, unlike programming language expertise?

Are there software techniques beyond windbg, gdb?

How is debugging different from reverse engineering?

Debugging is an essential part of the software development process, and the ability to effectively troubleshoot and fix bugs is crucial for any software engineer. As technologies and programming languages evolve, so do the tools and techniques for debugging, so it is important for software engineers to continue learning and staying up to date with the latest debugging methods throughout their career.

Additionally, debugging is not only a key part of software development but also required for maintaining and updating the software. Identifying, debugging and resolving errors quickly and efficiently can greatly improve the stability and performance of a software system, ultimately saving time and resources for any organization.

In summary, debugging is an ongoing process that is critical for the success of any software project. Continuing to learn and improve debugging skills throughout a software engineering career is vital for the success of the engineer and the organization they work for.

The key to a long career in software is the ability to build large systems. Large-scale systems cannot be created on a single machine using a single programming language. Hence one has to evolve into a generalist engineer to lead such efforts. Irrespective of role, understanding complexity and the ability to navigate it during production firefighting is a growth accelerator in the industry.

The course takes a generic view of workflows leading to frequently occurring debugging problems in large systems. Intentionally no tool details or deep dives are included. Instead, a guidance framework is provided for the students to explore further in their day job or software projects.

Distributed systems are a challenge to debug. Not understanding a problem can easily lead one to debug the wrong services and stacks. It is always a communication problem first. Focus on building a generic debugging mental framework instead of becoming dependent on tools like windbg and gdb as the primary response to any situation.

This course is for people who consider themselves problem solvers ahead of their designation and qualifications. For example, if you believe only developers should debug or only support should talk to customers, then this course is incompatible with your ideas.

Who this course is for:
Beginner programmers who have recently learned C++, Java, Python, JavaScript and want to understand how real life production systems work.
Developers, QA, Support engineers looking to working in startups or want to join startups as thier next job
Engineers working on call rotation for customer support
Software engineers working with SRE team or as SRE members. Dealing with production on a regular basis.
Engineers looking to grow in roles of senior software engineer, team lead, tech lead
Active programmers in any language with multiple language based systems or products. Dealing with multiple services written in C++, Java, Python, Rust, GoLang, JavaScript.
Students looking forward to work in software industry