When debugging, attitude matters
jvns.ca
jvns.ca
or other people's mistakes
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.
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.
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...
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.
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!