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.
> 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?!)
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.
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.
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.
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.
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.
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!
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:
Honestly, it is 100% students/fresh grads. Recently, I copied a SQL query and spend few hours trying to understand it, then DBA reviewed it. I can't imagine anyone just going to copy/paste from stackoverflow. However, I just remember that Nissan mobile app had code copy/pasted from stackoverflow.
Going to read your old code takes some time to understand. Sometimes it even feels like someone else wrote it, but in order to provide fixes one must first understand it, then fix the bug. This cannot be copied from anywhere.
That subreddit is either very fresh juniors or cs students or people who are just getting away with being "that guy" on the team.
The subreddit is currently like that. About three years ago it was extremely high quality, but it ended up on the front page too many times, got overran by people who couldn’t understand the humor, and went through too many bad volume control/JavaScript bad posts. I’m extremely sad to see where it is now…
The actual posts were slightly better, but the comments were much better. Often you’d have some sort of silly joke but the comments would have extensive, detailed discussion by people who knew their stuff on tangential topics.
System administration isn't any different. I run into examples all the time.
I see "documentation" that is a saved website from some "How to install X on Y" blog entry. These blogs are so bad. If you google 'install x on ubuntu' you will get a bunch of hits on 'tech' blogs. Many of them just copy and paste from the same original source.
Nothing gets explained, things are installed with terrible defaults, steps are performed that aren't necessary, and necessary steps are also performed! You'll see every bad habit in the book.
StackOverflow is even worse. Well, ServerFault is where admin questions should be posted but they end up on SO. "I did xx and it if fixed it", usually xx has nothing to do with it or is something like 'chmod 777'
Nobody takes any time to read the documentation, learn anything or even question, 'what does this actually do?'. It's sad.
I've been writing an article like that, but I'm trying to go through every manual and ensure it's correct and current. You wouldn't believe the amount of work I'm putting into this, and for no reason but to practice writing or something,I don't even know anymore.
I get why people write the shitty articles now, it's really hard to write a good article about a simple install. That's no excuse, they should just not be writing articles if they don't want to work, but I understand the reason behind the influx of crap.
First: there is documentation available (many MANY stuff doesn't have docs, especially in the Javascript world, but it's become a "trend" in general software)
Second: the docs are reasonably up to date (again, Javascript... webpack drove me nuts) and the software is backwards compatible so that docs/examples from the last version still work (again, webpack serves as a fine example)
Third: the docs come with a reasonable amount of examples that cover common usage scenarios and edge cases that one may hit during implementation (Kubernetes on bare metal is just plain "fun")
Fourth: the docs are legible and understandable without boatloads of domain knowledge and in coherent English (or if it's a regional thing, the locally dominant language)! When half the documentation suffers from typo errors, is badly formatted, or (common with offshored stuff) the reader needs more time to mentally translate the gibberish to "this is what the author could have meant", then a Google search is often enough the easier way. Understandability also includes organization: Unorganized wikis or "current version" scopes including stuff from years ago that clearly is outdated are a nightmare to use.
Fifth (esp. applicable for new-ish GUI applications): documentation without illustration. No, your average user will not automatically associate your weird "flat design" button as "save".
tl;dr: Docs aren't read 'cause they're unusable.
Additionally, and this is another huge part: on Stackoverflow/Serverfault and many blogs there will be a comment section which I can glance over to see: is this answer correct/still applicable, what experiences did other people have, are there better alternatives... most docs don't have this proximity of documentation and feedback - except maybe PHP Core documentation, which on the other hand suffers from not being moderated (i.e. old/dangerous stuff isn't hidden)
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.
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.
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.
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.
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:
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/ ):
> 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!
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.
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?!)
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.
or other people's mistakes
2. Understand the problem.
3. Test your hypothesis by changing something and getting (or not) your expected behavior.
4. Fix the problem.
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.
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.
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.
https://ericsink.com/Abstraction_Pile.html
Going to read your old code takes some time to understand. Sometimes it even feels like someone else wrote it, but in order to provide fixes one must first understand it, then fix the bug. This cannot be copied from anywhere.
That subreddit is either very fresh juniors or cs students or people who are just getting away with being "that guy" on the team.
Top of front page (4 years ago): My teacher thinks he's a programmer http://i.imgur.com/32nfQXZ.png
Top now: https://www.reddit.com/r/ProgrammerHumor/comments/fvhk9l/a_b...
https://www.reddit.com/r/ProgrammerHumor/comments/4d6vl5/had...
https://www.reddit.com/r/ProgrammerHumor/comments/4dd6nx/my_...
https://www.reddit.com/r/ProgrammerHumor/comments/4dcjfc/cod...
https://www.reddit.com/r/ProgrammerHumor/comments/4dfjag/tel...
I see "documentation" that is a saved website from some "How to install X on Y" blog entry. These blogs are so bad. If you google 'install x on ubuntu' you will get a bunch of hits on 'tech' blogs. Many of them just copy and paste from the same original source.
Nothing gets explained, things are installed with terrible defaults, steps are performed that aren't necessary, and necessary steps are also performed! You'll see every bad habit in the book.
StackOverflow is even worse. Well, ServerFault is where admin questions should be posted but they end up on SO. "I did xx and it if fixed it", usually xx has nothing to do with it or is something like 'chmod 777'
Nobody takes any time to read the documentation, learn anything or even question, 'what does this actually do?'. It's sad.
I get why people write the shitty articles now, it's really hard to write a good article about a simple install. That's no excuse, they should just not be writing articles if they don't want to work, but I understand the reason behind the influx of crap.
That assumes many things:
First: there is documentation available (many MANY stuff doesn't have docs, especially in the Javascript world, but it's become a "trend" in general software)
Second: the docs are reasonably up to date (again, Javascript... webpack drove me nuts) and the software is backwards compatible so that docs/examples from the last version still work (again, webpack serves as a fine example)
Third: the docs come with a reasonable amount of examples that cover common usage scenarios and edge cases that one may hit during implementation (Kubernetes on bare metal is just plain "fun")
Fourth: the docs are legible and understandable without boatloads of domain knowledge and in coherent English (or if it's a regional thing, the locally dominant language)! When half the documentation suffers from typo errors, is badly formatted, or (common with offshored stuff) the reader needs more time to mentally translate the gibberish to "this is what the author could have meant", then a Google search is often enough the easier way. Understandability also includes organization: Unorganized wikis or "current version" scopes including stuff from years ago that clearly is outdated are a nightmare to use.
Fifth (esp. applicable for new-ish GUI applications): documentation without illustration. No, your average user will not automatically associate your weird "flat design" button as "save".
tl;dr: Docs aren't read 'cause they're unusable.
Additionally, and this is another huge part: on Stackoverflow/Serverfault and many blogs there will be a comment section which I can glance over to see: is this answer correct/still applicable, what experiences did other people have, are there better alternatives... most docs don't have this proximity of documentation and feedback - except maybe PHP Core documentation, which on the other hand suffers from not being moderated (i.e. old/dangerous stuff isn't hidden)
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.
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.
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.
... why indeed? I can't think of any (presumably fairly simple) scenario where that would happen.
>>> 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/ ):
> 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!