Technical debt is similar to real life debt:

1) Pay all your debt now, unless you have a sure way to make money at a higher interest rate CONSIDERING INFLATION (ie if you hold debt at a fixed 2% annual rate and can access 3% guaranteed placement, don't pay your debts if inflation is <1%)

2) Never make any debt ever again UNLESS it is for a productive investment. A productive investment is something that will pay the amount due + interest + leave you something to leave on. Physicial capital (tools) is an investment. Today you must have a really good reason to buy your own server instead of paying-as-you-go for a virtual server. Education may - or may not be, it 's a complex question (credentialing may mean you need paper diplomas more than the actual knowledge)

3) Leave beyond your expenses, save and invest. There're various websites with suggestions on how to do that exactly.

The most important thing is the endgoal : no debt, money in the bank, freedom to work on jobs or projects you value, without the short term constraints of putting food on the table.

When in doubt about making a debt, go see 2) - purchasing property to flip it on the market is taking a risk. If you have followed 3), it's a risk you can take.

Now let's translate that to development debt :

1) you should fix your code now, unless there are more productive uses of your time. Fixing old complex code is like fighting inflation - don't bother. You may win some battle but can't win the war. Fixing new code however is a good idea, while it's still clear in your head.

2) you shouldn't have made a technical debt in the first place, except to ensure a sale or quick money. if you did, you'd rather have a good reason and some profits to show

3) code in a "beginner me could understand that" way. Remember it takes someone twice as intelligent to debug some code, so make life easy for yourself.

The end goal is the same : code that work, with the freedom to repurpose it, without the short term hassle of fighting bugs everyday.

When in doubt about creating technical debt, go see 2) - feature creep to try to secure a sale is taking a risk. If you have followed 3) and your code base is clean enough, it's a risk you can take.

EDIT : Downvotes, really? At -1 now ?? Please tell me how I am not following the guidelines and not contributing to the discussion.

EDIT2: falcolas, sorry, but I see technical debt just like real life debt. It is a powerful and dangerous tool, and if one is looking for solutions on a blog where a guy advise playing around for the fun of it you're not doing to lower your technical debt - you're going deeper into technical debt.

In his own works : "hacking debt" : "Some portion of a career should be devoted to hacking. Not 100%, but not 0% either. Without some time spent exploring and having fun, people become less effective and eventually burn out.".

Huh? "hacking debt" won't resolve the "technical debt" - that's completely unrelated. I just don't and can't agree with his approach of playtime for the sake of it. One should remember the dead simple advice posted above (and heavily downvoted) before trying to do better. Not everyone is a rockstar or a special gem needing daily bouts of playtime to keep inspiration. Most however need to keep a training routine and consider which technical debt is worth taking on, and which is worth leaving aline.

BTW, as I posted 2 weeks ago (https://news.ycombinator.com/item?id=5508906) :

"Take a military analogy - if you're not doing something "shippable" (ex: fighting), you are training to maintain or raise your potential for when you will have to get in action - or at least to maintain discipline."

That's not playing for the sake of playing or having fun. That's playing with a goal.