Things Programmers Shout #808
*tests code* “Yes it works!” *tests code with other variables* “Nevermind, it just keeps returning ‘2’ which just happened to be the right answer the first time.” // submitted by @broadwayuponastar
Aqua Utopia|海の底で記憶を紡ぐ
h
YOU ARE THE REASON

izzy's playlists!

No title available
let's talk about Bridgerton tea, my ask is open

Discoholic 🪩
he wasn't even looking at me and he found me
we're not kids anymore.
Game of Thrones Daily
Stranger Things

PR's Tumblrdome
almost home

Kiana Khansmith
Sweet Seals For You, Always
$LAYYYTER
Monterey Bay Aquarium

⁂
hello vonnie
I'd rather be in outer space 🛸
seen from Saudi Arabia

seen from Singapore
seen from United States

seen from United States
seen from United States

seen from United States
seen from United States
seen from United States
seen from United States
seen from United States
seen from United States
seen from Türkiye

seen from Ukraine
seen from Türkiye

seen from United States
seen from United States
seen from United States
seen from United States
seen from United States
seen from Canada
@fyeahcode
Things Programmers Shout #808
*tests code* “Yes it works!” *tests code with other variables* “Nevermind, it just keeps returning ‘2’ which just happened to be the right answer the first time.” // submitted by @broadwayuponastar
327 Checkboxes for EU GDPR
If you’re living in the EU, Tumblr had to tell you what they’re doing with your data when you recently logged in. They also gave you the choice to disable data sharing with all their partners — for that, you just had to untick 327 checkboxes.
But fear no more, because with a bit of JavaScript I just wrote, they all untick immediately!
If you already left the page crying and screaming and with anger on your face, getting it back to apply the JavaScript is simple. On your dashboard, click on Account → Settings → Privacy and uncheck “Cookie Consent”:
Then, when on the page, click Manage Options → Manage → Show.
Open the developer console (*), paste the following snippet and press enter:
Array.prototype.forEach.call( document.querySelectorAll("[type='checkbox']"), (e) => e.checked = false );
And all your 327 problems are suddenly gone!
* How to open the console:
Chrome: Ctrl+Shift+J (Windows), Ctrl+Option+J (Mac)
Firefox: F12
Edge: F12
Safari: Go to Preferences → Advanced → tick “Show Develop menu in menu bar”; open Develop menu; click “Show Error Console”
Catching yourself writing unit tests as a method of procrastination.
I think the best piece of advice I have got ever was in my third year of CS, in an algorithms and complexity class. I remember when we went up to the blackboard and someone was stuck in some part of a problem, the professor always told us to take a step back. Literally. So I remember people took a step back (even, sometimes some people returned to their seats to see the whole blackboard) and it seemed, they magically got the answer. In those times I questioned that. How someone who has been stuck in the same problem for a long time, take a step back and then see what’s the problem?
Then, one day, I was in the blackboard and was stuck somewhere, the professor gave me that advice. One step back and I saw the blackboard in a different way. I was able to keep on writing a solution for the problem.
After that, I found it doesn’t need to be a literal step back. It can be going for a walk, drink or eat something, whatever. You know that, if you ever feel stressed and you can keep going on, relax, but you seldom do that. At least, I don’t.
So, today, I was programming something, but it didn’t work. I was 100% sure, I understood what I needed to code, but it wasn’t still working. I decided to brush my teeth and drink water; meanwhile I was summing up what I had done. I rethought the whole problem for a moment, and I got it! I was focused in the details, instead of the whole picture.
“How much is accidentally switching two OpenGL statements around?”
“That would be five hours of total despair, trying to find the cause without any errors or actually any output at all. Have fun.”
Unit tests
If you were asking me about THE one thing I’d suggest to every programmer, it’s this: Write unit tests.
Everybody knows they should, but many still don’t. Just do it. Learn the framework for your language, it’s worth it. Not only does it help you save possibly many hours of painful debugging in the long term, it also makes you rethink how you structured your code, rethink what it should be doing in the first place.
So go ahead. Pick some project, and create some tests for it. Or do it with the next project ahead. It feels good having something that works reliably, and even better being able to prove that it does.
Meanwhile in C#
(via Filip W)
Yeah. Of course. I mean, why not ;)
Debugging be like
Worst feeling: Realizing the reason for your Batch process not completing for 30 minutes was that a piece of text inside the window was selected. WHY DID I WASTE MY TIME ON THIS ?!
And yes, if you haven’t noticed, execution stops when there’s a selection in the prompt.
Not programming related, but THIS IS THE REAL ORIGINAL iPhone. Yes, that thing existed. There’s even a November 2, 1998 CNN article about it: http://edition.cnn.com/TECH/computing/9811/02/netphone.idg/
Apparently it had a “(6-by-4-1/2 inches) touchscreen with stylus, Internet scroll keys, and a retractable QWERTY keyboard“. Wow.
Consider going into a classroom and looking around, and you’re the only man there. Even if you’re totally ok with that (heck, you expected it), you notice. You feel all the women in the room notice you and see that a lot of them are glancing over at you or making comments about your presence. Ok, you knew that might happen. A woman next to you says, “Hey, cool, a guy in a CS class, good for you.” When it comes time to form a study group, half the women in the class don’t want to work with you because they assume men aren’t as good at CS. The other half jockey to work with you, some for the novelty (“Hey, I’m in a group with the guy, ”) and half because they want to ask you out. When you go to apply for an internship, a lot of companies seem really interested in you, but you’re not sure if it’s because they like your resume or just because you’re a guy in CS and they want to look open and forward thinking by having lots of male interns coding. You meet up with a group of female interns and one makes a slightly sexual joke. Everyone freezes and looks at you - are you one of those guys in CS that is serious and can’t take a joke, or will you be one of the girls? At your job after you graduate, it’s naturally not ok for a woman to say outright that she’s prejudiced against male coders… But maybe your boss gives you slightly different work, or it takes longer for you to get a promotion because they need more proof that you are good - you don’t get the benefit of the doubt the way the girls do. When you express a strong opinion about a tough problem, the women write it off as you being sensitive and emotional - men often are, you know. When discussing your career ambitions, your coworkers often ask you how children play into that - I mean, you’re probably looking for a wife and plan to have kids since you’re in your late 20s. Everyone knows it’s a safe bet that kids are going to derail your career at least temporarily, if not permanently. You frequently police how often you mention family at all for fear people will assume you’re expecting a kid soon… … Does this begin to explain it, at all? Even when a company is open to women working in all areas and no one is a dick, there is still a lot of pervasive bias that affects how women are treated and perceived. Why would you notice? It doesn’t affect you.
Electrostaticrain (Reddit)
Programmers nowadays have to...
... write 100%-covering unit tests;
... set up continuous integration, linters, hinters, style checkers, ...;
... follow style guides for every language;
... meet impossible deadlines;
... meet impossible management/customer/end user expectations;
... read through terrible code others made;
... read through terrible documentation others made;
... make terrible documentation themselves;
... fight with the IDE;
... fight with the build tools;
... deal with unreproducible crash reports coming in from everywhere;
... debug code written at 2am (by themselves AND others);
...
...
...
... KNOW HOW TO PROGRAM.
Seriously: First “what”, then “why”
TL;DR: Before you try to fix the error, know for certain where it comes from.
Now, this seems obvious, right? And it is. Yet, I didn’t follow this principle a few days ago, and I beg you not to make the same mistake.
A little backstory. I deployed a rather huge web app I’m writing on a brand-new server. After I had set up the database, I gave it a quick test-run and Node.JS’s generic ECONNREFUSED error popped up. Now, due to the fact that I had just worked on the database, my brain made a connection where there shouldn’t be one.
I proceeded to work on “fixing” the database for the following 7 hours, ripping every last nerve of mine out in the process, without any result. Could connect via CLI, via telnet (even remotely!), via the web interface, only my code kept endlessly throwing the same error.
Then it dawned on me. I added another string to the statement that prints database errors – and it didn’t appear, the message stayed unchanged. How could this be possible?
Well, I hadn’t yet installed the mail servers, and that was where the error actually came from, since Node couldn’t connect to those (which makes total sense, right?). But, never had I spent a single thought on just trying out whether the database worked; never had I spent a thought on the fact that the message was so generic and could come from literally anywhere.
Seven hours lost fixing a bug that did not exist in the first place. Never will I make the same mistake again, I had learned my lesson. Hopefully you can do so, too.
Never interrupt a programmer.
What's the coolest thing you've coded for?
There were many things that I found to be “super cool” when they happened. Yet, it doesn’t feel like I’m at the point already where I can look back and say that something absolutely killed it.
Up until a few months ago, I worked mostly on rather small projects, although lots of them. I am just now starting to focus more on big ones, so maybe in a few years I could give you a proper response.
Developing
Making software, nowadays, is just 20% code – the remaining 80% is fighting with the countless tools over the way you want it to crash.