4 ms·

> Amateur software developers dislike (...) I think that's wrong way to put it. I think the difference between pro and amateur might be, even if both dislike s

> Amateur software developers dislike (...) I think that's wrong way to put it. I think the difference between pro and amateur might be, even if both dislike something, pro will understand he needs to do it properly anyway and why. For example, I dislike writing unit tests. In many years there has not been a single time the unit test saved me from anything. I tend to be very pedantic when writing code extremely careful when modifying code written by other people. I don't rely on tests to tell me I have messed something because I know these tests written by a person with lesser work ethics cannot be trusted. So before I modify anything I do thorough investigation to understand what I am modifying, what my modification can possibly cause and whether it is not a problem. If unit tests were done correctly (ie. up to the standard that would let me trust them) then yes, they would be helpful. But it requires only a single developer on the project, even one that has already departed, and you can no longer just trust tests to catch a problem. Also I am yet to see well tested code -- one that documents and thoroughly proves all detectable aspects of unit contract. So I understand I am paying the price for other people not making tests correctly but I still have to write them nonetheless. I hope you understand why I can BOTH dislike it and be professional about it, at the same time.

Nursie 6y ago
> In many years there has not been a single time the unit test saved me from anything. You've never even made a typo that a unit test has helped you spot? You've never, ever, had a unit test show you that one of the assumptions was wrong that you made about the behaviour of a piece of third party code? That seems mighty unusual to me...
- lmilcin 6y ago
  As I said, I try to always thoroughly understand anything I am about to modify. For example, if I change a function body I always familiarize myself with how the function is being used, exactly, what the code of the function does, exactly and how other function it calls work, exactly.
  - aYsY4dDQ2NrcNzA 6y ago
    I think I understand where you’re coming from, but let me ask something: when there are bugs found in your code, due to subtle implications of the design or whatnot, are you ever tempted to add a unit test to check that this situation doesn’t return?
  - Nursie 6y ago
    I’m afraid I find this somewhat unlikely, or if you are genuinely not only this careful but this fault-less, can only imagine you progress at a very slow pace. Do you not consider unit tests useful because they might help others understand and catch changes to the implicit contracts in your own code?
    - lmilcin 6y ago
      It has always been amazing to me that almost all developers are convinced that it is not possible to write programs that work on the first try. This is as silly as stating that you need to build at least couple skyscrapers that fall before one that can stand up and can be occupied. It is not at all difficult. Instead of spending my entire career writing couple of lines of code and then running it, to see if it works (which is training at being perpetually newb at programming), I spent it learning to write longer and longer pieces of code that I understand exactly what they are going to do and that work on the first try. I can work weeks writing thousands of lines of complex code and have very good chance that the effect will be working code that needs no corrections. Do I make silly mistakes? Sure I do. But I then try to figure how it happened and how to make sure I don't make those kinds of blunders in the future. I also try to design the modules in such a way that it is not possible to misuse them (well, at least requires malicious intent or gross incompetence). You see, unit tests reward people who break a lot, not people who put a lot of effort into not breaking things. I prefer to focus my efforts into not breaking things in the first place. I wish this was more popular: https://en.wikipedia.org/wiki/Personal_software_process https://en.wikipedia.org/wiki/Personal_software_process
      - Nursie 6y ago
        I’m afraid I would not hire someone with that sort of outlook, nor do I believe that you could reliably produce software at any great speed that way. Unit tests show you that the code does what it’s supposed to. Without them you haven’t demonstrated that, just asserted it, nor have you left a system that can be picked up by others with a reasonable expectation that if something does break, it will be caught.

Nursie 6y ago

> In many years there has not been a single time the unit test saved me from anything. You've never even made a typo that a unit test has helped you spot? You've never, ever, had a unit test show you that one of the assumptions was wrong that you made about the behaviour of a piece of third party code? That seems mighty unusual to me...

lmilcin 6y ago
As I said, I try to always thoroughly understand anything I am about to modify. For example, if I change a function body I always familiarize myself with how the function is being used, exactly, what the code of the function does, exactly and how other function it calls work, exactly.
- aYsY4dDQ2NrcNzA 6y ago
  I think I understand where you’re coming from, but let me ask something: when there are bugs found in your code, due to subtle implications of the design or whatnot, are you ever tempted to add a unit test to check that this situation doesn’t return?
- Nursie 6y ago
  I’m afraid I find this somewhat unlikely, or if you are genuinely not only this careful but this fault-less, can only imagine you progress at a very slow pace. Do you not consider unit tests useful because they might help others understand and catch changes to the implicit contracts in your own code?
  - lmilcin 6y ago
    It has always been amazing to me that almost all developers are convinced that it is not possible to write programs that work on the first try. This is as silly as stating that you need to build at least couple skyscrapers that fall before one that can stand up and can be occupied. It is not at all difficult. Instead of spending my entire career writing couple of lines of code and then running it, to see if it works (which is training at being perpetually newb at programming), I spent it learning to write longer and longer pieces of code that I understand exactly what they are going to do and that work on the first try. I can work weeks writing thousands of lines of complex code and have very good chance that the effect will be working code that needs no corrections. Do I make silly mistakes? Sure I do. But I then try to figure how it happened and how to make sure I don't make those kinds of blunders in the future. I also try to design the modules in such a way that it is not possible to misuse them (well, at least requires malicious intent or gross incompetence). You see, unit tests reward people who break a lot, not people who put a lot of effort into not breaking things. I prefer to focus my efforts into not breaking things in the first place. I wish this was more popular: https://en.wikipedia.org/wiki/Personal_software_process https://en.wikipedia.org/wiki/Personal_software_process
    - Nursie 6y ago
      I’m afraid I would not hire someone with that sort of outlook, nor do I believe that you could reliably produce software at any great speed that way. Unit tests show you that the code does what it’s supposed to. Without them you haven’t demonstrated that, just asserted it, nor have you left a system that can be picked up by others with a reasonable expectation that if something does break, it will be caught.