3 ms·

That's the web developer equivalent of being able to use a hammer as a carpenter, though. That's a bit of an exaggeration but only a bit. Would you hire a carpe

That's the web developer equivalent of being able to use a hammer as a carpenter, though. That's a bit of an exaggeration but only a bit. Would you hire a carpenter if he couldn't use a hammer effectively? Sure, you could spend a few hours teaching him and probably get him to be good enough to be useful. But would you really rather hire him over someone who knows how to use a hammer if that's the only differentiating factor between the two people?

judofyr 8y ago
If you already know that the hammer is the best way to solve it, why wouldn't you ask them to solve it with a hammer? Using the right tool is tricky and there are cases where console.log is more efficient than a debugger: - It's a debugger you're not used to - The stack/application is complicated and works weirdly with the debugger (e.g. exceptions are captured and stack traces are lost) - Many things are happening at the same time so it's quicker to scan through 100 lines of output than stepping through 100 breakpoints. I know how to use a debugger, but I also know how to console.log in such a way that I can quickly scan the output, or output a DOT file so I can visualise the flow and data as a graph.
- wild_preference 8y ago
  None of those apply to their fizzbuzz-level question. I’m guessing you don’t have much experience with front-end code if you think this is Chrome tooling specific. It’s really the equivalent of reading a stack trace to get an idea of where to look instead of wolf-fencing off the bat with println. “I would’ve read the stack trace if I knew you wanted me to!” wouldn’t be a good defense, likewise. Yes, you can teach someone to read stack traces on the job. If-statements, too. And how to write their first function. But that’s not the skill level you’re always looking for.
  - judofyr 8y ago
    > I’m guessing you don’t have much experience with front-end code Okay. You're guessing wrong. I'm just asking for a bit honesty here. If they start adding console.log everywhere, how about you ask them why they're doing it that way? In a codebase I know nothing about it's not uncommon for me to add some console.log around to see how the code flows. Adding breakpoints isn't efficient when it's being hit 100 of times; reading console.log output can be done quite quickly. Maybe I'm misunderstanding the original test, but I'm just tired of playing these games where a person asks me a question and they're holding off important information that they will use to judge me.
    - 0xfeba 8y ago
      I don't hold off important info. I mean, I won't give the answer but I encourage dialog. And your console.log example is valid, but this isn't the same situation. It's a button press, the fetch call is made. I tell them what it should do, I say I would use the debugger but ask them what they would do.
- bryanrasmussen 8y ago
  I prefer console logs to the debugger for the following reason - I tend to know about where the problem is. I've been working on this code, I know it's a couple things that could be breaking it in the way it's breaking. I prefer to console.log those things because I find stepping through code tedious, though I understand some people would prefer to use the debugger. If on the other hand it is code I don't know anything about I guess I would probably say well I guess I should set a breakpoint. That said, because I find stepping through code tedious I will often use console log statements when I should use the debugger because I am apt to think oh I will know the answer with just another try. Thus I can end up wasting my time by using too many console log statements. Finally this situation is also affected by the problem of specialized debugging tools for particular frameworks. I hate learning tools. I have to click on things etc. I like learning languages. If there was a debugging environment that was a specialized console with a particular api to interact with the code I would learn it. I don't mean a debugger statement before anyone suggests it.
  - jasonkostempski 8y ago
    You can make a conditional break point, put in arbitray js statements, such as console.log, and return false if you dont want to pause there. Best of both worlds and you dont have to clean up the code after.
    - lhnz 8y ago
      I can type `console.log(blah)` into a text file and hit save much faster than I can search for the same file within Chrome right-click and then come up with a working conditional breakpoint dependent on the context around it and type this into a tiny input field. If you understand the code and are currently writing it, it's almost always faster to debug with a `console.log`[0]. This seem to be the case whether you are coding in a browser or running unit tests: reaching for the debugger is slowwww. To me, the debugging experience everywhere seems broken. Why is the only tool we have a breakpoint? What if I don't want to 'block' and just want to mark a point in the code which I want to capture a selection of information about? Why not let me visualise or filter these points, and then click through to see the callstacks and the state that was collected? The whole DX seems to be built around the premise that I want to laboriously step through when I debug. While in 99% of cases as soon as I see some values I instantly know what I have done wrong. The only times I normally use a debugger are when debugging problems on production sites, or when debugging complex problems in other people's code. [0] This might not be the case, if your IDE is extremely well-integrated with your text editor to the extent that you can add breakpoints as easily as you can add log statements. Edit: I just checked and the latest version of VSCode has LogPoints. Perhaps that means others see room for improvement, too.

judofyr 8y ago

If you already know that the hammer is the best way to solve it, why wouldn't you ask them to solve it with a hammer? Using the right tool is tricky and there are cases where console.log is more efficient than a debugger: - It's a debugger you're not used to - The stack/application is complicated and works weirdly with the debugger (e.g. exceptions are captured and stack traces are lost) - Many things are happening at the same time so it's quicker to scan through 100 lines of output than stepping through 100 breakpoints. I know how to use a debugger, but I also know how to console.log in such a way that I can quickly scan the output, or output a DOT file so I can visualise the flow and data as a graph.

wild_preference 8y ago
None of those apply to their fizzbuzz-level question. I’m guessing you don’t have much experience with front-end code if you think this is Chrome tooling specific. It’s really the equivalent of reading a stack trace to get an idea of where to look instead of wolf-fencing off the bat with println. “I would’ve read the stack trace if I knew you wanted me to!” wouldn’t be a good defense, likewise. Yes, you can teach someone to read stack traces on the job. If-statements, too. And how to write their first function. But that’s not the skill level you’re always looking for.
- judofyr 8y ago
  > I’m guessing you don’t have much experience with front-end code Okay. You're guessing wrong. I'm just asking for a bit honesty here. If they start adding console.log everywhere, how about you ask them why they're doing it that way? In a codebase I know nothing about it's not uncommon for me to add some console.log around to see how the code flows. Adding breakpoints isn't efficient when it's being hit 100 of times; reading console.log output can be done quite quickly. Maybe I'm misunderstanding the original test, but I'm just tired of playing these games where a person asks me a question and they're holding off important information that they will use to judge me.
  - 0xfeba 8y ago
    I don't hold off important info. I mean, I won't give the answer but I encourage dialog. And your console.log example is valid, but this isn't the same situation. It's a button press, the fetch call is made. I tell them what it should do, I say I would use the debugger but ask them what they would do.
bryanrasmussen 8y ago
I prefer console logs to the debugger for the following reason - I tend to know about where the problem is. I've been working on this code, I know it's a couple things that could be breaking it in the way it's breaking. I prefer to console.log those things because I find stepping through code tedious, though I understand some people would prefer to use the debugger. If on the other hand it is code I don't know anything about I guess I would probably say well I guess I should set a breakpoint. That said, because I find stepping through code tedious I will often use console log statements when I should use the debugger because I am apt to think oh I will know the answer with just another try. Thus I can end up wasting my time by using too many console log statements. Finally this situation is also affected by the problem of specialized debugging tools for particular frameworks. I hate learning tools. I have to click on things etc. I like learning languages. If there was a debugging environment that was a specialized console with a particular api to interact with the code I would learn it. I don't mean a debugger statement before anyone suggests it.
- jasonkostempski 8y ago
  You can make a conditional break point, put in arbitray js statements, such as console.log, and return false if you dont want to pause there. Best of both worlds and you dont have to clean up the code after.
  - lhnz 8y ago
    I can type `console.log(blah)` into a text file and hit save much faster than I can search for the same file within Chrome right-click and then come up with a working conditional breakpoint dependent on the context around it and type this into a tiny input field. If you understand the code and are currently writing it, it's almost always faster to debug with a `console.log`[0]. This seem to be the case whether you are coding in a browser or running unit tests: reaching for the debugger is slowwww. To me, the debugging experience everywhere seems broken. Why is the only tool we have a breakpoint? What if I don't want to 'block' and just want to mark a point in the code which I want to capture a selection of information about? Why not let me visualise or filter these points, and then click through to see the callstacks and the state that was collected? The whole DX seems to be built around the premise that I want to laboriously step through when I debug. While in 99% of cases as soon as I see some values I instantly know what I have done wrong. The only times I normally use a debugger are when debugging problems on production sites, or when debugging complex problems in other people's code. [0] This might not be the case, if your IDE is extremely well-integrated with your text editor to the extent that you can add breakpoints as easily as you can add log statements. Edit: I just checked and the latest version of VSCode has LogPoints. Perhaps that means others see room for improvement, too.