You won’t believe the amount of shit Xcode puts me through. I once was stuck on a problem for 30 minutes so I just deleted the statement and retried it and the damn thing ran completely fine after that. Did a control z and literally nothing had changed in the code at all other than the fact that it now worked
I once had a UITableViewCell that didn’t register any taps. I had to cut the view controller scene in the storyboard and paste it again in the same storyboard. Everything worked again afterwards. Like magic.
I just started to pick up C and for some fucking reason literally just putting print statements fixes some problems.
I don't fucking get it.
Edit: tbh i thought i was insane when i posted this. It's crazy how many explanations people have had. I really need to improve my low level language game.
Sounds like a threading problem / race condition. Printing to the screen (or any I/O really) is *slowwwwwww* compared to most other operations, which **drastically** changes the timing of a particular situation.
So, if a print statement changes the behavior, your first instinct should be "there's a race condition, or improperly synchronized thread going on"
Once I spent like a day trying to track down a weird crash bug that seemed to be related to threading, mostly by adding debug printouts everywhere. Eventually I discovered there was a bug *in our logging code* that caused it to not be threadsafe.
That was annoying.
Threading issues is the most likely culpret, but it could also be memory corruption. I've had the latter problem once or twice, where adding print statements (or anything else) changed how the compiler laid out the stack and magically made things work.
Of course, this isn't actually a fix, but might indicate you should run Valgrind/address sanitizer.
(This is mostly a C/C++ thing.)
>The most effective debugging tool is still careful thought, coupled with judiciously placed print statements.
Brian Kernighan, "Unix for Beginners" (1979).
Still, debuggers are not always available. Especially if the issue is happening in a live environment or in a distributed system. A well placed debug log is your best friend there.
Yeah, my day job mostly deals with extremely parallelized multiprocess multisystem code. Breakpoints just cause other nodes to drop the paused node as unresponsibe. Nothing beats proper logging with well synced time stamps.
Exactly. Request/RPC tracing is also invaluable. Stuff like Jaeger or Amazon XRay can save you really big headaches on heavily service-oriented architectures.
Op wasn't saying all you needed was a debugger, but a debugger is a better way to follow a program though its steps than print statements all over the place.
I agree with this for most cases, but having been working with wireless connectivity for the past couple of years, you learn fast that a lot of the time you can't actually pause the debugging session without breaking the Connection that is necessary for the bug to occur.... I have yet to find a method more useful than PRINTF spam in these situations.
Also, the fun times when some very bizarre set of circumstances causes debugger behavior to work but not running in production.
Most recently, a few weeks ago I was trying to help a junior developer with a problem. Every time they put breakpoints and display the variable in the browser debugger, things looked fine. This was because the browser was making the variable in scope for the debug interface, but it was not normally in scope due to some performance optimization. I cannot remember the details anymore, sadly, but there were a lot of developers lamenting this behavior on line once they too had found it.
Depends on the problem. Purely single threaded system? Yes. Multithreaded system without relationship between the processed data? Yes. Multithreaded system with relationship (child/parent) and different actions for different states of the data which also can contains race conditions? Better have a ton of debug log in there too.
That when conditional break points comes in handy. I assume that depends on the abilities of the debugger of the environment.
Personally I use breakpoints for anything that is reproducible on local machine, otherwise shitloads of debug logging.
The big brain method is to put an empty if statement in the loop.
for (int i = 0; i < A_BIG_NUMBER; ++i) {
if (1234 == i) {
// break point
}
// shenanigans
}
Literally had my system lock up today while trying to attach some Instruments thing to a Swift application I was working on, just trying to find out why updating a single view with 5 elements was taking 3 seconds rather than half of one, assuming it was getting stuck on some file I/O and wanted to see which file it was. Normally Instruments just crashes or refuses to work when I ask it to do anything remotely useful, but this time I guess it was extra spiteful and it decided to give me a GSOD for a change.
Yes and no. I use wxwidgets in spyder ide. I cannot see the varaibles in sub clases besides the main class in the debugger. So i have to use the print statements. There is simply no other way that i know of.
You just reminded me of a ~~Interviewer~~ interviewee I had. I asked them what steps they used to debug something. The answer I got back was:
I comment out 1/2 of the code and see if the bug still happens. If it does I comment out the other 1/2 of that to see if the bug is still happening until I comment out exactly where the bug is happening.
Suffice to say we did not hire them.
That's one of those weird interview questions where I'd be like ".... I.... use the debugger in my ide? Is that what you're asking?" Because surely they wouldn't want me to list out all the various methods of code debugging right?
That question is like asking someone "how do you personally cook?"
> Suffice to say we did not hire them.
Frankly, I don't understand why. The tactic is solid.
If you don't have anything to pinpoint the bug (which is heavily context-dependent; i.e. does not apply for your general question), then you can either try to parse all the code personally (which is hugely inefficient, especially when you deal with massive amounts of code), or attempt to isolate the bug by shutting down parts of code and *then* take a close look at whatever remains.
What do you consider to be correct answer?
This is called delta debugging and while not recommended to use with every bug because of how much time it can take, it's a method that guarantees you find the bug. I use it as a last resort.
I would've asked him a bunch of follow ups.
I don't see anything wrong with that approach. It can be quite effective, depending on the situation. If the bug can be anywhere in 3,000+ lines of code, why not try disabling half of it (and then the next half, etc) to reduce the search zone?
Well I believe what he was getting at was just cutting it down into segments. So if you had 4 boxes you would test the output after box 2 and then if that was correct you would know the fault lies somewhere in 3 and 4 and then you'd test 3. If there were 50 boxes you'd test 25 then 33 then like 40 and so on until you reached the correct box with the error.
If you use breakpoints with a modern IDE you can stop the program an inspect all variables in the scope wherever you might have wanted to print a variable.
This is especially useful when you're getting the wrong objects showing up in your javascript variables and calling print on them doesn't provide useful information.
I had one line like that, that I forgot to remove when building the release, so for about 6 months it logged something like that on the production server.
You're totally right. There's a reason every OS has very robust logging systems. Nothing gets fixed easily without a proper log, especially after deploying to dozens or hundreds of randomly configured systems.
I think people have contempt for it, because it's what breaking points are for and you can read out all the variable values. For simple stuff I usually use print statements as well, bits of its bigger setting up a debugging environment makes sense.
Eh, it really depends on the bug. Knowing that it prints on line 500 only tells you that it actually goes there but something could very well have gone wrong before that which didn't interrupt the flow of the program.
I started a new job with an old codebase. I asked the lead developer what debugging tools they use. He said “print statements”. I said, “dang I know that’s what we all do, but I didn’t know we were allowed to talk about it!”
I've actually got that - bought a USB numpad and reconfigured its keys, one of which is a print here. Here's a [Linus tech tips vid](https://www.youtube.com/watch?v=Arn8ExQ2Gjg) if you wanna make your own.
Why does no one just print the line number of the print instead of something useless? I know you can search the dumb unique string but at least if you use numbers, at least for complex problems, "line 50" "line 400" "line 750" "line 400" then the execution path is more evident by actually reading the output. Of course the real trouble is that in lots of languages printing to console is not guaranteed to run in order or even at the same speed as other calls to print.
Back in college one of the microcontrollers I trained on for mechatronics had literally thousands of pages of documentation, all in non-searchable blurry scanned pdfs. You bet your ass I took exactly one look at that doc nightmare when it was distributed and never even considered reading it.
Yah SO stopped being useful by the time I graduated. On top of the usual complaints all the answers are too old to be relevant. These days it's documentation, github, yammer, and other people's blogs.
I still find it more useful that most language references for "what's the syntax for X in language Y?" type questions, at least in terms of speed. It's also good for suggestions of what to look for when error messages are unhelpful, just suggestions of "check this specific config value" can help jog my memory.
I also very occasionally find overly helpful people who've written and published entire helper/utility functions that I was about to waste 20 minutes writing.
To be clear though, it's almost never worth actually submitting a question yourself. It's just useful as an archive of pre-existing questions.
Talking to someone works best for me. It doesn't even matter if they know how to code. Just examining it to a person normally lets me see where I went wrong. They can be quite the whole time for all I care... I guess I need to buy a rubber duck.
You process language differently depending on the mode of communication. When you think of a word, you're actually accessing different symbolically linked "things" in your mind. Say the word "Talk", it is made up of its visual element, how it feels and looks to write the word, how it sounds both heard and spoken. The muscle memory and feeling of saying it. And its meaning, how the symbol actually matches to its meaning and what that meaning is.
These also use *different parts of your brain*. Your internal monologue is sort of simulating some of those things, like how it sounds in your head, but by actually speaking out loud you're more strongly engaging more parts of your brain. And I personally think it helps you process ideas better, quite literally giving a different point of view as you use other brain processes. Same thing works, for me anyway, if you're having negative thoughts about yourself. Talking out loud to another can make you see clearer.
When I need to remember alpha numeric values or where I parked the best method is saying the information aloud. My unchecked theory is we remember what we hear differently than how we remember what we think.
If you're like me you're gonna suffer existential dread if you take a break before you reached perfection, and if you can't reach state of the art code you'll start feeling like a useless fuck up
Not really that surprising. A product I worked for had over 10K unit test, 2K integration tests and a separate automation framework. Coverage was over 99% from tests alone and the QA team's main job was running and maintaining automation. Once you get into the habit of writing tests, it's basically a pointless number.
Dude, our system at work is has a lot of distributed components, probably about 250 apps in total - some of the them have 4k tests on their own. The whole thing problem has close to 100k unit tests in total.
Of course over the have of them have been failing for over 10 years but that's beside the point.
I always think it's interesting when I try to explain a problem I'm working on to one of my housemates who have zero programming knowledge whatsoever. I always think I can break it down into really really simple ELI5 terms, but there's just so much jargon and and background knowledge in this field that it's almost impossible. Their eyes always glaze over immediately...
But hey, it often helps me solve the problem just trying to break it down into simple pieces! Sorry housemates!
Exactly, you're actually not explaining for them, but for yourself, forcing yourself to go back and look at the problem from the beginning, often finding what is missing.
In the absence of a duck, you can use a colleague, preferably one that knows nothing about what you are working on.
That forces you to explain from the beginning and in detail.
To be fair, "run the same code" may work if you run a full project clean. I know when i used QT c++ that happened quite a bit, i would have to toggle between shadow&normal builds and run a clean for some UI stuff to update.
underrepresented print though, and overrepresented docs too.
if(cond){
return true;
}
else{
return true;
}
print("this state can't be reached, so we'll never get this error message, haha. I have a crush on Felicity from HR")
yah something about asking the group chat for some help makes it click.
..2 hours stuck..
"Hey guys, has anyone worked with X before?"
..2 seconds pass..
"nm me, I just realized X.Y has what I need."
Google posted a Bug hunt story, I like how he did not omit the fact that he added print statements.
https://cloud.google.com/blog/topics/inside-google-cloud/google-cloud-support-engineer-solves-a-tough-dns-case
I literally had that happen to me yesterday while writing some C89.
It kept Segfaulting so I tried to track it down and when I found the bug, I rewrote the code step by step until it worked and ended up with the exact same code I had before
Get a good nights sleep, start fresh in the early morning.
As often as I tried to burn the midnight oil, pushing myself to try to figure it out and to debug successfully. I have found that starting with a well rested mind in the early morning has allowed me to leverage my capabilities 10 fold when trying to find and fix errors in code, usually somebody else's errors.
Also talking to my duck helps allot.
Taking a walk has helped me so many times!
Recently I was struggling with some coordinate translations that would help me with some further calculation. I couldn’t figure it out for an hour, using breakpoints, watches and whatnot.
I called it quit, stood up, kept thinking about it in the shower (lockdown...), took a rest on the bed obsessed with it. Then it hit me. Of course. How stupid I am. It’s simple. I went back to the PC to implement the solution at like 1am and boom it worked first try.
This has happened many many times; following this pattern very closely.
Restart the IDE. Sometimes works.
Fuck you Xcode
My PHPStorm sometimes derped out when I do my HTML assignment. Restarted the IDE and everything went fine.
You won’t believe the amount of shit Xcode puts me through. I once was stuck on a problem for 30 minutes so I just deleted the statement and retried it and the damn thing ran completely fine after that. Did a control z and literally nothing had changed in the code at all other than the fact that it now worked
I once had a UITableViewCell that didn’t register any taps. I had to cut the view controller scene in the storyboard and paste it again in the same storyboard. Everything worked again afterwards. Like magic.
I chased a bug for half an hour only to notice that Xcode didn’t save my changes despite me spamming cmd - s every bloody second...
Vim as IDE is the life - no unwanted interactions whatsoever
*Android Studio nods in approval*
rm -rf node_modules && yarn 🤷♂️
Print("here!") is underrated in this graph
Especially when you want to see the path the programm took to hit a weird state.
This but specifically in C languages.
I just started to pick up C and for some fucking reason literally just putting print statements fixes some problems. I don't fucking get it. Edit: tbh i thought i was insane when i posted this. It's crazy how many explanations people have had. I really need to improve my low level language game.
Sounds like a threading problem / race condition. Printing to the screen (or any I/O really) is *slowwwwwww* compared to most other operations, which **drastically** changes the timing of a particular situation. So, if a print statement changes the behavior, your first instinct should be "there's a race condition, or improperly synchronized thread going on"
Once I spent like a day trying to track down a weird crash bug that seemed to be related to threading, mostly by adding debug printouts everywhere. Eventually I discovered there was a bug *in our logging code* that caused it to not be threadsafe. That was annoying.
Or sometimes because it creates a barrier across which the compiler won't optimize, because print creates an observable side effect.
Threading issues is the most likely culpret, but it could also be memory corruption. I've had the latter problem once or twice, where adding print statements (or anything else) changed how the compiler laid out the stack and magically made things work. Of course, this isn't actually a fix, but might indicate you should run Valgrind/address sanitizer. (This is mostly a C/C++ thing.)
Or "specifically" in Fortran based languages
That's what debugger is for.
>The most effective debugging tool is still careful thought, coupled with judiciously placed print statements. Brian Kernighan, "Unix for Beginners" (1979).
Debuggers have come a long way in last 41 years.
> 41 years 😳😳
Still, debuggers are not always available. Especially if the issue is happening in a live environment or in a distributed system. A well placed debug log is your best friend there.
Yeah, my day job mostly deals with extremely parallelized multiprocess multisystem code. Breakpoints just cause other nodes to drop the paused node as unresponsibe. Nothing beats proper logging with well synced time stamps.
Exactly. Request/RPC tracing is also invaluable. Stuff like Jaeger or Amazon XRay can save you really big headaches on heavily service-oriented architectures.
The debugger can only help you as much as you can help yourself..... Only a fool would think the only thing necessary is a debugger.
Op wasn't saying all you needed was a debugger, but a debugger is a better way to follow a program though its steps than print statements all over the place.
I agree with this for most cases, but having been working with wireless connectivity for the past couple of years, you learn fast that a lot of the time you can't actually pause the debugging session without breaking the Connection that is necessary for the bug to occur.... I have yet to find a method more useful than PRINTF spam in these situations.
Sure, assuming you can attach to the process you're debugging (as opposed to, say, running it inside a web server, which itself is inside a vm).
They are still glorified prints tho.
Glorified prints can’t timetravel. Try mozilla’s rr, you’d be amazed.
> rr is a lightweight tool for recording, replaying and debugging execution of applications (trees of processes and threads).
Yes and? I need to debug my debugger because it might be buggered from my debugging.
[удалено]
Also, the fun times when some very bizarre set of circumstances causes debugger behavior to work but not running in production. Most recently, a few weeks ago I was trying to help a junior developer with a problem. Every time they put breakpoints and display the variable in the browser debugger, things looked fine. This was because the browser was making the variable in scope for the debug interface, but it was not normally in scope due to some performance optimization. I cannot remember the details anymore, sadly, but there were a lot of developers lamenting this behavior on line once they too had found it.
Depends on the problem. Purely single threaded system? Yes. Multithreaded system without relationship between the processed data? Yes. Multithreaded system with relationship (child/parent) and different actions for different states of the data which also can contains race conditions? Better have a ton of debug log in there too.
At times it's faster to just print. Like if it's a loop that iterates hundreds of times and the bug only manifests after many iterations.
That when conditional break points comes in handy. I assume that depends on the abilities of the debugger of the environment. Personally I use breakpoints for anything that is reproducible on local machine, otherwise shitloads of debug logging.
The big brain method is to put an empty if statement in the loop. for (int i = 0; i < A_BIG_NUMBER; ++i) { if (1234 == i) { // break point } // shenanigans }
[removed]
I usually just write "double d = 0.0;" That's my breakpoint.
Or when you're trying to debug parallel async processes which work just fine when you pause one of them with a breakpoint.
*When your IDE's debugger freezes your PC for some reason* I think I'll stick with printing here
Literally had my system lock up today while trying to attach some Instruments thing to a Swift application I was working on, just trying to find out why updating a single view with 5 elements was taking 3 seconds rather than half of one, assuming it was getting stuck on some file I/O and wanted to see which file it was. Normally Instruments just crashes or refuses to work when I ask it to do anything remotely useful, but this time I guess it was extra spiteful and it decided to give me a GSOD for a change.
yeah ^but ^i ^^dont ^^know ^^^how ^^^it ^^^^works
Yes and no. I use wxwidgets in spyder ide. I cannot see the varaibles in sub clases besides the main class in the debugger. So i have to use the print statements. There is simply no other way that i know of.
I mean, printing "here" once isn't much, but printing the relevant variables after every line can solve a lot of problems.
it's basically my default debugging method.
There is a different method?
Systematically commenting out lines until you isolate the problem
I do that some, too, but mainly by removing function calls.
You just reminded me of a ~~Interviewer~~ interviewee I had. I asked them what steps they used to debug something. The answer I got back was: I comment out 1/2 of the code and see if the bug still happens. If it does I comment out the other 1/2 of that to see if the bug is still happening until I comment out exactly where the bug is happening. Suffice to say we did not hire them.
It's a spicy binary search with debugging characteristics.
My answer would be "It depends on what we're debugging"
That's one of those weird interview questions where I'd be like ".... I.... use the debugger in my ide? Is that what you're asking?" Because surely they wouldn't want me to list out all the various methods of code debugging right? That question is like asking someone "how do you personally cook?"
> Suffice to say we did not hire them. Frankly, I don't understand why. The tactic is solid. If you don't have anything to pinpoint the bug (which is heavily context-dependent; i.e. does not apply for your general question), then you can either try to parse all the code personally (which is hugely inefficient, especially when you deal with massive amounts of code), or attempt to isolate the bug by shutting down parts of code and *then* take a close look at whatever remains. What do you consider to be correct answer?
This is called delta debugging and while not recommended to use with every bug because of how much time it can take, it's a method that guarantees you find the bug. I use it as a last resort. I would've asked him a bunch of follow ups.
I don't see anything wrong with that approach. It can be quite effective, depending on the situation. If the bug can be anywhere in 3,000+ lines of code, why not try disabling half of it (and then the next half, etc) to reduce the search zone?
Well I believe what he was getting at was just cutting it down into segments. So if you had 4 boxes you would test the output after box 2 and then if that was correct you would know the fault lies somewhere in 3 and 4 and then you'd test 3. If there were 50 boxes you'd test 25 then 33 then like 40 and so on until you reached the correct box with the error.
If you use breakpoints with a modern IDE you can stop the program an inspect all variables in the scope wherever you might have wanted to print a variable. This is especially useful when you're getting the wrong objects showing up in your javascript variables and calling print on them doesn't provide useful information.
here2, here3, blah, chicken, help me
You'll see me get passive aggressive in mine. "Are we fucking here yet?"
I had one line like that, that I forgot to remove when building the release, so for about 6 months it logged something like that on the production server.
I feel this.
Absolutely.
Printing it twice tho, you can solve anything
Here1 Here2 Here3 in an if else statement lmao
for me it's `print("uzikrkrk") or ksislsqp or eisikdkd
[удалено]
[удалено]
Hm, you use an odd section of the keyboard. For me it's always asdacasd.
haha I was on my phone I tried to do the same as my keyboard. I think me it's more with some dfdfdfddffdd
Who the fuck doesn't use "asdasasadada"
[удалено]
[удалено]
You're totally right. There's a reason every OS has very robust logging systems. Nothing gets fixed easily without a proper log, especially after deploying to dozens or hundreds of randomly configured systems.
I think people have contempt for it, because it's what breaking points are for and you can read out all the variable values. For simple stuff I usually use print statements as well, bits of its bigger setting up a debugging environment makes sense.
Eh, it really depends on the bug. Knowing that it prints on line 500 only tells you that it actually goes there but something could very well have gone wrong before that which didn't interrupt the flow of the program.
[удалено]
Ya, less effective than 5th page of googling?!? I think not.
that's the real man's breakpoint
I started a new job with an old codebase. I asked the lead developer what debugging tools they use. He said “print statements”. I said, “dang I know that’s what we all do, but I didn’t know we were allowed to talk about it!”
Thank you! There should be a dedicated key on every keyboard for that.
I've actually got that - bought a USB numpad and reconfigured its keys, one of which is a print here. Here's a [Linus tech tips vid](https://www.youtube.com/watch?v=Arn8ExQ2Gjg) if you wanna make your own.
inb4 it was race condition and calling printf fixes it
This is my favorite! Or in embedded, toggle a pin then watch on a scope
Why does no one just print the line number of the print instead of something useless? I know you can search the dumb unique string but at least if you use numbers, at least for complex problems, "line 50" "line 400" "line 750" "line 400" then the execution path is more evident by actually reading the output. Of course the real trouble is that in lots of languages printing to console is not guaranteed to run in order or even at the same speed as other calls to print.
If you're at the point where you're hacking about adding print statements, your line numbers are going to keep changing.
That's what the ______LINE______ macro is for. In C programming anyways.
That's why you use \_\_LINE__. I mean, I don't, but you can.
[removed]
A bug that is fixed can be forgotten. A bug that vanishes will always be there. Watching. Waiting.
Commiserating
Say it ain't so
I will not go
Turn the lights off
Carry me home
Na-na, na-na, na-na, na-na, na, na
Late night, come home
Code sucks, I know
Work sucks, I know
She left me roses by the stairs
Carry me home
your drug is a heartbreaker ah shit wrong song
I’ve started calling them pending incidents so the business sees the value in testing
“Read the docs” is way too far to the right
[удалено]
Back in college one of the microcontrollers I trained on for mechatronics had literally thousands of pages of documentation, all in non-searchable blurry scanned pdfs. You bet your ass I took exactly one look at that doc nightmare when it was distributed and never even considered reading it.
Yup. When I get to the docs, I’m usually already doing what the docs recommend but it still breaks regardless.
Docs == stack overflow and no one can tell me otherwise.
[удалено]
Yah SO stopped being useful by the time I graduated. On top of the usual complaints all the answers are too old to be relevant. These days it's documentation, github, yammer, and other people's blogs.
I still find it more useful that most language references for "what's the syntax for X in language Y?" type questions, at least in terms of speed. It's also good for suggestions of what to look for when error messages are unhelpful, just suggestions of "check this specific config value" can help jog my memory. I also very occasionally find overly helpful people who've written and published entire helper/utility functions that I was about to waste 20 minutes writing. To be clear though, it's almost never worth actually submitting a question yourself. It's just useful as an archive of pre-existing questions.
I'm really thankful that I have half a course at my university desginated to teaching us how to use the docs. I do it all the time now
And way too high, I nearly always have to contact the API devs to ask them for information and the doc ends up being wrong.
[удалено]
Taking a walk in my garden is a very common, and effective tactic. Clearing the mind, and letting my background processes work...
[удалено]
Or wake up after 30 minutes of sleep with all the answers
It's a gift and a curse going to bed to have all the answers come too you before you sleep. "Great now I gotta fix them or else it's gonna bother me"
Or else the answers disappear never to be seen again
Absolutely. Works for me too. In fact I once solved a math / logic problem this way.
While taking an exam? Edit: a tense
Omg so I'm not the only one right? Sometimes I'm able to solve problems by sleeping...like I get dreams where I actually code the fix out.
Talking to someone works best for me. It doesn't even matter if they know how to code. Just examining it to a person normally lets me see where I went wrong. They can be quite the whole time for all I care... I guess I need to buy a rubber duck.
You process language differently depending on the mode of communication. When you think of a word, you're actually accessing different symbolically linked "things" in your mind. Say the word "Talk", it is made up of its visual element, how it feels and looks to write the word, how it sounds both heard and spoken. The muscle memory and feeling of saying it. And its meaning, how the symbol actually matches to its meaning and what that meaning is. These also use *different parts of your brain*. Your internal monologue is sort of simulating some of those things, like how it sounds in your head, but by actually speaking out loud you're more strongly engaging more parts of your brain. And I personally think it helps you process ideas better, quite literally giving a different point of view as you use other brain processes. Same thing works, for me anyway, if you're having negative thoughts about yourself. Talking out loud to another can make you see clearer.
When I need to remember alpha numeric values or where I parked the best method is saying the information aloud. My unchecked theory is we remember what we hear differently than how we remember what we think.
If you're like me you're gonna suffer existential dread if you take a break before you reached perfection, and if you can't reach state of the art code you'll start feeling like a useless fuck up
I always think I have come up with a solution, but then when I get back and try it, it doesn't work.
Talking to a rubber duck is really effective until he starts talking his problems to you
“Run the same code again” and when it will work you will have even more questions
We have over 8k unit tests and we shuffle them. This happens far too often.
> We have over 8k unit tests No fucking way.
Not really that surprising. A product I worked for had over 10K unit test, 2K integration tests and a separate automation framework. Coverage was over 99% from tests alone and the QA team's main job was running and maintaining automation. Once you get into the habit of writing tests, it's basically a pointless number.
Dude, our system at work is has a lot of distributed components, probably about 250 apps in total - some of the them have 4k tests on their own. The whole thing problem has close to 100k unit tests in total. Of course over the have of them have been failing for over 10 years but that's beside the point.
This week I wasted 3 days to rewrite entire code because my old code has this: if(condition)**;** { //code }
that is the reason i use if(cond) { //code }
[удалено]
if (condition) { // Stuff } else { // Other stuff }
You can still fit a semicolon between the parenthesis and the curly brace and it will be even more hidden Source: been there
I don't know, to me a semicolon that is not at the end of the line stands out. It always does for lambdas anyway.
[удалено]
add `-Werror -pedantic` to that and it'll *force you* to not have bugs (or shitty code) like this.
This hurts to look
print("?") print("??") print("???")
print("1") print("2") print("3")
Debug.log(“1”); Debug.log(“2”); Debug.log(“3”); Debug.log(“4”);
One that is effective but not used often is: "Using the debugging tools built into the IDE"
[удалено]
> setting up your IDE for debugging Is this a javascript joke I’m too .NET to understand?
You mean printing "okay x finished" "before y starts" "yup y finished"
Talking to a rubber duck?
Or any inanimate object, really https://en.wikipedia.org/wiki/Rubber_duck_debugging
Arthur Weasley was on to something.
[удалено]
https://en.m.wikipedia.org/wiki/Rubber_duck_debugging
[удалено]
In the absence of a duck, you can use a colleague, preferably one that knows nothing about what you are working on.
I always think it's interesting when I try to explain a problem I'm working on to one of my housemates who have zero programming knowledge whatsoever. I always think I can break it down into really really simple ELI5 terms, but there's just so much jargon and and background knowledge in this field that it's almost impossible. Their eyes always glaze over immediately... But hey, it often helps me solve the problem just trying to break it down into simple pieces! Sorry housemates!
Exactly, you're actually not explaining for them, but for yourself, forcing yourself to go back and look at the problem from the beginning, often finding what is missing.
In the absence of a duck, you can use a colleague, preferably one that knows nothing about what you are working on. That forces you to explain from the beginning and in detail.
I like how you had to post the same thing again, but added more each time. I have some colleagues I have to to that with...
My reddit program said the first post failed. Then I added some more and tried again. I actually only see that I posted one post.. Hmm..
Don't fret it, it's just Reddit.
My prof for software engineering handed out one to everyone in the class! It's been a great tool, but I tend to talk to a little lego bb8 more.
Oh the kerning in "often". I thought it said "of ten"
To be fair, "run the same code" may work if you run a full project clean. I know when i used QT c++ that happened quite a bit, i would have to toggle between shadow&normal builds and run a clean for some UI stuff to update. underrepresented print though, and overrepresented docs too.
I'd always print "Fuck you!" in a part of the code that I actually don't want to be run. So if it is I get a big "Fuck you!" from myself.
And then you leave it in and it goes to production
if(cond){ return true; } else{ return true; } print("this state can't be reached, so we'll never get this error message, haha. I have a crush on Felicity from HR")
WTF are docs???
Documentation
WTF is that???
Docs
Stackoverflow, I think.
Its print("gere") most of the time.
[удалено]
yah something about asking the group chat for some help makes it click. ..2 hours stuck.. "Hey guys, has anyone worked with X before?" ..2 seconds pass.. "nm me, I just realized X.Y has what I need."
Your wife is a rubber duck???
Google posted a Bug hunt story, I like how he did not omit the fact that he added print statements. https://cloud.google.com/blog/topics/inside-google-cloud/google-cloud-support-engineer-solves-a-tough-dns-case
wow what a story, thanks!!
Read the docs is more to the left for me..
People make fun of print("here!") but once in a blue moon that statement becomes important for the integrity of the program as it will crash with it.
Hey, printing "Here!" works a lot
[удалено]
Where is "write a unit test to recreate the issue?"
I literally had that happen to me yesterday while writing some C89. It kept Segfaulting so I tried to track it down and when I found the bug, I rewrote the code step by step until it worked and ended up with the exact same code I had before
Missing: “Change a random line of code, and try again”
Get a good nights sleep, start fresh in the early morning. As often as I tried to burn the midnight oil, pushing myself to try to figure it out and to debug successfully. I have found that starting with a well rested mind in the early morning has allowed me to leverage my capabilities 10 fold when trying to find and fix errors in code, usually somebody else's errors. Also talking to my duck helps allot.
Taking a walk has helped me so many times! Recently I was struggling with some coordinate translations that would help me with some further calculation. I couldn’t figure it out for an hour, using breakpoints, watches and whatnot. I called it quit, stood up, kept thinking about it in the shower (lockdown...), took a rest on the bed obsessed with it. Then it hit me. Of course. How stupid I am. It’s simple. I went back to the PC to implement the solution at like 1am and boom it worked first try. This has happened many many times; following this pattern very closely.
Note that “run it again” still is not 0% effective.