I thought that's what the second last one was gonna be

I believe in a conspiracy theory that nobody uses debuggers.

It’s easy, you just step, step, step, step in, or wait, over, or, oops.

Watch a Video or read something because it really is an invaluable tool. But here's a crash course:

Debuggers, or IDEs, let you step through your code in slo-mo so you can see what is happening.

1. Set a breakpoint - Click to the left of a line of code so a red dot appears. Run your program, and the IDE will execute to that line, then pause.
2. Look at variables' values - While the execution is paused you can hover over variables before that line to see their value.
3. Step through the code - See what happens next in slo-mo.
   • Use "Step Into" to enter into a function and see what that code does.
   • Use "Step Over" to not go into a function and continue in the current spot after the function has done its business.
   • Use "Step Out" to exit a function and pick up the execution after it has run. Use this when you're in too deep and the code stops making sense.
4. See whats in the heap - The heap will list all the functions that you're currently inside of. You can jump to any of those points by clicking them.
5. Set a watch - Keep a variable in the watch so you can see what its value is at all times.
6. Set a condition on the breakpoint - If the breakpoint is inside a big loop, you can right-click on the red dot to create a conditional breakpoint, so you write something like x===3 and it will only pause when x is 3.

There are many other things an IDE can do to help you, so def look into it more if you want to save yourself a lot of insanity. But this is a good starting point.

If you're developing for the web use F12 to open web tools, and when an error happens, click the file/line number to see that point in the Sources tab, and you can debug there.

That image goes so incredibly hard

Kung Fury will never not be amazing

What I want to know is who taught the original Indian YouTube tutor. Was he born with the knowledge?

I was going to say. That's a way more terrifying flex than everything else here.

Set Forms!frmFaceOfGod!OLECustomControl.Picture = LoadPicture("\\linux-nfs.local\nullshare\%*!!.bmp")

He's the only man I know, the only man I want to be.

My colleague literally once said to me "i can't read bleep bloops"

"Samir.... you're breaking the car!"

Please don't.

Thanks for unlocking my account everytime I forget my password!

Competitive programming.

Usually multiple algorithmic problems that are released to public at the same time and the fastest people to submit a correct solution get more points.

A fun one I still like to participate in is advent of code, which is a yearly christmas themed one with two problems released a day during advent.

If you want to seriously compete in competitive programming, you need to learn and memorize different problem types and the solutions to those. A bit like you start learning patterns in chess.

For practicing, the CSES Problem Set is a gold mine for practice problems. Theres also a list of competitive programming books on the site.

It's about coding competitions, and without me being directly involved in the scene (the closest I get to it are silly competitions regarding indy-games or decompiling old games or whatever) I did make personal acquaintance with every of those stereotypes, and it's so true.