3 ms·

Write 5 tests for a piece of code that you think is working but has no tests. You will find at least 1 bug every time. Staying at work longer won't help you p

Write 5 tests for a piece of code that you think is working but has no tests. You will find at least 1 bug every time. Staying at work longer won't help you produce more and better code. Sleep and exercise will. People who get angry about technical choices like what framework to use or what coding style or how tightly to enforce rules will flame out. Don't be that person. If you think you need to rewrite it from scratch, think again. Look up Chesterton's Fence.

brador 10y ago
"Chesterton's fence is the principle that reforms should not be made until the reasoning behind the existing state of affairs is understood." In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, "I don't see the use of this; let us clear it away." To which the more intelligent type of reformer will do well to answer: "If you don't see the use of it, I certainly won't let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it."[1] Source - Wikipedia.
- crazygringo 10y ago
  Chesterton's Fence is a great example of why code comments are critical. If the code is doing something that isn't immediately obvious to a programmer on a deadline, there should be comments explaining why it's there. "Go away and think" just means the programmer who wrote it couldn't be bothered to take a couple of minutes to be clear, resulting in later programmers wasting hours or days (or worse) re-discovering the reason for something in the first place.
  - btschaegg 10y ago
    A counterpoint to this is that the very reason to refactor code usually is that it isn't understandable anymore. I'd rather read it in the way that you shouldn't rewrite code for which you don't understand the problem it's trying to solve. In my experience, that part is usually much easier, since you're working in hindsight. There's a great interview Peter Seibel did with Bernie Cosell[1], where Cosell explains that his approach to debugging usually consisted in a) understanding what a specific piece of code is supposed to do and b) rewriting it so it actually would do it properly. Of course there's much to be said on when this approach is overkill and when it isn't. [1]: https://en.m.wikipedia.org/wiki/Coders_at_work https://en.m.wikipedia.org/wiki/Coders_at_work
  - Can_Not 10y ago
    > "Go away and think" just means the programmer who wrote it couldn't be bothered to take a couple of minutes to be clear I haven't had the luxury of working with a lot of experienced veterans, but I've seen and been burnt by rookies who couldn't be bothered to read code other people wrote or written without their favorite framework/language. No amount of comments would deflect those types.
travmatt 10y ago
Chesterton's Fence is a brilliant insight. Funnily enough, I learned it reading some interview in a fashion magazine. They talked about what made different designers styles is the fact that they didn't break fashion 'rules' haphazardly, rather that people should only break 'rules' they knew the purpose for and why they wanted to do so.

brador 10y ago

"Chesterton's fence is the principle that reforms should not be made until the reasoning behind the existing state of affairs is understood." In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, "I don't see the use of this; let us clear it away." To which the more intelligent type of reformer will do well to answer: "If you don't see the use of it, I certainly won't let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it."[1] Source - Wikipedia.

crazygringo 10y ago
Chesterton's Fence is a great example of why code comments are critical. If the code is doing something that isn't immediately obvious to a programmer on a deadline, there should be comments explaining why it's there. "Go away and think" just means the programmer who wrote it couldn't be bothered to take a couple of minutes to be clear, resulting in later programmers wasting hours or days (or worse) re-discovering the reason for something in the first place.
- btschaegg 10y ago
  A counterpoint to this is that the very reason to refactor code usually is that it isn't understandable anymore. I'd rather read it in the way that you shouldn't rewrite code for which you don't understand the problem it's trying to solve. In my experience, that part is usually much easier, since you're working in hindsight. There's a great interview Peter Seibel did with Bernie Cosell[1], where Cosell explains that his approach to debugging usually consisted in a) understanding what a specific piece of code is supposed to do and b) rewriting it so it actually would do it properly. Of course there's much to be said on when this approach is overkill and when it isn't. [1]: https://en.m.wikipedia.org/wiki/Coders_at_work https://en.m.wikipedia.org/wiki/Coders_at_work
- Can_Not 10y ago
  > "Go away and think" just means the programmer who wrote it couldn't be bothered to take a couple of minutes to be clear I haven't had the luxury of working with a lot of experienced veterans, but I've seen and been burnt by rookies who couldn't be bothered to read code other people wrote or written without their favorite framework/language. No amount of comments would deflect those types.

travmatt 10y ago

Chesterton's Fence is a brilliant insight. Funnily enough, I learned it reading some interview in a fashion magazine. They talked about what made different designers styles is the fact that they didn't break fashion 'rules' haphazardly, rather that people should only break 'rules' they knew the purpose for and why they wanted to do so.