【The Ecosystem of IT Workplaces】The Rituals of Debugging: Differences Between Geniuses, the Highly Skilled, the Average, and Beginners

　A system's bad mood always arrives abruptly.

　A screen that was working perfectly until yesterday suddenly goes silent one day.
　Or, it spits out values that should be impossible.

　At such times, a unique sense of tension runs through the IT workplace.

Debugging.

　Identifying and fixing the cause of a bug.
　Put into words, it sounds simple, but no other task exposes a person's true nature quite like this one.
　The speed of their keystrokes, the intensity in their eyes as they glare at the monitor, and above all, the path they take to reach a solution.

　There exists a cruel 'hierarchy' within it.

Those who pray in the labyrinth, those who unfold the map

　The debugging performed by the so-called beginner tier is somewhat akin to a religious ritual.
　Before they even think about why an error is occurring, their fingers are already moving.
　They rewrite whatever looks suspicious, restart, and press the execute button as if praying to a god.

　Once, a junior colleague working next to me kept rewriting the same code over and over, sighing each time.
　Even when I asked, 'What do you think is the cause?', he would only repeat, 'It was working until yesterday.'
　This is not analysis; it is an attachment to the past.
　Even if they happen to fix it by luck, they don't understand why it was fixed.
　That is why, a few days later, they will wander back into the same labyrinth of bugs.

　On the other hand, the average engineer becomes a steady investigator.
　They love the gritty technique known as print debugging.
　They embed markers throughout the program, such as 'reached this point' or 'current value is 100,' and trace the footprints.
　It takes time, but there is a craftsman's integrity in the way they corner the culprit step by step.

A sharp scalpel and a quiet prophecy

　When you reach the highly skilled tier, the landscape changes completely.
　Before looking at the code, they construct the system's structure in their minds and wield a scalpel called a hypothesis.

　'If it crashes at this timing, the bottleneck is either in the memory or the communication.'

　They make such an educated guess and identify the cause with minimal investigation.
　To them, a bug is not an enemy, but merely a kind notification pointing out a flaw in the system.
　While fixing it, they polish the surrounding code as well, leaving it in a more beautiful state than before.
　Their efficiency is like watching a skilled surgeon.

　However, on rare occasions, you may encounter the breed of people called 'geniuses' who are even above that.
　Their debugging is no longer even deduction.

　The moment they hear a report of trouble, without even touching the keyboard,

　　'Ah, the conditional branch over there is reversed.'

they mutter.

　Perhaps the entire system is constructed three-dimensionally as complex gears within their brains.
　Can they hear the distortion of logic as a sound, or see it as a color?
　Problems that an ordinary person would agonize over for three days and three nights, they solve in the time it takes to take a sip of coffee.

What lies there is an overwhelming difference in 'vision'.

In Conclusion

I feel that one's style of debugging is directly connected to how one faces the world.

When faced with the unknown, do you pray, do you walk, or do you think?
Or, do you simply stare?

While we admire the brilliance of geniuses, we are saved by the grit of ordinary people.

An ecosystem in the workplace where efficiency is not the only virtue.

Through the work of filling in the small cracks called bugs, someone is updating themselves again today.

[Note 1: The Ecosystem of Debugging Styles]

[Beginner] The 'Exorcist' who tries everything and hopes for the best

・Characteristics: Does not think about the cause; just rewrites suspicious areas and runs the code.

・Example: When an error occurs, they just repeat 'restarting' or 'copy-pasting'. Since they don't know why it was fixed, they create the same bug again the next day.

・Perspective: Debugging that is close to gambling. When it is fixed by luck, they say, 'Oh, it just started working'.

[Average Person] The 'Investigator' of steady research

・Characteristics: Their main battlefield is 'print debugging', where they embed a massive amount of print or console.log statements.

・Example: They hunt for the culprit from a mountain of logs. Because they proceed step-by-step with a dragnet operation, it takes time, but they surely reach a solution.

・Perspective: A world of effort and perseverance. Their screens are filled with execution logs.

[High Performers] The 'Scientists' Who Manipulate Hypotheses

- Characteristics: Before looking at the code, they form a hypothesis—'If this is the behavior, the cause must be here or there'—and verify it with minimal steps.

- Case Study: They master debuggers, vividly visualizing memory contents and communication paths. They don't just fix the bug; they implement a 'mechanism to prevent it from ever happening again' on the spot.

- Perspective: Efficient and elegant debugging. After they pass through, the code is cleaner than it was before.

[Geniuses] The 'Prophets' Who Converse with Code

- Characteristics: The moment they hear a report, they point out, 'Oh, the inequality sign on line 328 is reversed.'

- Case Study: They have the entire complex system mapped out in their brains. They reach a level where they don't even use a debugger, simply looking at the screen and saying, 'The bug stands out.'

- Perspective: To the average person, it's nothing short of magic. They aren't sensing bugs as physical phenomena, but rather perceiving distortions in logic.

[Note 2: Categorizing Styles]

In the unique 'ecosystem' of an IT workplace, debugging is not just a bug-fixing task; it is a ritual that clearly reveals an engineer's personality, experience, and the health of the project.
I will categorize these 'styles' by their approach and mindset.

(1) Styles of Inference and Hypothesis (Thought Process)
The core of debugging lies in solving the mystery of 'why it happened.'

- Deductive Approach (Process of Elimination)
A steady style of eliminating possibilities one by one, thinking, 'If A is normal, then B must be the cause.'

- Inductive Approach (Pattern Recognition)
A veteran style of using intuition to guess the target based on past experience, thinking, 'If it's this error message, it's usually that.'

- Rubber Ducking
A technique where you explain how the code works to someone (or a mascot), allowing you to notice contradictions in your own logic.

(2) Styles of Tools and Technology (Debugging Methods)
This is about how you choose your weapons to corner the 'culprit.'

- Print Debugging Group
They embed console.log or print statements everywhere to track the movement of variables during execution with their own eyes. It is the most primitive yet powerful method.

- Step Execution Group
They make full use of debuggers (IDE features) to stop the program line by line, observing the state of memory and the call stack in detail.

・Binary Search (Bisect)
Examine the middle point between a past version that worked correctly and the current version where it stopped working to narrow down which change caused the issue.

(3) Styles of Environment and Reproduction (Controlling the Situation)
To "catch" a bug, you must first put it in a "cage."

・Creating a Short, Self-Contained, Correct (Compilable) Example (SSCCE)
Isolate the minimal code that triggers the bug from a complex project. This in itself is a shortcut to a solution.

・Cloning the Environment
To eradicate the "it works on my machine" problem, use container technology like Docker to completely reproduce the environment where the issue is occurring.

・Log Mining
Connect the dots from vast server logs by using specific time axes or user IDs as keys to form a clear picture.

(4) Styles of Mentality and Philosophy (How to Approach It)
The mental state of an engineer during debugging is directly linked to the quality of the code.

・The Spirit of "Doubting Yourself"
Before suspecting bugs in libraries or the language itself, thoroughly doubt the code you wrote and your own assumptions first.

・Sleep-Driven Debugging
If you get stuck in a quagmire, go to sleep. The phenomenon where you find the solution in five minutes the next morning when looking at the screen with a refreshed brain.

・The Boy Scout Rule
While fixing a bug, clean up the surrounding messy code just a little bit before you leave.

[Related Articles]

☆Ecosystem of the IT Workplace

☆The Path of a Project Manager

☆The Small Path of Project Management

Book Introduction

・Practical Software Engineering 2nd Edition: Key Points of Software Development Learned from the Field - Top SE Introductory Course Kindle Edition
By Osamu Asai, Supervised by Haruhisa Ishida Format: Kindle Edition
Kindai Kagaku Sha (2019/4/1)
Systematizing practical knowledge and theory that can be applied in development sites!
The second edition of "Top SE Introductory Course 1: Practical Software Engineering," which was well-received for comprehensively introducing software engineering knowledge from a field perspective.
Following the chapter structure of the first edition, items have been added, and new terminology explanations have been included to further enrich the content. A book that allows even beginners without software engineering knowledge to learn theories that can be applied in development sites. Also ideal for field engineers to relearn.
( * Book descriptions, etc., are generally based on the descriptions on the linked site (Amazon). Please refer to the link for detailed content.)

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-

・A Guide to the Project Management Body of Knowledge (PMBOK Guide) 7th Edition Kindle Edition
+ The Standard for Project Management: Supervised translation by PMI Japan Chapter
By Project Management Institute (PMI)
PMI Japan Chapter (2023/1/6)
( * Book descriptions, etc., are generally based on the descriptions on the linked site (Amazon). Please refer to the link for detailed content.)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-

・Illustrated Instant Combat Power: A Textbook to Thoroughly Understand PMBOK 7th Edition Knowledge and Methods in One Book (Kindle Edition)
　Kazuya Maeda (Author)
　 Gijutsu-Hyohron Co., Ltd. (2024/9/20)
　This is an explanatory book for the PMBOK Guide 7th Edition, known as the global standard for project management. In addition to fundamental project management knowledge such as "Project Basics," "Value Delivery System," and "12 Principles," it provides detailed explanations of the "8 Performance Domains," which can be considered the main theme of the PMBOK 7th Edition. This book is recommended not only for studying project management but also as a first step in preparing for the PMP exam.
(* Book descriptions are generally based on the descriptions provided at the link (Amazon). Please refer to the link for detailed content.)

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-

・Illustrated Introduction: Easy-to-Understand Latest PMBOK 6th Edition Basics (Kindle Edition)
　Yasuji Suzuki (Author)
　 Shuwa System (2018/3/23)
　The PMBOK Guide is translated and published in 11 languages worldwide, including Japanese, by the Project Management Institute (PMI). Even when translated, it is often difficult to understand due to the abundance of technical terms and katakana terminology. In this book, the author, who also served as the leader of the translation and supervision team for the "PMBOK Guide 6th Edition," breaks down the original meanings as simply as possible. It uses plenty of illustrations to make it easy to visualize, making it accessible for everyone from beginners to veterans.
(* Book descriptions are generally based on the descriptions provided at the link (Amazon). Please refer to the link for detailed content.)

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-

・A Book to Thoroughly Master the Basics of Project Management in One Volume (Kindle Edition)
　Kazuya Maeda [Author]
　Gijutsu-Hyohron Co., Ltd. (2022/06)
　This book is an introductory guide that allows you to learn project management from the basics. After explaining the fundamental knowledge of project management, it divides projects into five stages: "Initiating," "Planning," "Executing," "Monitoring and Controlling," and "Closing," and carefully explains what should be done and the points to be aware of at each stage.
(* Book descriptions are generally based on the descriptions provided at the link (Amazon). Please refer to the link for detailed content.)

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-