[thegeomaster]

I think you're right. Here's a personal anecdote that leads me to agree with you.

During an internship, I fixed some code style issue in a file that I touched for some unrelated reason. The tests had a blind spot just there, and I didn't manually test after the fix, as it was very minor and I couldn't imagine it causing any problems. But it completely broke the feature, and just testing the most basic user scenario would have revealed the screwup. So the bug made it into staging for a 1.5 MAU web application.

Fortunately, manual QA caught it early on, so no real damage was done, but while I didn't suffer any serious consequences, people definitely let me know that my actions were irresponsible. That's had a lasting impact on me. I often recall this anecdote when I catch myself thinking "no need to test that, it was a small change", and it's saved my ass a couple of times since.

(Of course, better automation is the right way to avoid these kinds of situations, but that's often not attainable in practice due to a number of constraints.)

[gmueckl]

I guess every developer has to have that moment of hubris in their career. I remember checking in a seemingly trivial change, telling everybody that it works - only to get told in return that it wouldn't even compile, let alone work when the syntax was fixed! Oops...

Sure enough, I became much more cautious after that.

[linuxftw]

I don't think your actions were irresponsible. I would assume someone with domain knowledge of the area you changed did a proper code review, especially since you were an intern.

If there's not time to write proper tests for code, there's not time for manual testing either. Testing every line of a code change can burn a lot of your time up.

Additionally, if a seemingly strange way to do something is necessary for proper function, there should have been a comment in the code to explain why it was doing something in such a particular way.