4 ms·

Maybe I'm a worse than average coder, but I find it nearly impossible to write a "unit" of code without also writing one or two bugs along the way. So whether y

Maybe I'm a worse than average coder, but I find it nearly impossible to write a "unit" of code without also writing one or two bugs along the way. So whether you do your testing ad hoc as you develop, or write unit tests, you do have to spend time in testing each unit of code you write. It doesn't seem to me that formalizing this into a repeatable unit test is adding a lot of real extra work.

Retric 8y ago
I would suggest trying to write correct code without unit tests. They fill up mental capacity making it harder to think about then write correct code in the first place. Keeping below 1 bug per 100 lines of code is viable simply by being careful and thinking things through. That's a long way from perfection, but it really helps.
- verinus 8y ago
  THen why not think "in-code"? I mean thinking through all aspects of edge cases and the like would likely result in some written documentation- why not do it in code then?
  - Retric 8y ago
    You can only focus on a relatively small number of different things at the exact same time. 1 3 2 5 9 2 8 7 vs. 1 3 2 5 9 2 8 7 Memorizing the first sequence is trivial, but dealing with each half independently is much less mental effort. Now each idea can be more complex than just a number, but even still you make fewer mistakes by removing mental overhead. PS: Now, their are a lot of tricks on how you can get better at this stuff. But if the parent poster tends to write bugs in most functions then simplifying things may help.
- blktiger 8y ago
  I find that writing unit tests helps me think about the code so that I write better code. Plus it generally forces me to make the code more modular than I might otherwise. YMMV
  - Retric 8y ago
    If it's working for you then great. I am specifically responding to: > I find it nearly impossible to write a "unit" of code without also writing one or two bugs along the way Finding bugs early is great, but minimizing bug creation is even better.
- dpark 8y ago
  Advice that boils down to “try harder” typically provides no value. If you want an outcome to change, you have to change an input. Better tooling or better processes may achieve that. Trying harder rarely will, because most people are already trying quite hard to do a good job.
  - Retric 8y ago
    I think people may be reading this backwards. I am specifically saying don't try as hard. Don't think about unit tests or anything else when writing correct code for a function. Once you can generally write mostly correct code then you can work on improving your process. But, until most of your functions are working when you right them just work on improving that. Edit: And yea quality may drop as part of this transition, but you need to get a feel for how much you can pay attention to.
    - dpark 8y ago
      You’re saying that if you have a problem with code correctness, the solution is to just try harder to write correct code. The tests are there specifically to help find the errors that “trying harder” didn’t catch. You don’t get a higher quality result by cutting QA.
      - Retric 8y ago
        I don't necessarily think he has a problem with code correctness after QA. I think he has a problem with code correctness before QA. You can build a factory that has a Great QA process that finds all faults and corrects them. But, inside the factory you still want to minimize the amount of defects for QA to find. Either way you still need QA, but it's easy to get into the habit of improving QA vs improving the initial process. PS: One exercise I did for a while was every time I found a non syntax bug in a function I just wrote (aka bug at run-time) I would start over and rewrite it. It's painful, but 'Build' wait let's look at this again if I hit run and it does not work that's going to be painful. So is this actually correct? Anyway, doing that showed me how important it was to just focus on the code (and what it means) to exclusion of everything else.

Retric 8y ago

I would suggest trying to write correct code without unit tests. They fill up mental capacity making it harder to think about then write correct code in the first place. Keeping below 1 bug per 100 lines of code is viable simply by being careful and thinking things through. That's a long way from perfection, but it really helps.

verinus 8y ago
THen why not think "in-code"? I mean thinking through all aspects of edge cases and the like would likely result in some written documentation- why not do it in code then?
- Retric 8y ago
  You can only focus on a relatively small number of different things at the exact same time. 1 3 2 5 9 2 8 7 vs. 1 3 2 5 9 2 8 7 Memorizing the first sequence is trivial, but dealing with each half independently is much less mental effort. Now each idea can be more complex than just a number, but even still you make fewer mistakes by removing mental overhead. PS: Now, their are a lot of tricks on how you can get better at this stuff. But if the parent poster tends to write bugs in most functions then simplifying things may help.
blktiger 8y ago
I find that writing unit tests helps me think about the code so that I write better code. Plus it generally forces me to make the code more modular than I might otherwise. YMMV
- Retric 8y ago
  If it's working for you then great. I am specifically responding to: > I find it nearly impossible to write a "unit" of code without also writing one or two bugs along the way Finding bugs early is great, but minimizing bug creation is even better.
dpark 8y ago
Advice that boils down to “try harder” typically provides no value. If you want an outcome to change, you have to change an input. Better tooling or better processes may achieve that. Trying harder rarely will, because most people are already trying quite hard to do a good job.
- Retric 8y ago
  I think people may be reading this backwards. I am specifically saying don't try as hard. Don't think about unit tests or anything else when writing correct code for a function. Once you can generally write mostly correct code then you can work on improving your process. But, until most of your functions are working when you right them just work on improving that. Edit: And yea quality may drop as part of this transition, but you need to get a feel for how much you can pay attention to.
  - dpark 8y ago
    You’re saying that if you have a problem with code correctness, the solution is to just try harder to write correct code. The tests are there specifically to help find the errors that “trying harder” didn’t catch. You don’t get a higher quality result by cutting QA.
    - Retric 8y ago
      I don't necessarily think he has a problem with code correctness after QA. I think he has a problem with code correctness before QA. You can build a factory that has a Great QA process that finds all faults and corrects them. But, inside the factory you still want to minimize the amount of defects for QA to find. Either way you still need QA, but it's easy to get into the habit of improving QA vs improving the initial process. PS: One exercise I did for a while was every time I found a non syntax bug in a function I just wrote (aka bug at run-time) I would start over and rewrite it. It's painful, but 'Build' wait let's look at this again if I hit run and it does not work that's going to be painful. So is this actually correct? Anyway, doing that showed me how important it was to just focus on the code (and what it means) to exclusion of everything else.