
When debugging, attitude matters - weinzierl
https://jvns.ca/blog/debugging-attitude-matters/
======
ptsneves
I agree that debugging is about attitude. Above all debugging is about
acknowledging your understanding and/or assumptions are wrong and revisiting
then. I would also say debugging is the punishment for your mistakes,and oh
boy it can be extremely punishing. I associate debugging with pain and
resilience. From me debugging is taking some problem and testing assumptions
and models until you zero in on the only possible place where the issue can
be. This zeroing in can be of different orders. Impossible conditions being
met does not mean they were met, just that somehow your program reached a
state where they are considered met. PS: coming from an embedded and systems
programing i was going to dismiss css debugging as a joke but then I realized
I have been wasting huge amounts of time getting ridiculously simple things
like centering a logo on my web site....again debugging teaches humbleness and
punishes self centered bullshit.

~~~
saagarjha
> I would also say debugging is the punishment for your mistakes,and oh boy it
> can be extremely punishing.

Well…not always. I actually like debugging, especially when the bug isn’t mine
and I’m not in too much of a rush. Diving into a completely new codebase,
trying to make sense of the behavior and come up with ways to infer things
through the lens the tooling gives you, and finally zeroing in on the
problematic code and sending a patch can be quite satisfying. It’s even better
when you learn something new and have a good war story to tell about it. (The
message was being forwarded through _what?!_ You can do that?!)

~~~
dntbnmpls
> especially when the bug isn’t mine and I’m not in too much of a rush.

Worry-free debugging. That's the life. Also, it's always great to be the one
handing out the dunce cap rather than the one wearing it.

~~~
saagarjha
There’s no need to pull out a dunce cap every time you debug; many times the
bug is complicated enough that you feel great finding it but can’t fault the
person who wrote the code.

------
jmount
When I teach coding, I teach the following. When debugging you must clear your
mind of any desire to fix the problem. You are most effective if you work only
to find and identify the problem.

~~~
flyinglizard
1\. Reliably and consistently reproduce the problem.

2\. Understand the problem.

3\. Test your hypothesis by changing something and getting (or not) your
expected behavior.

4\. Fix the problem.

------
battery_cowboy
I agree with this article, and further, there's too much googling and random
coding these days. The joke about Google was meant to be that developers
refused to memorize data structures or something, not that we have no idea how
to understand anything and should randomly use code from the internet.

I use my share of code from the internet, don't get me wrong, but I try to
figure out how it works first, as intended. Otherwise I'm just some monkey
bashing two functions together to make sparks.

~~~
umvi
Whenever I visit /r/programmerhumor I get kind of sad.

I feel like 10 years ago there was a sense of pride and camaraderie among
programmers. Programmers strove to understand both their code and the
underlying system.

Now that programming has "gone mainstream" there's a constant meme that
programmers don't understand their own code and that it's a grand mystery why
it works. Furthermore, programmers get 100% of their code from stack overflow
or Google or Indian YouTubers. Or that programmers just randomly mash the
keyboard until the errors go away.

I get that it's just CS students commiserating with each other, but I just
hate how self-deprecating it is.

~~~
baby
I realized recently that we're all working on top of abstractions created from
the people below us.

You're working on assembly stuff? Cool, you're just using a tool that people
created for you by designing the x86 instruction set.

You're working on a compiler? Cool, you're just using a tool that people
created for you by designing machine code.

You're working on a system language? Cool, you're just using a tool that
people created for you to translate some baby language into machine code.

You're working on a high-level language?

You're working with a web framework?

You're working with ...

...

In the end you realize that the people you're talking about are just the
people in the layer above you, or sitting in the middle, and you're a noob to
the people sitting below you.

~~~
battery_cowboy
It blows my mind how many layers there are between us and the actual chip
physics (the gates and other transistors). There's like 20 hardware layers of
abstraction and another 20 software layers, probably, maybe more!

~~~
acemarke
One of my favorite classic articles is this post from 2003 by Eric Sink, "The
.NET Abstraction Pile", which lists 46 separate abstractions that are involved
from clicking the "Check In" button in a networked version control system:

[https://ericsink.com/Abstraction_Pile.html](https://ericsink.com/Abstraction_Pile.html)

------
notacoward
Some bugs are caused by a moment of inattention or carelessness. Those aren't
the interesting ones. The more interesting bugs are the ones where the
programmer _misunderstood_ something - how an API works, what a structure
represents, etc. Those are the ones where attitude matters.

If the programmer is someone else, it's necessary to "get in their head" a
bit, to understand what they were trying to achieve and how, so that you can
fix the bug without breaking the code in a different way. If the programmer is
you, it's necessary to accept that you were _wrong_ about something. The job
is to figure out what, and learn the right piece of information to replace the
wrong one that was in your head.

This is where attitude comes in. What these two cases have in common is
_humility_. If you come in to the first case assuming that you know better
than the original programmer what needs to be done, you fail. If you come in
to the second case assuming that your original code was perfect and the bug
must be somewhere else, you also fail. To debug well, you have to come in with
the attitude that your knowledge is incomplete and you need to _learn_
something to make progress. This is why junior programmers often become worse
at debugging as they become more senior. It takes _effort_ to stay in that
mindset even when you do know more than others about the domain in general.

------
xakahnx
So much to relate to in this article. If I'm cycling through stackoverflow for
answers, it's because I've convinced myself I'm in over my head. Depending on
the day this is either laziness or imposter syndrome. There's always a better
resource out there, and better to find out what that is now because very
rarely am I just one answer away from completing anything.

------
xupybd
I think one key here is "documentation that you can trust makes a big
difference". I would add to that documentation you can navigate.

It took me a long time in perl to learn how to read the docs. Specifically,
what is this squiggly thing. How do I Google for that? Then I was pointed to
[https://perldoc.perl.org/perlop.html](https://perldoc.perl.org/perlop.html).

I'm also sometimes guilty of Googling for the answer because I don't want to
have to learn how to use tool X. I just want to move on to the interesting
work. That's a bad idea. It's always worth understanding what you're doing.

------
EvilTerran
_So I changed the z-index of Div A to be 5 or something. But it didn’t work!
In Firefox, div A was on top, but in Chrome, Div B was on top. Argh! Why?_

... why indeed? I can't think of any (presumably fairly simple) scenario where
that would happen.

~~~
jvns
I got a bit nerdsniped by this so here's a simple reproduction of the original
issue (which I still don't fully understand tbh) [https://codepen.io/jvns-css-
fun/pen/zYGVLXj](https://codepen.io/jvns-css-fun/pen/zYGVLXj)

~~~
Jasper_
So this is a bit of a spec oddity. It seems like the transform is forcing a
stacking context here, but for some reason in Chrome the z-index of this
stacking context is not getting assigned -- the z-index is left at 0. You can
see this by running this in DevTools console:

>>> getComputedStyle(document.getElementById('prev')).zIndex

"0"

I think this is a bug in Chrome, where it's short-circuiting the new stacking
context when a transform is specified, and not propagating the z-index to the
new stacking context. The CSS spec says ( [https://www.w3.org/TR/css-
transforms-1/](https://www.w3.org/TR/css-transforms-1/) ):

> If an element with a transform is positioned, the z-index property applies
> as described in [CSS2], except that auto is treated as 0 since a new
> stacking context is always created.

This element is positioned, so z-index should be affecting it.

You can fix it by moving the transform to the child here, but it requires a
bit of finagling. Nice catch!

~~~
sgc
Perfect example of how Chrome is the new IE. When something behaves
differently in FF and Chrome, I presume Chrome is wrong until I can prove it
otherwise.

