Thanks for reading and for leaving a comment!

Comments in source code doesn't work as well as one might hope; nobody wants to try to keep comments up-to-date after the fact. I believe code should be self-documenting: do a solid job of naming classes, methods, and variables, and you'll be better off.

To a degree, I agree with you. However, I still find usefulness in sparse comments that explain why something unintuitive was done the way it was, often linking to external resources like relevant bugs in third-party libraries or services, the language itself, etc.

I also have to disagree with, "put low-level requirements in ticketing systems."

Again, in general, I agree. However, it depends on the nature of the work being done and who's writing the requirements. As an example, my workplace recent began a large-scale effort to cull some of our technical debt. The developers are the better people to write requirements in that instance because they're familiar with the nature of the debt and the best way to go about resolving it. I suspect this also varies on a more general basis from company to company; some may put high-level requirements in requirements documents and lower-level requirements in ticketing systems.