4 ms·

When I first read the book, I remember this maxim resonated with me greatly. But these days I often feel that all I ever do is program by coincidence. Granted,

by philbo 12y ago

When I first read the book, I remember this maxim resonated with me greatly. But these days I often feel that all I ever do is program by coincidence. Granted, the coincidences come in much smaller increments now, and they're punctuated with unit tests. But they still feel like coincidences. The deliberate stuff all happens later, when I'm refactoring and the unit tests are already in place.

nulltype 12y ago
I think this may be just how most programming (and perhaps everything else besides science experiments) has to be done. If you're writing assembly code, well, computers have some pretty solid low level abstractions, but do you really understand how many clock cycles that instruction there is going to take? What about all the error cases? If you're writing for the web, it's clear you can't even try to really understand how everything works in all cases across all machines. Few programmers really understand how computer memory works, but if everyone were to read this guide (http://www.akkadia.org/drepper/cpumemory.pdf http://www.akkadia.org/drepper/cpumemory.pdf) and really learn it throughly, the net benefit probably wouldn't be that great vs other things they could do with that time. It's great fun to track down every last misunderstanding or bug, but it's probably not worth it over the long term. The benefit of learning the internal details of a reliable subsystem is often not worth it and it's easier to just use it and get on with the project. That being said, when I do go to fix a bug, I try to get to the bottom of why it happens and not just stop at the first change that works. This is useful for a number of reasons: 1) If you made the bug, you probably have some misunderstanding of the system that will be fixed when you understand the bug. 2) If you're spending your time fixing an actual bug, then the misunderstanding empirically matters because this mistake has been made and actually affects someone. 3) You tend not to accumulate a lot of superstition in your code, which makes the code much easier to read.

by philbo 12y ago

nulltype 12y ago

I think this may be just how most programming (and perhaps everything else besides science experiments) has to be done. If you're writing assembly code, well, computers have some pretty solid low level abstractions, but do you really understand how many clock cycles that instruction there is going to take? What about all the error cases? If you're writing for the web, it's clear you can't even try to really understand how everything works in all cases across all machines. Few programmers really understand how computer memory works, but if everyone were to read this guide (http://www.akkadia.org/drepper/cpumemory.pdf http://www.akkadia.org/drepper/cpumemory.pdf) and really learn it throughly, the net benefit probably wouldn't be that great vs other things they could do with that time. It's great fun to track down every last misunderstanding or bug, but it's probably not worth it over the long term. The benefit of learning the internal details of a reliable subsystem is often not worth it and it's easier to just use it and get on with the project. That being said, when I do go to fix a bug, I try to get to the bottom of why it happens and not just stop at the first change that works. This is useful for a number of reasons: 1) If you made the bug, you probably have some misunderstanding of the system that will be fixed when you understand the bug. 2) If you're spending your time fixing an actual bug, then the misunderstanding empirically matters because this mistake has been made and actually affects someone. 3) You tend not to accumulate a lot of superstition in your code, which makes the code much easier to read.