Not sure really. Probably a combination of habit and a belief that you should try to fully understand the code you're working on before you change it. I think I trust my gut more readily than assuming someone got the tests right and didn't miss anything. Almost all of the time I understand the implications of what I've changed, and know exactly what few little things I need to check still work - and I usually have devised my own ways of checking those. The times when I don't fully understand the implications, I use as opportunity to further my understanding of the system by looking into it in more detail - or discussing it (if possible) with whoever wrote it.
The extra layer of automated testing just feels like extra work for no real benefit. Development over the time I've been doing it seems to have added many layers of tooling to make things 'easier' for developers, whilst at the same time distancing them more and more from a direct "hand's on" approach to working with, and understanding the code.
My take on this probably also stems from mainly having worked solo or in very small teams throughout my professional development experience. I'm also entirely self taught, and have probably gotten used to figuring out my own way of doing things. To this day, I still much prefer writing the code for as many things as possible - deferring to libraries only when absolutely necessary. Slower maybe, but a massive sense that you've actually built something rather than just joined together some pieces of other people's work. Yes, I know if you take that to it's logical conclusion I should be building my own hardware, writing my own OS etc.... and I obviously don't do that, but I prefer to feel like an architect rather than a bricklayer where possible
That makes sense, thanks for taking the time to explain it! I find these conversations fascinating.
I totally get your points, and have felt that way for many years. I've just started using tests over the last 2 years or so. And I still only use them at work (mostly), on personal projects I don't usually use them. I prefer your approach, as it feels more fun, and allows me to focus on the tasks at hand. This, as you say, makes you have a really good understanding of the project and the consequences of changing something.
I think I trust my gut more readily than assuming someone got the tests right and didn't miss anything
That's a really good point, tests can sometimes be deceiving, they make you feel so safe you might not even think about the consequences of performing a change (just because there are tests).
Again, thanks for the response!
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.
Not sure really. Probably a combination of habit and a belief that you should try to fully understand the code you're working on before you change it. I think I trust my gut more readily than assuming someone got the tests right and didn't miss anything. Almost all of the time I understand the implications of what I've changed, and know exactly what few little things I need to check still work - and I usually have devised my own ways of checking those. The times when I don't fully understand the implications, I use as opportunity to further my understanding of the system by looking into it in more detail - or discussing it (if possible) with whoever wrote it.
The extra layer of automated testing just feels like extra work for no real benefit. Development over the time I've been doing it seems to have added many layers of tooling to make things 'easier' for developers, whilst at the same time distancing them more and more from a direct "hand's on" approach to working with, and understanding the code.
My take on this probably also stems from mainly having worked solo or in very small teams throughout my professional development experience. I'm also entirely self taught, and have probably gotten used to figuring out my own way of doing things. To this day, I still much prefer writing the code for as many things as possible - deferring to libraries only when absolutely necessary. Slower maybe, but a massive sense that you've actually built something rather than just joined together some pieces of other people's work. Yes, I know if you take that to it's logical conclusion I should be building my own hardware, writing my own OS etc.... and I obviously don't do that, but I prefer to feel like an architect rather than a bricklayer where possible
That makes sense, thanks for taking the time to explain it! I find these conversations fascinating.
I totally get your points, and have felt that way for many years. I've just started using tests over the last 2 years or so. And I still only use them at work (mostly), on personal projects I don't usually use them. I prefer your approach, as it feels more fun, and allows me to focus on the tasks at hand. This, as you say, makes you have a really good understanding of the project and the consequences of changing something.
That's a really good point, tests can sometimes be deceiving, they make you feel so safe you might not even think about the consequences of performing a change (just because there are tests).
Again, thanks for the response!