4 ms·

That's a good question. There are different ways: - Play around with the program intelignetly and observe no bugs (you wouldn't believe how many bugs I've found

by ambrop7 10y ago

That's a good question. There are different ways: - Play around with the program intelignetly and observe no bugs (you wouldn't believe how many bugs I've found by that method, that have been missed by very formal verification processes). - Don't call it done until you haven't proven to yourself that the code has no bugs. This is an informal process of self-code-review but which involves quite rigorous thinking about the behavior of the code. Often assertions are involved (which all have to be proved).

lisivka 10y ago
How you prove to your peer that you done all of above? How your code is able to pass peer reviews??
- ambrop7 10y ago
  Well, I haven't claimed to be able to to that, but to write mostly bugless code :) Though, writing insightful comments in the code helps. If anyone has doubt, you explain in a friendly way why they're wrong (if they are). Though, not all reviewers will study the code suffciently to find possible bugs, and also many findings are not the right/wrong kind but more about style/architecture.
  - lisivka 10y ago
    I also doing all of that AND test cases. However, I never use debugger. :-/
  - jasonm23 10y ago
    Since you're actually writing tests (you say you're doing checks, which are effectively tests.) Why not just add them to a test suite? You win twice, or more. You get proof of the assertions you're making to your peers, you get regression tests to cover your code when it's being refactored, you also get to strongly document the intent of your code so that others can know it deeply, relatively quickly. See devs like yourself who claim they aren't writing tests, but in essence they are, the only difference is they're not persisting their tests, and losing their value beyond initial validation of the correctness of the code.
  - deleted 10y ago
    [deleted]
crpatino 10y ago
> Play around with the program intelignetly and observe no bugs That's the most sophomore thing I have read in a long time!!! Probably works OK if you are working alone in a simple product whose whole code mostly fits inside a single brain. Try doing that as part of a team of dozens that make daily changes to a code base of millions of lines and you will very soon earn the title of the most infamous person in the office.
- ambrop7 10y ago
  Right. In large projects some kind of automated tests are indeed useful. But they should not be a substitute for writing working code in the first place, just as an extra level of quality assurance.
  - lisivka 10y ago
    Just compare web design before ACID and after ACID. All browsers had working code, but web design was nightmare.
- ambrop7 10y ago
  BTW, can you elaborate on the meaning of "sophomore"? I can't find in a dictionary anything other than "second in a series" which doesn't seem to make sense in your use.
  - joevandyk 10y ago
    Probably means http://www.merriam-webster.com/dictionary/sophomoric http://www.merriam-webster.com/dictionary/sophomoric
  - Macha 10y ago
    Sophomore is the name of the second year in American high schools, so he's basically calling it an comment someone inexperienced would make
TylerE 10y ago
You know, I used to be like that. Then I had the revelation that in the time it took to click test something 4 or 5 times I could write test code that could click test in less than 100ms forever.
jacques_chester 10y ago
> Play around with the program intelignetly and observe no bugs What if the computer encoded your knowledge? > Don't call it done until you haven't proven to yourself that the code has no bugs. What happens when the software changes? Do you repeat every single desk-checking exercise to ensure nothing has broken? Do you even remember every click, every experimental input? Can you prove that you do? > This is an informal process of self-code-review but which involves quite rigorous thinking about the behavior of the code. I trust that smarter developers than me are smarter developers than me. But I am dumb. I assume that the code is smart and that my mental simulation of the code, which my brain helpfully and invisibly patches on the fly, is correct. But my mental simulation is frequently wrong. So I wrap myself in explicit statements of what I think the code does. Then I make those explicit statements executable. And then I run them frequently. And frequently, I realise again that I am dumb and I should leave the flawless coding to others.
- ambrop7 10y ago
  > What if the computer encoded your knowledge? > Do you even remember every click, every experimental input? > Can you prove that you do? I agree some tests are a good idea depending on the project. Doesn't mean I have to like writing them! > I assume that the code is smart and that my mental simulation of the code, which my brain helpfully and invisibly patches on the fly, is correct. I try not to assume things until I've constructed associated proofs in my mind (and sometimes written them into comments). In fact keeping in mind what you've established (proven) and what not is a very important thing. Most of the bugs I've done are because I've simply forgotten to think about / prove something. It's a completely different way of programming! > Then I make those explicit statements executable. And then I run them frequently. But I prefer to write down these explicit statements in the code itself, often as assertions. I can then prove them right on the spot!

by ambrop7 10y ago

lisivka 10y ago

How you prove to your peer that you done all of above? How your code is able to pass peer reviews??

ambrop7 10y ago
Well, I haven't claimed to be able to to that, but to write mostly bugless code :) Though, writing insightful comments in the code helps. If anyone has doubt, you explain in a friendly way why they're wrong (if they are). Though, not all reviewers will study the code suffciently to find possible bugs, and also many findings are not the right/wrong kind but more about style/architecture.
- lisivka 10y ago
  I also doing all of that AND test cases. However, I never use debugger. :-/
- jasonm23 10y ago
  Since you're actually writing tests (you say you're doing checks, which are effectively tests.) Why not just add them to a test suite? You win twice, or more. You get proof of the assertions you're making to your peers, you get regression tests to cover your code when it's being refactored, you also get to strongly document the intent of your code so that others can know it deeply, relatively quickly. See devs like yourself who claim they aren't writing tests, but in essence they are, the only difference is they're not persisting their tests, and losing their value beyond initial validation of the correctness of the code.
- deleted 10y ago
  [deleted]

crpatino 10y ago

> Play around with the program intelignetly and observe no bugs That's the most sophomore thing I have read in a long time!!! Probably works OK if you are working alone in a simple product whose whole code mostly fits inside a single brain. Try doing that as part of a team of dozens that make daily changes to a code base of millions of lines and you will very soon earn the title of the most infamous person in the office.

ambrop7 10y ago
Right. In large projects some kind of automated tests are indeed useful. But they should not be a substitute for writing working code in the first place, just as an extra level of quality assurance.
- lisivka 10y ago
  Just compare web design before ACID and after ACID. All browsers had working code, but web design was nightmare.
ambrop7 10y ago
BTW, can you elaborate on the meaning of "sophomore"? I can't find in a dictionary anything other than "second in a series" which doesn't seem to make sense in your use.
- joevandyk 10y ago
  Probably means http://www.merriam-webster.com/dictionary/sophomoric http://www.merriam-webster.com/dictionary/sophomoric
- Macha 10y ago
  Sophomore is the name of the second year in American high schools, so he's basically calling it an comment someone inexperienced would make

TylerE 10y ago

You know, I used to be like that. Then I had the revelation that in the time it took to click test something 4 or 5 times I could write test code that could click test in less than 100ms forever.

jacques_chester 10y ago

> Play around with the program intelignetly and observe no bugs What if the computer encoded your knowledge? > Don't call it done until you haven't proven to yourself that the code has no bugs. What happens when the software changes? Do you repeat every single desk-checking exercise to ensure nothing has broken? Do you even remember every click, every experimental input? Can you prove that you do? > This is an informal process of self-code-review but which involves quite rigorous thinking about the behavior of the code. I trust that smarter developers than me are smarter developers than me. But I am dumb. I assume that the code is smart and that my mental simulation of the code, which my brain helpfully and invisibly patches on the fly, is correct. But my mental simulation is frequently wrong. So I wrap myself in explicit statements of what I think the code does. Then I make those explicit statements executable. And then I run them frequently. And frequently, I realise again that I am dumb and I should leave the flawless coding to others.

ambrop7 10y ago
> What if the computer encoded your knowledge? > Do you even remember every click, every experimental input? > Can you prove that you do? I agree some tests are a good idea depending on the project. Doesn't mean I have to like writing them! > I assume that the code is smart and that my mental simulation of the code, which my brain helpfully and invisibly patches on the fly, is correct. I try not to assume things until I've constructed associated proofs in my mind (and sometimes written them into comments). In fact keeping in mind what you've established (proven) and what not is a very important thing. Most of the bugs I've done are because I've simply forgotten to think about / prove something. It's a completely different way of programming! > Then I make those explicit statements executable. And then I run them frequently. But I prefer to write down these explicit statements in the code itself, often as assertions. I can then prove them right on the spot!