Tech debt

Tech debt is similar to credit cards, if you use it wisely, you can leverage the same resource [fixed engineering resource] to achieve bigger results in the short term. But similar to a credit card, you need to have a strategy to pay that back.

In the workplace, the tech debt is shared by the team

It is your financial issue to pay back your credit cards. Interestingly, in the tech workplace, people who make the debt are usually NOT the people who pay for the debt! It means your tech debt is shared by the team, if the team is great and disciplined [only make the debt when it is necessary], then tech debt is fine as long as you repay that on time. But the most annoying part is when people are not disciplined and keep making the debt, and they also don’t plan to pay that back. Instead, they will just quit and leave the debt to others right before things are out of control.

In the end, someone gets the credits and leaves the whole & future team to pay that back, which I think isn’t ethical.

Solutions

If it is a prototype, dirty & quick is fine, as long as it is just a demo.

If it is for long-term use, involves long-lasting pipelines & complex logic, then design and code review are required to maintain things above a certain standard.

It requires discipline, it requires thinking, and it is not the most comfortable approach. But for the healthy growth of the project/product, it is necessary.

At the very least, given a reasonable timeline and resources, the codebase should be improved with every new PR.

If you don’t have such fortunate, then please, at the very least leave a BIG TODO flag with reasons and explanations. Also, organize the code in a way that you or other people can rewrite easily in the future [functions, no hardcodes, reasonable naming, comments next to non-trivial things, write one or two unit tests for the happy flow]. These things can have 10x+ ROI easily in terms of time.