My two most copied lines from Stack Overflow
(and why I try to stop, but not really)
14th of February 2021
Now, I don’t think that’s anything wrong with these lines. But they helped me when I didn’t know better and they feel safe now. I know of better or more powerful ways to solve my problems, but I come back time and time again.
Before starting out, I thought that there is a lot of straight-up copying blocks of code from Stack Overflow during development. I had it on good authority because you know… memes. So it was surprising to me that this is not really the case. Sure, I try out some code from time to time, but even if it helps, I rewrite it and fit it better into the structure of my code. Mostly it just provides an idea of how to solve a given problem. So my two favourite lines, aren’t even really code. Not it the “this code is part of the program” code at least.
First one is very simple and helped me out time and time again.
During this first year of my development, I had a chance to work with some UI components, that were very difficult to work with, when I had to inspect it. Mainly dropdowns. The tricky part was, when I had to check parts of it during the :hover and :focus events. Each time I wanted to do something in the devtools, the dropdown disappeared. I wished then what a great thing it would be to freeze time. Luckily, this time, I could.
After typing in the line into devtools, you set up the screen as you need it, and after timeout runs out, debugger opens and you can freely inspect all parts of the current DOM, without fear of parts of it disappearing on you.
Since then I discovered several different ways how to get around that problem. To me, the best one for this specific situation could be to enable the “Emulate a focused page” option in the Chrome devtools. You can check out a video presentation of how it works out in this tweet by Tomek Sułkowski(@sulco).
Ever tried debugging an element that keeps disappearing when it loses focus once you start using devtools?— Tomek Sułkowski (@sulco) September 15, 2020
Well dang me to heck there is an "Emulate a focused page" option in @ChromeDevTools just for that 🤯
(you can get it from the [⌘]+[P] Command Menu, or Global Preferences) pic.twitter.com/O17CW4KAZm
Sometimes I also use an option to set a break directly on an element in the DOM. By right clicking on it and setting a break on either removal, subtree modification, or attribute modification.
But even though I have these fancy options at my disposal, I still like to occasionally use my setTimeout line. Even though it takes a bit of dexterity and good timing to get it right sometimes. :)
git reset --soft HEAD~1
I wouldn’t really say that I’m afraid of Git. It’s more of a “I know how powerful you are, I saw a 500+ page book about you once, why am I only using a handful of commands, if something goes wrong, I’m not sure how to negotiate with you” kind of a situation.
When I first met Git it was very well explained to me. Why do we use it, when do we use it, what are the basic features. Pretty straight-forward. Until I needed to switch my branch before committing changes for the first time. I forgot the situation why I was jumping around, but let’s just say that “wip” was very popular commit message back then.
Since then I found out about git stash. And then never used it again. I know it’s probably great for this situation. I know I should be using that. I know that after the first 5 minutes I will forget about my dear git line. But still, when I have to switch a branch, I commit a good old “wip” and when I return, the line above cleans everything up.
So I’m giving myself a little challenge. Until next time, I’ll delve a bit into this git stash to get comfortable with it and to see if I like it more. Perhaps it’s time to occasionally leave something that gave us comfort before, in the past.
P.S.: To credit people that helped me out on SO with their answers, I’m adding links to the threads, where I found my answers when I needed them. (and have them conveniently collected in one spot :))