4 ms·

> when debugging, many programmers prefer to make small changes to their code (tweaks) and run it again to see if the bug is fixed rather than spending the ener

> when debugging, many programmers prefer to make small changes to their code (tweaks) and run it again to see if the bug is fixed rather than spending the energy to create a good mental model of the problem Then there's the feeling you get after you have done a dozen of fixes to your code and none of them fixed the problem which got you started until you realize that you were debugging the wrong file. There was so much room for improvement.

gumby 5y ago
> when debugging, many programmers prefer to make small changes to their code (tweaks) and run it again to see if the bug is fixed rather than spending the energy to create a good mental model of the problem This problem can be solved by increasing compile time.
dhzhzjsbevs 5y ago
Brute force problem solving is a technique like any other. Has its pros and cons, places it excells and places it doesn't. I can only expend so much energy learning a problem domain so many times a day, sometimes, using instinct and learned heuristics to find a fix without building a mental model of the wider picture is good enough. I should also add it depends greatly on your codebase. Some code bases are so rotten your heuristics won't work but if you have clean abstractions or even just code that generally limits the amount of weird and unexpected shit it does you should be fine brute forcing a few things saving brain power for later in the day.
- WJW 5y ago
  So true. I'll add that sometimes there is not really a mental model to be built for the code because there wasn't one when the code was built; too many programmers over the years, each with their own style.
cjbgkagh 5y ago
I sometime go weeks without compiling. Background type checking and a defensive coding style works well for me. When I do run code I expect it to work the first time. I do white box test it to be sure. I find other developers to be rather cavalier about bugs, bugs are a valuable learning opportunity to me and each one goes into a ledger so that lessons are not lost.
- w0m 5y ago
  What field do you work in? It's rare I'm able to work on the same project for weeks at a time; let alone compile.
  - cjbgkagh 5y ago
    It’s my own software that I sell licenses to. I’m a solo dev but I have had contractors help me from time to time. 6 years of dev time with over 500K LOC of a wide variety of languages. It’s mostly really dense functional code. It’s an extremely stable code base - once something is built it’s unlikely I’ll ever have to touch it again. One of my primary motivations to do solo dev was to have the freedom to do things properly without ill-informed program managers rushing me into bad decisions.
    - chrisweekly 5y ago
      Is any of it OSS? I'm always eager to see high-quality codebases like what you've described.
      - cjbgkagh 5y ago
        I keep this account (and all social accounts anonymous) so I can’t share my OSS code. I think self-hosting meta language compilers would be the closest similar code base. My code is targeted to experienced functional programmers, and others of the same skill level seem to have no trouble with it, but the less experienced will bounce off it. My thinking is that those people should get more experience and come back instead of optimizing my codebase to a lower common denominator for ease of hiring. This has made hiring difficult as anyone who can work on my code base can probably get a high paying job at a FANG. But as a solo dev the productivity gain is enough that I still have no trouble competing in my niche.
- kaetemi 5y ago
  I find that the strategy of writing for a week or two without compiling works well for me too. At least when the goal is big and clear. Doesn't work with clients who aren't quite sure what their own requirements are, of course. Then it's more of a few days at most, so revisions can be done early. If I'm interfacing with a library that I'm not familiar with, I'll usually do trial and error in a blank project, separate from the actual project, first. Then write cleanly in the real project. Iteration times on the learning process are faster that way. Sometimes I'll just write long drafts or snippets in notepad at first, just to stay clear of IDE distractions. It's a fast way of figuring out the structure of things without the need for everything to compile at all times.
ilaksh 5y ago
Or like the other night when I fixed something in the code, still saw the problem when deploying, then unfixed and tried something else, repeat for two solid hours, then finally realize I forgot to copy the file into my `web` directory. Would have been nice if I just had it outputting to the right place from the start. But that sort of dumb deployment thing is what gets me when I am tired, more often than something really complicated.
logbiscuitswave 5y ago
I once spent a whole bunch of time trying to debug and iterate on an issue in a dependency library my application was using. No matter what I tried it just didn’t seem to help with the issue - even though I was certain of the fix. I was going crazy trying different things with none of them making any difference. I eventually realized I was running into a bug in my build environment. It wasn’t detecting the library had any code changes so it was “optimizing” my build by skipping that library. It was one of a dozen or so dependencies so it wasn’t immediately obvious. Eventually, I set a breakpoint somewhere else in the library code and realized it wasn’t being hit because the source code didn’t match the symbols! I felt pretty dumb once so figured this out even though rationally I know it wasn’t my fault.

gumby 5y ago

dhzhzjsbevs 5y ago

Brute force problem solving is a technique like any other. Has its pros and cons, places it excells and places it doesn't. I can only expend so much energy learning a problem domain so many times a day, sometimes, using instinct and learned heuristics to find a fix without building a mental model of the wider picture is good enough. I should also add it depends greatly on your codebase. Some code bases are so rotten your heuristics won't work but if you have clean abstractions or even just code that generally limits the amount of weird and unexpected shit it does you should be fine brute forcing a few things saving brain power for later in the day.

WJW 5y ago
So true. I'll add that sometimes there is not really a mental model to be built for the code because there wasn't one when the code was built; too many programmers over the years, each with their own style.

cjbgkagh 5y ago

I sometime go weeks without compiling. Background type checking and a defensive coding style works well for me. When I do run code I expect it to work the first time. I do white box test it to be sure. I find other developers to be rather cavalier about bugs, bugs are a valuable learning opportunity to me and each one goes into a ledger so that lessons are not lost.

w0m 5y ago
What field do you work in? It's rare I'm able to work on the same project for weeks at a time; let alone compile.
- cjbgkagh 5y ago
  It’s my own software that I sell licenses to. I’m a solo dev but I have had contractors help me from time to time. 6 years of dev time with over 500K LOC of a wide variety of languages. It’s mostly really dense functional code. It’s an extremely stable code base - once something is built it’s unlikely I’ll ever have to touch it again. One of my primary motivations to do solo dev was to have the freedom to do things properly without ill-informed program managers rushing me into bad decisions.
  - chrisweekly 5y ago
    Is any of it OSS? I'm always eager to see high-quality codebases like what you've described.
    - cjbgkagh 5y ago
      I keep this account (and all social accounts anonymous) so I can’t share my OSS code. I think self-hosting meta language compilers would be the closest similar code base. My code is targeted to experienced functional programmers, and others of the same skill level seem to have no trouble with it, but the less experienced will bounce off it. My thinking is that those people should get more experience and come back instead of optimizing my codebase to a lower common denominator for ease of hiring. This has made hiring difficult as anyone who can work on my code base can probably get a high paying job at a FANG. But as a solo dev the productivity gain is enough that I still have no trouble competing in my niche.
kaetemi 5y ago
I find that the strategy of writing for a week or two without compiling works well for me too. At least when the goal is big and clear. Doesn't work with clients who aren't quite sure what their own requirements are, of course. Then it's more of a few days at most, so revisions can be done early. If I'm interfacing with a library that I'm not familiar with, I'll usually do trial and error in a blank project, separate from the actual project, first. Then write cleanly in the real project. Iteration times on the learning process are faster that way. Sometimes I'll just write long drafts or snippets in notepad at first, just to stay clear of IDE distractions. It's a fast way of figuring out the structure of things without the need for everything to compile at all times.

ilaksh 5y ago

Or like the other night when I fixed something in the code, still saw the problem when deploying, then unfixed and tried something else, repeat for two solid hours, then finally realize I forgot to copy the file into my `web` directory. Would have been nice if I just had it outputting to the right place from the start. But that sort of dumb deployment thing is what gets me when I am tired, more often than something really complicated.

logbiscuitswave 5y ago

I once spent a whole bunch of time trying to debug and iterate on an issue in a dependency library my application was using. No matter what I tried it just didn’t seem to help with the issue - even though I was certain of the fix. I was going crazy trying different things with none of them making any difference. I eventually realized I was running into a bug in my build environment. It wasn’t detecting the library had any code changes so it was “optimizing” my build by skipping that library. It was one of a dozen or so dependencies so it wasn’t immediately obvious. Eventually, I set a breakpoint somewhere else in the library code and realized it wasn’t being hit because the source code didn’t match the symbols! I felt pretty dumb once so figured this out even though rationally I know it wasn’t my fault.