From humble beginnings at an MSP, I've adventured through life as a sysadmin, into an engineer, and finally landed as a developer focused on fixing problems with automation.
Fair point, usually bad code equals to technical debt. Still, it is more than nothing at all and you can use it as some kind of primal spec or starting point.
Regarding the quote, the context is how pointless is to complain or blame the author. It is not uncommon at all to go to the commit introducing the changes and find out the author is... yourself.
From humble beginnings at an MSP, I've adventured through life as a sysadmin, into an engineer, and finally landed as a developer focused on fixing problems with automation.
I've found that usually the context is inexperience or rushed timelines. Those do not make the bad code "valuable", they make it technical debt.
I'd argue this is a bad thing.
Fair point, usually bad code equals to technical debt. Still, it is more than nothing at all and you can use it as some kind of primal spec or starting point.
Regarding the quote, the context is how pointless is to complain or blame the author. It is not uncommon at all to go to the commit introducing the changes and find out the author is... yourself.
Thanks for the comments!
Fully agree. It is toxic to do so and leads to tensions in a new workplace (especially if the author was liked or still employed there!)