8 ms·

I like this list. It's also missing "debugging". That's a skill that they don't emphasize in college because they can't test it and it's hard to teach. But ther

I like this list. It's also missing "debugging". That's a skill that they don't emphasize in college because they can't test it and it's hard to teach. But there are ways to teach it and techniques. There are some books on the subject: https://www.amazon.com/dp/1484290410/ https://www.amazon.com/dp/1484290410/ https://www.whyprogramsfail.com/ https://www.whyprogramsfail.com/ That can mitigate that a bit.

orderedtree 4y ago
Why can't debugging be tested?
- gregmac 4y ago
  I can think of a couple challenges. Let's say you're debugging "the website won't load." Often debugging is a hunch, and quickly branches. One person will go down the path of trying the same site from another PC. Another will try a different site from the same browser/PC. Another will try to ping the server. If you're running this live you're always going to have the chance where someone's hunch or first try basically pinpoints the problem and eliminates a dozen checks from their consideration. If you're looking for things like "did they check DNS? Did they try another site?" but they skipped that and immediately figured out apache wasn't running, do they lose points? Or do they get 100% for their lucky (and/or experienced) guess? If you do it on paper, the major problem is basically infinite branching for every step and possible result. How do you mark that? What's the minimum you need to do to get 100%? I think it's also unfair, because even as a seasoned vet I've been deep in troubleshooting to the point of (for example) greping source of nginx for a specific error message -- which I'd never have even thought of two steps earlier. I do t expect anything that complex on a school test of course, but the point is the result of each step is often the only way to even think of the next.
  - atoav 4y ago
    Sure testing a beginner is hard here. But testing someone who learned how to debug means testing their knowledge of the moving parts of the system they are debugging. And this can be explained by the person being tested. E.g. "I am going to ping an IP on the outside first, to see if ICMP message reaches the outside server. If yes I will check if the DNS server responds, if no we check the physical connection." That would be an ideal answer, judging less ideal answers fairly is certainly a challenge, but not impossible.
    - no1lives4ever 4y ago
      And what if the firewall blocks icmp? What if the dns server is internal to the network and is returning a stale ip? There are way too paths down this rabbit hole.
      - gregmac 4y ago
        This is exactly my point. It's even worse in a "school test" situation, because who knows what contrived scenario the instructor has invented depending on what their focus is (eg: DNS vs physical net vs routing vs apache config). Maybe there are multiple DNS servers for the zone that are returning different IPs, maybe one or both of them is even in split-zone configuration so it returns a different IP depending on if you're internal or external. Maybe the client has manual DNS configured or a hosts entry that's wrong. Each of these problems would have several more layers of troubleshooting steps and branching, and it's not even a complete list -- and this is only if the problem is DNS-centric! There's hundreds of other branches for each of the other problem categories.
      - atoav 4y ago
        I mean if it is a test you obviously test things that you tought them first, or not? Of course in reality there can be more, weirder things — especially if you are coming into an unknown network. But we are talking about an educational context here, would not make a lot of sense to let your students run into new unknown issues on a test unless your goal is not to educate.
    - sideshowb 4y ago
      More simply you could just ask to brainstorm 5 things the issue might be.
- clintonb 4y ago
  Debugging is difficult to test in a university/exam setting, but can be tested in an observational sense. Stripe does it in one of the on-site interviews.
  - no1lives4ever 4y ago
    I have been in enough debugging sessions to know that it is easy to weed out those who are bad from those who have the basics right. But trying to know if a candidate is good with advanced debugging is a futile exercise. You need to be in a few intense sessions with such people to know who are good/bad at these things. I have only been able to figure this about people after working with them for 6-12 months. Which is why it helps keep references to such people and have them on your teams in future ;-)
  - marginalia_nu 4y ago
    A compounding factor is that it's much harder to debug code you're not at least reasonably familiar with. Even if you can gain such intuition through looking at a piece of code, in a realistic scenario, more often than not you don't actually know in which file or method the bug is hiding. What you have is a code base and some externality that is wrong, the debugging process is essentially deepening your understanding of the relevant code (in relationship to what it should be doing) until you understand what is wrong. Debugging isn't being able to use a debugger or a profiler or syscall tracing tool or whatever, sure they help but the critical skill is being able to quickly and accurately model the behavior of a system in your head, in combination with a tacit understanding of where bugs tend to occur.
- invalidname 4y ago
  I can personally evaluate a specific persons skill. But doing this in a formal gradable test would be hard.
- josephg 4y ago
  It can. I love using debugging problems as an interview question. Give the candidate some simple code (~200-300 lines is probably about right) with a handful of failing unit tests. Sit them down, walk them through running the test suite and ask them to find and fix as many bugs as they can in 30 minutes. It pays to make the first bug trivial (like, a typo or something) and make the subsequent bugs increasingly subtle. You learn an awful lot about a candidate by watching their process. The hard thing with this sort of question is calibration. Candidates will be able to debug way less code than you think in 30 minutes. It helps to run the code past a few coworkers before giving it to candidates to figure out if its too hard a test. The surprising thing about this test is that it seems to be really highly correlated with senior engineers. Senior engineers often don't do as well as smart grads at coding problems because we often don't write that much code any more. But senior engineers seem to do waay better than juniors at debugging problems. If I could only get a candidate to do one programming problem, I'd get them to debug code. I think you get a massive amount of signal about whether you'd want to hire someone out of a debugging challenge.
  - gregmac 4y ago
    Debugging works extremely well during an interview because: 1. Your evaluation can be interactive: you're watching them step through, can stop and ask questions about their thought process, etc. If it's a theoretical problem (ie: not on a live computer) you can even re-calibrate on-the-fly if they're really quick (maybe a lucky guess) at narrowing down the issue, or just asking "what if this happened instead, what would you do?" 2. Grading the candidate is subjective, just like the rest of the interview process. The OP was talking in the context of college-style evaluation. I don't think you can apply either of these things to grading someone in a course. (1) doesn't scale, and (2) isn't a fair (or unbiased) way to evaluate students.
    - josephg 4y ago
      Sure you can. I’ve done “prac tests” before when I was studying CS. The test happened in a computer lab. We were given some specs and had to submit programs which implemented the specs. (The specs were written in a way that grading could happen automatically). Just do the same thing, except the student is given some code with some failing tests. Their grade is determined by how many of the bugs they can fix within the time allotted.
- no1lives4ever 4y ago
  One of the problems with debugging is that everyone seems to approach it differently. With some of the approaches working better than others in some situations. Which is why a group debugging session works great when you have a tricky problem that is not getting solved by one person. We can definitely test for basic debugging and troubleshooting skills. But I havent found a way to consistently evaluate people who are capable of identifying and finding solutions to complex problems. These days a lot of these come down to framework level experience. With the proliferation of frameworks and tools used in modern apps, it is impossible to find someone who can solve problems involving all of them. So in a big team you want a variety of such experiences to cover a wider base. Having said that, I have been in many situations where i have had to join a debugging session involving technologies or programming languages where i have had zero prior knowledge and have moved things towards a solution by asking what at times seems like basic queries to help others come up with the solution.
djmips 4y ago
Debugging is always overlooked. Even in blog posts.
yamasanama 4y ago
Most non-trivial programming homework assignments in college require debugging and a good school will provide guidance of how to do this. One thing I do in job interviews is to have the candidate debug an issue (that they usually caused themselves and that I let them purposefully run into). Quite the eye opener of how they approach bugs.
- invalidname 4y ago
  You would need to debug but can you tell if a person just printed to the console or used advanced tooling? Can you tell how long they wasted on the debugging aspect? Nope. That's the problem. These are soft skills that are hard to teach but much harder to test.
  - yamasanama 4y ago
    Yes, I can tell, because in the interview situation I'm sitting next to them. And print statements are sometimes the superior choice. This ties into my other comment that these things can be heavily subjective. As long as it gets the job done, I prefer print statements used by somebody who uses them as a sharp knife to gain understanding of what's going on over somebody just clicking buttons in a fancy UI but has no clue. (And vice versa, obviously.)
    - invalidname 4y ago
      I'm talking about universities not interviews. Print debugging is sometimes useful but sometimes indicate the person doesn't know about tracepoints/logpoints.
josephg 4y ago
I also find it odd that nobody is ever taught to read code. We spend a lot of time writing code, but how many programs does the average CS grad read by the time they graduate? Imagine going to school to learn how to write, but in the course nobody ever reads anyone else's work. And in fact, most people (including the professors) never read any books. For some reason, thats the status quo in software. In industry, learning to read other people's code is one of the most valuable skills there is. There's plenty of times I've run into a showstopper bug in some opensource library we depended on, or needed another feature that was missing. If you can't read code, how can you fix the problem? Hope there's another library out there which solves your problem better? Implement some complex workaround? But if you can read - well, you can just dive into your dependency, debug the issue there and file a PR. (And if you like, use a fork with the fix until its merged upstream).
- jdougan 4y ago
  You might find this interesting https://www.dreamsongs.com/MFASoftware.html https://www.dreamsongs.com/MFASoftware.html:
sureglymop 4y ago
I find debugging hard when it comes to web development. How can I debug a typescript web app when 1. It will actually be in javascript once it's transpiled and 2. It will run in the browser and not in my ide. It uses some kind of live reloading dev server that is completely different than the production build. Currently I'm building something with sveltekit and i have no idea how to debug this except logging out messages.
- invalidname 4y ago
  The first book above has a chapter of various tools in debugging web applications. You can use the sourcemap feature to debug TS. You are missing out on a lot of amazing capabilities by avoiding the browser debugger. Did you know you can place a breakpoint that will trigger on DOM mutation?
- hermanradtke 4y ago
  Most languages are compiled or transpired into another representation. For TypeScript, source maps can help with the debugging. The live reloading dev server is just a wrapper around your code. You should still be able to use the browsers debugger to set a breakpoint at the function you want.
- gernb 4y ago
  I don't know what your setup is but I've had no trouble debugging typescript in the browser or on the server. In the browser I use the browser's devtools and source maps. It works. For the server I use VSCode's built in node debugger integration. Both have worked great for me.
- flohofwoe 4y ago
  If the code is running in the browser: source maps are the answer (there's a step-debugger in the browser's devtools panel). But also: Modern Javascript is (more or less) just Typescript with the type hints removed, so even debugging the output JS code is pretty straightforward.
- deleted 4y ago
  [deleted]

orderedtree 4y ago

Why can't debugging be tested?

gregmac 4y ago
I can think of a couple challenges. Let's say you're debugging "the website won't load." Often debugging is a hunch, and quickly branches. One person will go down the path of trying the same site from another PC. Another will try a different site from the same browser/PC. Another will try to ping the server. If you're running this live you're always going to have the chance where someone's hunch or first try basically pinpoints the problem and eliminates a dozen checks from their consideration. If you're looking for things like "did they check DNS? Did they try another site?" but they skipped that and immediately figured out apache wasn't running, do they lose points? Or do they get 100% for their lucky (and/or experienced) guess? If you do it on paper, the major problem is basically infinite branching for every step and possible result. How do you mark that? What's the minimum you need to do to get 100%? I think it's also unfair, because even as a seasoned vet I've been deep in troubleshooting to the point of (for example) greping source of nginx for a specific error message -- which I'd never have even thought of two steps earlier. I do t expect anything that complex on a school test of course, but the point is the result of each step is often the only way to even think of the next.
- atoav 4y ago
  Sure testing a beginner is hard here. But testing someone who learned how to debug means testing their knowledge of the moving parts of the system they are debugging. And this can be explained by the person being tested. E.g. "I am going to ping an IP on the outside first, to see if ICMP message reaches the outside server. If yes I will check if the DNS server responds, if no we check the physical connection." That would be an ideal answer, judging less ideal answers fairly is certainly a challenge, but not impossible.
  - no1lives4ever 4y ago
    And what if the firewall blocks icmp? What if the dns server is internal to the network and is returning a stale ip? There are way too paths down this rabbit hole.
    - gregmac 4y ago
      This is exactly my point. It's even worse in a "school test" situation, because who knows what contrived scenario the instructor has invented depending on what their focus is (eg: DNS vs physical net vs routing vs apache config). Maybe there are multiple DNS servers for the zone that are returning different IPs, maybe one or both of them is even in split-zone configuration so it returns a different IP depending on if you're internal or external. Maybe the client has manual DNS configured or a hosts entry that's wrong. Each of these problems would have several more layers of troubleshooting steps and branching, and it's not even a complete list -- and this is only if the problem is DNS-centric! There's hundreds of other branches for each of the other problem categories.
    - atoav 4y ago
      I mean if it is a test you obviously test things that you tought them first, or not? Of course in reality there can be more, weirder things — especially if you are coming into an unknown network. But we are talking about an educational context here, would not make a lot of sense to let your students run into new unknown issues on a test unless your goal is not to educate.
  - sideshowb 4y ago
    More simply you could just ask to brainstorm 5 things the issue might be.
clintonb 4y ago
Debugging is difficult to test in a university/exam setting, but can be tested in an observational sense. Stripe does it in one of the on-site interviews.
- no1lives4ever 4y ago
  I have been in enough debugging sessions to know that it is easy to weed out those who are bad from those who have the basics right. But trying to know if a candidate is good with advanced debugging is a futile exercise. You need to be in a few intense sessions with such people to know who are good/bad at these things. I have only been able to figure this about people after working with them for 6-12 months. Which is why it helps keep references to such people and have them on your teams in future ;-)
- marginalia_nu 4y ago
  A compounding factor is that it's much harder to debug code you're not at least reasonably familiar with. Even if you can gain such intuition through looking at a piece of code, in a realistic scenario, more often than not you don't actually know in which file or method the bug is hiding. What you have is a code base and some externality that is wrong, the debugging process is essentially deepening your understanding of the relevant code (in relationship to what it should be doing) until you understand what is wrong. Debugging isn't being able to use a debugger or a profiler or syscall tracing tool or whatever, sure they help but the critical skill is being able to quickly and accurately model the behavior of a system in your head, in combination with a tacit understanding of where bugs tend to occur.
invalidname 4y ago
I can personally evaluate a specific persons skill. But doing this in a formal gradable test would be hard.
josephg 4y ago
It can. I love using debugging problems as an interview question. Give the candidate some simple code (~200-300 lines is probably about right) with a handful of failing unit tests. Sit them down, walk them through running the test suite and ask them to find and fix as many bugs as they can in 30 minutes. It pays to make the first bug trivial (like, a typo or something) and make the subsequent bugs increasingly subtle. You learn an awful lot about a candidate by watching their process. The hard thing with this sort of question is calibration. Candidates will be able to debug way less code than you think in 30 minutes. It helps to run the code past a few coworkers before giving it to candidates to figure out if its too hard a test. The surprising thing about this test is that it seems to be really highly correlated with senior engineers. Senior engineers often don't do as well as smart grads at coding problems because we often don't write that much code any more. But senior engineers seem to do waay better than juniors at debugging problems. If I could only get a candidate to do one programming problem, I'd get them to debug code. I think you get a massive amount of signal about whether you'd want to hire someone out of a debugging challenge.
- gregmac 4y ago
  Debugging works extremely well during an interview because: 1. Your evaluation can be interactive: you're watching them step through, can stop and ask questions about their thought process, etc. If it's a theoretical problem (ie: not on a live computer) you can even re-calibrate on-the-fly if they're really quick (maybe a lucky guess) at narrowing down the issue, or just asking "what if this happened instead, what would you do?" 2. Grading the candidate is subjective, just like the rest of the interview process. The OP was talking in the context of college-style evaluation. I don't think you can apply either of these things to grading someone in a course. (1) doesn't scale, and (2) isn't a fair (or unbiased) way to evaluate students.
  - josephg 4y ago
    Sure you can. I’ve done “prac tests” before when I was studying CS. The test happened in a computer lab. We were given some specs and had to submit programs which implemented the specs. (The specs were written in a way that grading could happen automatically). Just do the same thing, except the student is given some code with some failing tests. Their grade is determined by how many of the bugs they can fix within the time allotted.
no1lives4ever 4y ago
One of the problems with debugging is that everyone seems to approach it differently. With some of the approaches working better than others in some situations. Which is why a group debugging session works great when you have a tricky problem that is not getting solved by one person. We can definitely test for basic debugging and troubleshooting skills. But I havent found a way to consistently evaluate people who are capable of identifying and finding solutions to complex problems. These days a lot of these come down to framework level experience. With the proliferation of frameworks and tools used in modern apps, it is impossible to find someone who can solve problems involving all of them. So in a big team you want a variety of such experiences to cover a wider base. Having said that, I have been in many situations where i have had to join a debugging session involving technologies or programming languages where i have had zero prior knowledge and have moved things towards a solution by asking what at times seems like basic queries to help others come up with the solution.

djmips 4y ago

Debugging is always overlooked. Even in blog posts.

yamasanama 4y ago

Most non-trivial programming homework assignments in college require debugging and a good school will provide guidance of how to do this. One thing I do in job interviews is to have the candidate debug an issue (that they usually caused themselves and that I let them purposefully run into). Quite the eye opener of how they approach bugs.

invalidname 4y ago
You would need to debug but can you tell if a person just printed to the console or used advanced tooling? Can you tell how long they wasted on the debugging aspect? Nope. That's the problem. These are soft skills that are hard to teach but much harder to test.
- yamasanama 4y ago
  Yes, I can tell, because in the interview situation I'm sitting next to them. And print statements are sometimes the superior choice. This ties into my other comment that these things can be heavily subjective. As long as it gets the job done, I prefer print statements used by somebody who uses them as a sharp knife to gain understanding of what's going on over somebody just clicking buttons in a fancy UI but has no clue. (And vice versa, obviously.)
  - invalidname 4y ago
    I'm talking about universities not interviews. Print debugging is sometimes useful but sometimes indicate the person doesn't know about tracepoints/logpoints.

josephg 4y ago

I also find it odd that nobody is ever taught to read code. We spend a lot of time writing code, but how many programs does the average CS grad read by the time they graduate? Imagine going to school to learn how to write, but in the course nobody ever reads anyone else's work. And in fact, most people (including the professors) never read any books. For some reason, thats the status quo in software. In industry, learning to read other people's code is one of the most valuable skills there is. There's plenty of times I've run into a showstopper bug in some opensource library we depended on, or needed another feature that was missing. If you can't read code, how can you fix the problem? Hope there's another library out there which solves your problem better? Implement some complex workaround? But if you can read - well, you can just dive into your dependency, debug the issue there and file a PR. (And if you like, use a fork with the fix until its merged upstream).

jdougan 4y ago
You might find this interesting https://www.dreamsongs.com/MFASoftware.html https://www.dreamsongs.com/MFASoftware.html:

sureglymop 4y ago

I find debugging hard when it comes to web development. How can I debug a typescript web app when 1. It will actually be in javascript once it's transpiled and 2. It will run in the browser and not in my ide. It uses some kind of live reloading dev server that is completely different than the production build. Currently I'm building something with sveltekit and i have no idea how to debug this except logging out messages.

invalidname 4y ago
The first book above has a chapter of various tools in debugging web applications. You can use the sourcemap feature to debug TS. You are missing out on a lot of amazing capabilities by avoiding the browser debugger. Did you know you can place a breakpoint that will trigger on DOM mutation?
hermanradtke 4y ago
Most languages are compiled or transpired into another representation. For TypeScript, source maps can help with the debugging. The live reloading dev server is just a wrapper around your code. You should still be able to use the browsers debugger to set a breakpoint at the function you want.
gernb 4y ago
I don't know what your setup is but I've had no trouble debugging typescript in the browser or on the server. In the browser I use the browser's devtools and source maps. It works. For the server I use VSCode's built in node debugger integration. Both have worked great for me.
flohofwoe 4y ago
If the code is running in the browser: source maps are the answer (there's a step-debugger in the browser's devtools panel). But also: Modern Javascript is (more or less) just Typescript with the type hints removed, so even debugging the output JS code is pretty straightforward.
deleted 4y ago
[deleted]