I know profilers and debuggers are a boon for productivity, but anecdotally I’ve found they’re seldom used. How often do you use debuggers/profilers in your work? What’s preventing you? conversely, what enables you to use them?

  • xian@beehaw.org
    link
    fedilink
    arrow-up
    11
    ·
    1 year ago

    As a C# programmer I use the debugger every single day, since it’s so natural and easy to use as to just run the application. I’ve grow spoiled actually, when I program in Go or Rust I really miss the “it just works” debugger.

    • Jaloopa@beehaw.org
      link
      fedilink
      arrow-up
      4
      ·
      1 year ago

      I can’t imagine programming without regularly pausing execution to inspect intermediate variables, run some quick checks in the immediate window or set conditional breakpoints. I’m always a bit surprised when I remember there are people who don’t work like that

    • frosty@beehaw.org
      link
      fedilink
      arrow-up
      4
      ·
      1 year ago

      Same here. The Visual Studio debugger is excellent, and there’s never a day that goes by without me using it.

    • pinkpatrol@anarch.isOP
      link
      fedilink
      arrow-up
      7
      ·
      1 year ago

      How do people do stuff without debuggers? :D

      Another way to develop would be through iterating within a Unit Test that you don’t plan to keep around.

      Uh, I set a breakpoint and run the app?

      To add a bit more context, it’s more difficult to configure a debugger when the application is running within something like Docker. How difficult? That depends on the language and tools you’re using.

      • Nicktar@beehaw.org
        link
        fedilink
        arrow-up
        8
        ·
        edit-2
        1 year ago

        I’ve seen the fun of “prints everywhere” in production when a colleague forgot to remove a “Why the fuck do you end up here?” followed by a bunch of variables before committing a hot-fix… Customers weren’t to amused…

        Edit: That was a PHP driven web shop and the message ended up on to of the checkout page

        • MagicShel@programming.dev
          link
          fedilink
          arrow-up
          2
          ·
          1 year ago

          That must’ve prompted a bit of existential crisis in some shoppers. I can see going to purchase some useless consumer shit online and getting a message “Why the fuck do you end up here?” and just closing my browser and rethinking my life decisions.

        • leodude@mastodon.social
          link
          fedilink
          arrow-up
          1
          ·
          1 year ago

          @Nicktar I usually prefer the prints everywhere approach, but of course printing to STDERR not STDOUT - so it ends up in a log, and not in the program output 😅 won’t make that mistake again!

      • aksdb@feddit.de
        link
        fedilink
        arrow-up
        4
        ·
        1 year ago

        We run almost everything on bare metal during development. The ci/cd pipeline runs containerized and also produces a container with the application inside, that then gets deployed to production. But we don’t debug on production, so that isn’t an issue.

  • Hudell@lemmy.dbzer0.com
    link
    fedilink
    arrow-up
    8
    ·
    1 year ago

    I use debuggers all day every day. If I’m running something in development, there’s a very good chance I have it connected to a debugger. Also use it whenever I encounter an unexpected behavior in production (we use our own product for work too)

    The profiler is a lot more specific and I haven’t used it in a while.

  • cnk@kbin.dk
    link
    fedilink
    arrow-up
    5
    ·
    1 year ago

    I have a tendency to just use console logging, and only use debuggers when things are starting to get hairy.

  • codus@leby.dev
    link
    fedilink
    arrow-up
    4
    ·
    1 year ago

    I find debuggers are used a lot more on confusing legacy code.

    Lately, monitoring tools such as OpenTelemetry have replaced a lot of my use of profilers.

  • camel-cdr@beehaw.org
    link
    fedilink
    arrow-up
    4
    ·
    1 year ago

    I recently started doing xeyes debugging.

    We have so many debug logs that trying to find your log of a background takes a non zero amount of time.

    So just inserting system("xeyes"); is actually way easier, to get instant feedback, and you can just use system("xmessage msg"), if you need a message.

  • Nicktar@beehaw.org
    link
    fedilink
    arrow-up
    4
    ·
    1 year ago

    I seldom use profilers because I seldom need to. It’s only usefull to run a profiler if your programm has a well defined perfomance issue (like “The request should have an average responsetime of X ms but has one of Y ms” or "90% of the requests should have a response after X ms but only Y% actually do).

    On the other hand I use a debugger all the time. I rarely start any programm I work on without a debugger attached. Even if I’m just running a smoke test, if this fails I want to be able to dig right into the issue without having to restart the programm in debug mode. The only situation, where i routinely run code without a debugger is the red-green-refactor cycle with running unit tests because I’ll need to re run these multiple times with a debugger anyway if there are unexpected reds…

    What enables me? Well there’s this prominent bug-shaped icon in my IDE right besides the “play button”, and there’s Dev-Tools in Chrome that comes with the debugger for JS…

    Running your code without a debugger is only usefull if you want to actually use it or if you’re so sure that there aren’t any issues that you might as well skip running the code altogether…

  • sjolsen@beehaw.org
    link
    fedilink
    arrow-up
    3
    ·
    1 year ago

    At my last job, doing firmware for datacenter devices, almost never. JTAG debugging can be useful if you can figure out how to reproduce the problem on the bench, but (a) it’s really only useful if the relevant question is “what is the state of the system” and (b) it often isn’t possible outside of the lab. My experience with firmware is that most bugs end up being solved by poring over the code or datasheets/errata and having a good long think (which is exactly as effective as it sounds – one of the reasons I left that job). The cases I’ve encountered where a debugger would be genuinely useful are almost always more practically served by printf debugging.

    Profilers aren’t really a thing when you have kilobytes of RAM. It can be done but you’re building all the infrastructure by hand (the same is true of debugger support for things like threads). Just like printf debugging, it’s generally more practical to instrument the interesting bits manually.

  • Papamousse@beehaw.org
    link
    fedilink
    arrow-up
    3
    ·
    1 year ago

    Really often, even since TurboDebuger in the 90s, no other way to trace your code, step over/into, watch variables, etc. For compiled program it’s necessary. For javascript I use print lol

    • The Doctor@beehaw.org
      link
      fedilink
      arrow-up
      2
      ·
      1 year ago

      Don’t forget being able to watch the stack in realtime, and run your code backwards to roll back its state!

  • Biscuit@kbin.social
    link
    fedilink
    arrow-up
    2
    ·
    edit-2
    1 year ago

    Every single day. They’re built into the IDE. It’s easier to use them than to not use them.

  • mike901@beehaw.org
    link
    fedilink
    arrow-up
    2
    ·
    1 year ago

    All the time. I deal with a lot C# code that makes and responds to HTTP API requests, and being able to check if requests and responses are properly formed without having to slap print statements everywhere is a godsend.

  • letsgo@lemm.ee
    link
    fedilink
    arrow-up
    2
    ·
    1 year ago

    C# dev here. Quite frequently. When writing new code, instead of trawling the docs looking for what odd name the thing I’m looking for has been given, especially when it’s several layers deep in a structure where each layer has dozens of members, to see where in the data structure the value I’m looking for is, makes it a lot easier to determine the next few lines of code to write.

  • miniu@beehaw.org
    link
    fedilink
    arrow-up
    2
    ·
    1 year ago

    This usually depends on which industry you work in, and what language you’re using usually :)

    I work in gamedev, c++, and I ALWAYS use a debugger. There’s no running the game, or even the editor without the debugger connected. No matter if you need it currently or not. You always launch the project through the debugger so if anything comes up you can investigate immediately.

    Profiler is used any time there’s a performance problem.

    • miniu@beehaw.org
      link
      fedilink
      arrow-up
      2
      ·
      1 year ago

      What enables me to use them is probably that this is very much true for the whole industry so software is built with that in mind.

      For example, we use special “print” statements for some of the errors that if a debugger is running, it will automatically stop the program so you can investigate. Without a debugger, it will just output the error in the log.

      There is no docker, the app is running usually on your local hardware. Consoles are also built with debugger support that you connect to from your PC. So it’s very easy to use. Even connecting to another PC in a local network, for example, an artist or tester hardware, is possible from your computer without a problem. We have all the tools prepared for that.

  • ShittyKopper [they/them]@lemmy.w.on-t.work
    link
    fedilink
    English
    arrow-up
    1
    ·
    1 year ago

    I’m starting to get into the habit of reaching for debuggers more and more as opposed to just print()ing everything and hoping for the best.

    Profilers on the other hand I still have no idea how to apply (and more importantly, read the results of) properly, so that’s something I’ll need to learn.