I think you briefly touched on the idea, but I want to share one of the things I do in personal projects that the company I work for has started at my recommendation. When we are working in the code base and see something strange, have to do something strange because of how the code is, or take a shortcut due to time or mental bandwidth constraints, we make an issue in our repo and label it tech debt. It's nice as it gives a list of things to work on later and we don't allow iffy code in through PRs if the person doesn't make a ticket for the tech debt.
This helps us uncover the existing tech debt, as well as not blindly adding more in(I'm sure we add stuff due to general incompetence, not everyone knows everything).
One other minor thing I want to say on the 4 types of tech debt is there's a slight variant where you make the decision to let it in because you mentally just cannot work on the branch any more but you want it in the codebase now so it won't get stale. I find it happens to me a lot on personal projects where I just want to move on to the next part of building my cool new idea. :P
We have a few projects that are at or teetering on the idea of technical bankruptcy so these kinds of strategies from the article help a lot! Thanks for writing about this! I feel we need more of these kinds of articles on dev.to as nice and helpful as the low level intro to programming ones are for a lot of people.
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.
Brilliant. Wonderful article.
I think you briefly touched on the idea, but I want to share one of the things I do in personal projects that the company I work for has started at my recommendation. When we are working in the code base and see something strange, have to do something strange because of how the code is, or take a shortcut due to time or mental bandwidth constraints, we make an issue in our repo and label it tech debt. It's nice as it gives a list of things to work on later and we don't allow iffy code in through PRs if the person doesn't make a ticket for the tech debt.
This helps us uncover the existing tech debt, as well as not blindly adding more in(I'm sure we add stuff due to general incompetence, not everyone knows everything).
One other minor thing I want to say on the 4 types of tech debt is there's a slight variant where you make the decision to let it in because you mentally just cannot work on the branch any more but you want it in the codebase now so it won't get stale. I find it happens to me a lot on personal projects where I just want to move on to the next part of building my cool new idea. :P
We have a few projects that are at or teetering on the idea of technical bankruptcy so these kinds of strategies from the article help a lot! Thanks for writing about this! I feel we need more of these kinds of articles on dev.to as nice and helpful as the low level intro to programming ones are for a lot of people.