3 ms·

> They end up getting into a "dopamine feedback loop" that causes them to continually make tiny changes and rebuild/run, Yeah that's what I'm doing all the tim

> They end up getting into a "dopamine feedback loop" that causes them to continually make tiny changes and rebuild/run, Yeah that's what I'm doing all the time. Just constantly testing the thing after every little change. If the test is fast, I like it. Probably there is some dopamine thing. I have thought of it in the past as like a slot machine. > and the code written as a result of this looks exactly like what you'd expect: Why would you expect any particular thing? > it barely works, and is full of redundancies, "dead ends", and other evidence that its author was probably not thinking of anything more than the next line or two when writing it. My code isn't like that though. Maybe that code was like that because it's beginner code. > In other words, reducing the iteration time reduces the motivation to get it right the first time I'm always hoping it works on the first time but you know how that goes. Even when it's close there's some little thing. The hope of getting untested code right on the first try isn't really something I entertain too seriously anymore. Short iteration is lovely.

GreenWatermelon 5y ago
Getting a particular piece if code running from the first time is so unexpected that I'm like "Huh... that's pretty cool" everytime it happens. no need to spend 3 more minutes looking at the code when a 2 seconds build will tell me there's a Segmentation fault right there, or when Valgrind will tell me I missed a free ().
- mannykannot 5y ago
  Only a small fraction of segmentation-fault-causing errors will be revealed in 2 seconds of testing. Thinking about all the ways your code could fail, and being able to keep a mental track of the constraints you need to observe, is a useful skill to acquire.
  - TheDesolate0 5y ago
    confused crustacean noises But, seriously, I do NOT miss C/C++.
- patrakov 5y ago
  Well, yesterday I made a rather significant change to the code. Essentially, a reimplementation of an existing function in a completely different way, to avoid a memory consumption issue that cannot be solved in the old approach. 68 insertions, 15 deletions. It, unexpectedly, worked correctly and passed all tests from the first attempt, even though there are threads involved, and they are my weak point. But I didn't have a "Huh... that's pretty cool" moment. I had an "I don't like this code, it's too complex, it must be wrong somehow" moment.
  - johnny22 5y ago
    or just feel both.. at the same time.

GreenWatermelon 5y ago

Getting a particular piece if code running from the first time is so unexpected that I'm like "Huh... that's pretty cool" everytime it happens. no need to spend 3 more minutes looking at the code when a 2 seconds build will tell me there's a Segmentation fault right there, or when Valgrind will tell me I missed a free ().

mannykannot 5y ago
Only a small fraction of segmentation-fault-causing errors will be revealed in 2 seconds of testing. Thinking about all the ways your code could fail, and being able to keep a mental track of the constraints you need to observe, is a useful skill to acquire.
- TheDesolate0 5y ago
  confused crustacean noises But, seriously, I do NOT miss C/C++.
patrakov 5y ago
Well, yesterday I made a rather significant change to the code. Essentially, a reimplementation of an existing function in a completely different way, to avoid a memory consumption issue that cannot be solved in the old approach. 68 insertions, 15 deletions. It, unexpectedly, worked correctly and passed all tests from the first attempt, even though there are threads involved, and they are my weak point. But I didn't have a "Huh... that's pretty cool" moment. I had an "I don't like this code, it's too complex, it must be wrong somehow" moment.
- johnny22 5y ago
  or just feel both.. at the same time.