5 ms·

Your #1 is so true. The lesson I learned was that the guy who was there before me almost always developed what he did under the gun and took on technical debt

Your #1 is so true. The lesson I learned was that the guy who was there before me almost always developed what he did under the gun and took on technical debt to make it happen. Now I just put a mental crosshair on the code I want changed and come back to it.

fhood 9y ago
Ditto. Not only that, but when working with a large codebase, design decisions that seem unfathomable at first glance often turn out to be reasonable or necessary once you understand the code and its use cases.
fwdpropaganda 9y ago
#1 might be common, but surely is symptomatic of something negative. Like fragile egos.
TearsInTheRain 9y ago
Cmd + f TODO :shudder:
- Clubber 9y ago
  Hah. And that's probably only 10% of what really needs to be done.
0xdeadbeefbabe 9y ago
But "technical debt" may also means he didn't do it in your preferred way. This double meaning really bothers me. It's like technical debt.
- hinkley 9y ago
  I’ve become more aware (again?) lately of the differences between ugly code and debtful code. When hunting down a bug in bad code every method you read becomes a honey trap. It could be here, so you have to stop and grok this messy pile and that mental gymnastics removes parts of the todo list from your working memory. You pingpng around and when you find the problem you can’t remember why you were looking for it. Then there’s code where you say “ugh”, take a breath and keep going. If the smell doesn’t rise to the point of potential confusion about the purpose or goals of the code, if it’s a small inefficiency you can’t (yet) spot in the flame charts, then move on to bigger issues. That said, I’ve paired to debug with people who defend their bad variable naming choices and the source of their problem was that their own code (and bad naming) confused them. You make them rename and they see the problem immediately.
  - 0xdeadbeefbabe 9y ago
    They aren't just giving in to your tastes?
    - hinkley 9y ago
      There are so many things that could go wrong in delivering a piece of code. Just the ones I've seen enough times to build rules of thumb about exceeds my own powers of recall. And some people reliably trip over certain failure modes, while others avoid them subconsciously, never even realizing there was a hazard to begin with. My new motto is: filter out the reversible decisions and worry about the rest. When something in the former set breaks, make it a teachable moment.
  - Terr_ 9y ago
    The idiom that always comes to mind for me is "good fences make good neighbors." In the long run ugly lines of code are so much better than a broken architecture or too much coupling.
    - hinkley 9y ago
      True. If the blast radius is small it only matters if you see the same three lines of code in twenty places.
- bg4 9y ago
  Yes, one must be able to discern between technical debt and taste.
hinkley 9y ago
I think people mistake the source of frustration. It’s not that the other guy took on tech debt. It’s that he kept saying “we’ll fix that later” and never did. Corner cutting isn’t fatal. Often it’s not even all that painful, if I’m perfectly honest. It’s the delusion that hurts.
- rpeden 9y ago
  In my experience, the person adding the technical debt usually had every intention of going back to fix it, but they were never given the time to actually do it. :)
  - hinkley 9y ago
    The road to hell is paved with good intentions. That's the delusional part of the problem. You won't look at it because admitting you have a problem is the hardest part. "I'll do it later." is the primary failure mode we have for personal improvement across just about everything. Diet, personal finance, interpersonal relationships. There's a whole category of aphorisms dedicated to this. Nobody is going to schedule time for integrity on the project roadmap. That's not how integrity works. You can find some or lose some, but on any given day you have it or you don't.
frugalmail 9y ago
technical debt is not always a "bad thing". Sometimes it makes sense to rapidly iterate until you understand what it is that needs to live on. If the risk for not getting the code out exceeds the risk for whatever technical metric is going to be improved by addressing the technical debt, then by all means iterate.
- Coincoin 9y ago
  For instance, there is no point in refactoring a piece of code that never needs maintenance. In that case it is good debt and it already paid off.
- kazinator 9y ago
  If technical interest rates are dirt low on your technical debt, go into technical debt. :)
  - wolco 9y ago
    Loved how that was framed. I'm going to start assessing the interest rate. Which to me is the interest leadership has on fixing vs new features.
    - kazinator 9y ago
      Or, to stick with the analogy more closely; what is interest? It's the cost of servicing a debt. Technical debt has a low cost to the extent that it Just Works. If it has to be constantly propped up, then it's high interest.
criddell 9y ago
> The lesson I learned was that the guy who was there before me almost always developed what he did under the gun and took on technical debt to make it happen. The number of times I've spotted some terrible bit of code then go through the version control system to try to find out more of why that moron did what he did only to discover that I wrote the code is embarrassingly large.

fhood 9y ago

Ditto. Not only that, but when working with a large codebase, design decisions that seem unfathomable at first glance often turn out to be reasonable or necessary once you understand the code and its use cases.

fwdpropaganda 9y ago

#1 might be common, but surely is symptomatic of something negative. Like fragile egos.

TearsInTheRain 9y ago

Cmd + f TODO :shudder:

Clubber 9y ago
Hah. And that's probably only 10% of what really needs to be done.

0xdeadbeefbabe 9y ago

But "technical debt" may also means he didn't do it in your preferred way. This double meaning really bothers me. It's like technical debt.

hinkley 9y ago
I’ve become more aware (again?) lately of the differences between ugly code and debtful code. When hunting down a bug in bad code every method you read becomes a honey trap. It could be here, so you have to stop and grok this messy pile and that mental gymnastics removes parts of the todo list from your working memory. You pingpng around and when you find the problem you can’t remember why you were looking for it. Then there’s code where you say “ugh”, take a breath and keep going. If the smell doesn’t rise to the point of potential confusion about the purpose or goals of the code, if it’s a small inefficiency you can’t (yet) spot in the flame charts, then move on to bigger issues. That said, I’ve paired to debug with people who defend their bad variable naming choices and the source of their problem was that their own code (and bad naming) confused them. You make them rename and they see the problem immediately.
- 0xdeadbeefbabe 9y ago
  They aren't just giving in to your tastes?
  - hinkley 9y ago
    There are so many things that could go wrong in delivering a piece of code. Just the ones I've seen enough times to build rules of thumb about exceeds my own powers of recall. And some people reliably trip over certain failure modes, while others avoid them subconsciously, never even realizing there was a hazard to begin with. My new motto is: filter out the reversible decisions and worry about the rest. When something in the former set breaks, make it a teachable moment.
- Terr_ 9y ago
  The idiom that always comes to mind for me is "good fences make good neighbors." In the long run ugly lines of code are so much better than a broken architecture or too much coupling.
  - hinkley 9y ago
    True. If the blast radius is small it only matters if you see the same three lines of code in twenty places.
bg4 9y ago
Yes, one must be able to discern between technical debt and taste.

hinkley 9y ago

I think people mistake the source of frustration. It’s not that the other guy took on tech debt. It’s that he kept saying “we’ll fix that later” and never did. Corner cutting isn’t fatal. Often it’s not even all that painful, if I’m perfectly honest. It’s the delusion that hurts.

rpeden 9y ago
In my experience, the person adding the technical debt usually had every intention of going back to fix it, but they were never given the time to actually do it. :)
- hinkley 9y ago
  The road to hell is paved with good intentions. That's the delusional part of the problem. You won't look at it because admitting you have a problem is the hardest part. "I'll do it later." is the primary failure mode we have for personal improvement across just about everything. Diet, personal finance, interpersonal relationships. There's a whole category of aphorisms dedicated to this. Nobody is going to schedule time for integrity on the project roadmap. That's not how integrity works. You can find some or lose some, but on any given day you have it or you don't.

frugalmail 9y ago

technical debt is not always a "bad thing". Sometimes it makes sense to rapidly iterate until you understand what it is that needs to live on. If the risk for not getting the code out exceeds the risk for whatever technical metric is going to be improved by addressing the technical debt, then by all means iterate.

Coincoin 9y ago
For instance, there is no point in refactoring a piece of code that never needs maintenance. In that case it is good debt and it already paid off.
kazinator 9y ago
If technical interest rates are dirt low on your technical debt, go into technical debt. :)
- wolco 9y ago
  Loved how that was framed. I'm going to start assessing the interest rate. Which to me is the interest leadership has on fixing vs new features.
  - kazinator 9y ago
    Or, to stick with the analogy more closely; what is interest? It's the cost of servicing a debt. Technical debt has a low cost to the extent that it Just Works. If it has to be constantly propped up, then it's high interest.

criddell 9y ago

> The lesson I learned was that the guy who was there before me almost always developed what he did under the gun and took on technical debt to make it happen. The number of times I've spotted some terrible bit of code then go through the version control system to try to find out more of why that moron did what he did only to discover that I wrote the code is embarrassingly large.