5 ms·

> You can't debug something just by reading the code. You are doing those junior engineers a disservice with this message. I'm usually trying to go in the oth

> You can't debug something just by reading the code. You are doing those junior engineers a disservice with this message. I'm usually trying to go in the other direction with them - you don't need to be able to reproduce it yourself or see the log files to narrow down or find the cause of an issue. Logs/etc are just additional tool that make it easier. Lost track of how many juniors I've seen throw their hands up and say they can't progress because they don't have logs/clean repro

sillyfluke 9d ago
> Lost track of how many juniors I've seen throw their hands up and say they can't progress because they don't have logs/clean repro Not the parent, but I think their approach is the correct one even though their line that you quote "You can't debug something..." should be everything instead of something. The issue with your juniors is them throwing their hands in the air without actually reading the code when they hit a wall, and not them trying to reproduce and inspect the bug first. What's the issue with telling them, "Obviously if you can't reproduce it and inspect it with dev tools, read the code."? I've won bets off devs who blamed me cause they said they couldn't reproduce the bug consistently when they tried but it would happen randomly in production. Mind you, the bet wasn't even about who was at fault. The bet was that I could reproduce it if I actually tried. You are complaining about juniors in a role that's known for the motto "it works on my machine" of course they're going to whine the moment it takes some effort to reproduce something. At the end of the day, how are you going to claim you fixed an issue if you can't reproduce it to begin with? The senior has to now read the code more carefully cause there is no proof the junior actually fixed anything.
- GrinningFool 9d ago
  I'm actually not complaining. I coach them through it, but the primary help I give is showing them how to walk through the code, and break the dependency on logs/repro scenarios.[1] In addition, if you find the issue in the code -- unless it's a really unusual race condition -- you have what you need to construct a reproduction scenario. That's also part of the coaching. [1] At least, I did until the place I work switched everyone to vibe coding. Now I give terse responses to their LLM-generated PRs -- which usually misses the forest for the trees -- since I know that they're just going to feed my words back into the machine.
  - bluefirebrand 8d ago
    I really disagree with this approach to debugging It's a good approach if every run of your code is very slow or very expensive, but if you can iterate quickly by running the code it's way more effective to try to reproduce and narrow it down that way I think you've been doing your juniors a disservice
    - GrinningFool 8d ago
      Logs are great. Interactive debugging is great. Both of these can also help build an understanding of the code and systems involved. But they're just debugging tools, and they should rarely be /required/ to find a bug. I am teaching the more fundamental skill: how to (learn to) think through the problems and the systems in a way that lets log files be a useful tool instead of the only option.

sillyfluke 9d ago

> Lost track of how many juniors I've seen throw their hands up and say they can't progress because they don't have logs/clean repro Not the parent, but I think their approach is the correct one even though their line that you quote "You can't debug something..." should be everything instead of something. The issue with your juniors is them throwing their hands in the air without actually reading the code when they hit a wall, and not them trying to reproduce and inspect the bug first. What's the issue with telling them, "Obviously if you can't reproduce it and inspect it with dev tools, read the code."? I've won bets off devs who blamed me cause they said they couldn't reproduce the bug consistently when they tried but it would happen randomly in production. Mind you, the bet wasn't even about who was at fault. The bet was that I could reproduce it if I actually tried. You are complaining about juniors in a role that's known for the motto "it works on my machine" of course they're going to whine the moment it takes some effort to reproduce something. At the end of the day, how are you going to claim you fixed an issue if you can't reproduce it to begin with? The senior has to now read the code more carefully cause there is no proof the junior actually fixed anything.

GrinningFool 9d ago
I'm actually not complaining. I coach them through it, but the primary help I give is showing them how to walk through the code, and break the dependency on logs/repro scenarios.[1] In addition, if you find the issue in the code -- unless it's a really unusual race condition -- you have what you need to construct a reproduction scenario. That's also part of the coaching. [1] At least, I did until the place I work switched everyone to vibe coding. Now I give terse responses to their LLM-generated PRs -- which usually misses the forest for the trees -- since I know that they're just going to feed my words back into the machine.
- bluefirebrand 8d ago
  I really disagree with this approach to debugging It's a good approach if every run of your code is very slow or very expensive, but if you can iterate quickly by running the code it's way more effective to try to reproduce and narrow it down that way I think you've been doing your juniors a disservice
  - GrinningFool 8d ago
    Logs are great. Interactive debugging is great. Both of these can also help build an understanding of the code and systems involved. But they're just debugging tools, and they should rarely be /required/ to find a bug. I am teaching the more fundamental skill: how to (learn to) think through the problems and the systems in a way that lets log files be a useful tool instead of the only option.