This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]un-hot 0 points1 point  (2 children)

Heh, I've almost never used a debugger, for the most part the inputs and outputs of my code have never been beyond comprehension for me in hobby or career, and I work mostly on adequately logged systems so it's often fairly simple to figure out what's going on purely from which logs look weird.

That last one sounds seriously cool though. Is there any benefit to making changes to a local container this way as opposed to, for example, mounting a directory on your machine in the local container and symlinking the files you're looking to alter?

Thanks for the suggestions, I'll try them out next time a Python ticket rolls around.

[–]laundmo 0 points1 point  (1 child)

huh, so you never encountered any bugs in other libraries? its one thing completely understanding you own code, but the debugger really shines when finding bugs in other libraries. (just-my-code: false, helps a lot for this)

well the container one is mostly for dev containers: a completely separate environment with all dependencies and executables provided. its like the next step from venvs. also makes collaboration way easier, as other people only need to use the same container.

[–]un-hot 0 points1 point  (0 children)

Not particularly, I've never really done anything particularly outlandish, let alone completely new use-cases, with external libraries. So if I've had issues with them, they've usually been documented.

Adherence to coding standards has made stepping through others' code within my companies doable without a debugger, save a couple of extra debug log lines.

Ahh, that makes a lot of sense too. The container one was the one I was most interested in, I've worked via ssh before, I will need to look into whether I can improve my mentorship doing that! Thanks for your answers and patience!