I find this very interesting. Did you ever work on a big project? I don't understand how you can maintain the quality without automated testing on a big project. Very curious, please share :)
I've worked on plenty of big projects. It's my honest opinion that you do better work if you fully (or as close to fully as is possible) understand the code you are working with, and understand the implications of any changes you are making.
If you are writing new code, then this understanding is obviously almost instant as you will (presumably) know what your code is doing. If you are working with old or unfamiliar code, then I always find the best thing is to familiarise yourself with that code completely before working on it - noting the places where it is used etc. - so you'll know what you need to test when you make your changes.
I feel this approach results in having developers with a far greater understanding of project code than they would have by relying on tests (which may or may not be up to date, and are a level removed from real-world use - so knowledge gleaned from reading them is often incomplete or somewhat disembodied). Working without tests means your understanding of the code you are working with is always fresh and up to date, and you gradually acquire a deeper understanding of more and more parts of a large project. The more you understand in the code, the better you become at working with it.
For me, relying on automated tests takes away a lot of the opportunity to build a deep understanding of a project.
Yes, this method may be slower sometimes... but it has always worked very well for me.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I find this very interesting. Did you ever work on a big project? I don't understand how you can maintain the quality without automated testing on a big project. Very curious, please share :)
I've worked on plenty of big projects. It's my honest opinion that you do better work if you fully (or as close to fully as is possible) understand the code you are working with, and understand the implications of any changes you are making.
If you are writing new code, then this understanding is obviously almost instant as you will (presumably) know what your code is doing. If you are working with old or unfamiliar code, then I always find the best thing is to familiarise yourself with that code completely before working on it - noting the places where it is used etc. - so you'll know what you need to test when you make your changes.
I feel this approach results in having developers with a far greater understanding of project code than they would have by relying on tests (which may or may not be up to date, and are a level removed from real-world use - so knowledge gleaned from reading them is often incomplete or somewhat disembodied). Working without tests means your understanding of the code you are working with is always fresh and up to date, and you gradually acquire a deeper understanding of more and more parts of a large project. The more you understand in the code, the better you become at working with it.
For me, relying on automated tests takes away a lot of the opportunity to build a deep understanding of a project.
Yes, this method may be slower sometimes... but it has always worked very well for me.