Rules for Debugging

Here's the situation.

Someone wrote code. It didn't do what they assumed it would do.

They come to me for help.

Here are my rules for debugging. All of them.

1. Try something else.

---

I don't have any other or more clever advice. When I look at someone's broken code, I'm going to suggest the only thing I know. Try something else.

I can't magically make broken code work. Code's not like that. If it doesn't work, it's wrong, usually in a foundational way. Usually, the author made an assumption, followed through on that assumption, and was astonished it didn't work.

A consequence of this will be massive changes to the broken code. Foundational changes.

When you make an assumption, you make an "ass" out of "u" and "mption".

Debugging is a matter of finding and discarding assumptions. This can be hard. Some people think their assumptions are solid gold and write long angry blog posts about how a language or platform or library is "broken."

The rest of us try something different.

My personal technique is to cite evidence for everything I think I'm observing. Sometimes, I actually write it down -- on paper -- next to the computer. (Sometimes I use the Mac OS Notes app.) Which lines of code. Which library links. Sometimes, i'll include in the code as references to documentation pages.

Evidence is required to destroy assumptions. Destroying assumptions is the essence of debugging.

Sources of Assumptions

I'm often amazed at how many people don't read the "But on Windows..." parts of the Python documentation. Somehow, they're willing to assume -- without evidence -- that Windows is POSIX-compliant and behaves like Linux. When things don't follow their assumed behavior, and they're using Windows, it often seems like they've compounded a bunch of personal assumptions. I don't have too much patience at this point: the debugging is going to be hard.

I'm often amazed that someone can try to use multiprocessing.apply_async() without reading any of the example code. What I'm guessing is that assumptions trump research, making them solid gold, and not subject to questioning or locating evidence. In the case of multiprocessing, it's important to look at code which appears broken and compare it, line-by-line with example code that works.

Comparing broken code with relevant examples is -- in effect -- trying something else. The original didn't work. So... Go to something that does work and compare the two to identify the differences.

The Passive-Aggressive Programmer (again)

I'm not even interested in psychology.  But.  This kind of thing seems to come up once in a great while.

You're asked (or "forced") to work with someone who—essentially—fails to cooperate.  They don't actively disagree or actively suggest something better.  They passively fail to agree.

In fact, they probably disagree.  They may actually have an idea of their own.

But they prefer to passively "fail to agree."

I have little patience to begin with.  And I had noted my personal inability to cope in The Passive-Aggressive Programmer or Why Nothing Gets Done.

Recently, I received this.

"I thought I was going crazy and started doubting myself when dealing with a PAP co-worker. I went out on the internet searching for help and ran into your blog and its helped me realize that I'm not crazy. The example conversations you posted are almost every day occurrences here at my job when dealing with my co-worker. From outside of the department it was oh those two just butt-heads because I never knew how to communicate or point out that really I'm a targeted victim of a PAP rather than a butting heads issue. No matter what approach I took with the PAP I was doomed and still not quite sure where to go from here. Would you happen to offer any advice on how to actually deal with PAP? It's driven me to a point where I'm looking for new employment because my employer won't deal with it." 

I really have no useful advice.  There's no way to "force" them to agree with anything specific.  In some cases, there's no easy to even determine what they might agree with.

Your employer will only "deal with" problems that cause them real pain.  If you're butting heads, but still getting things done, then there's no real pain.  You're successful, even if you're unhappy.

If you want to be both happy and successful, you need to stop doing things that make you unhappy.  If you can't agree with a co-worker, you can butt heads (which makes you unhappy) or you can ignore them (which may make you happy.)

Ignoring them completely may mean that things will stop getting done.  You may appear less successful.  If you stop being successful, then your employer will start to feel some pain.

When you employer feels pain, they will take action to relieve the pain.

You might want to try to provide clear, complete documentation of your colleague's ideas, whatever they are.  If you write down the Passive-Aggressive Programmer's "suggestions", then you might be able to demonstrate what's causing the pain.  Since a properly passive programmer never actually agrees with anything, it's tricky to pin them down to anything specific.

You might be able to make it clear that they're the roadblock that needs to be removed.