52 ms·

People saying "its on you" and "has your boss ever reviewed the code?" have not had varied enough experiences. Ever had your boss tell you a feature needs to b

by hobs 5y ago

People saying "its on you" and "has your boss ever reviewed the code?" have not had varied enough experiences. Ever had your boss tell you a feature needs to be delivered next week or the business closes? Or that you're fired? I have in fact had my commits gleaned by my boss, told me "no, we're not shipping these 10 lines of code because that goes too far and not what I asked" and then refused to accept the pull request because he had control. Just because YOU have never been in a situation where YOU didn't have control over the creation of technical debt doesn't mean its just some magical thing you can fix and change by saying the right words, don't be naive.

samhw 5y ago
It doesn't even require management to be unreasonable/intransigent/whatever. It's perfectly rational to write a prototype feature in a quick and hacky way, and then invest time in making it clean and extensible after you've validated user demand.
- hobs 5y ago
  For sure! And most of the time I would say spending 20x the time on a thing that you have no flipping idea is going to land is worse than technical debt, its called closing your doors. I just wanted to call out the posters who blame individual eng for the product quality, they've either never worked in a toxic org or are helping be the source!
  - samhw 5y ago
    Ah, yeah, I absolutely agree with you in that case. That's a very fair point. I'm sure there are lots of companies in which context it's not the engineer's decision at all, and therefore not their fault.
- foxfluff 5y ago
  > It doesn't even require management to be unreasonable/intransigent/whatever. It's perfectly rational to write a prototype feature in a quick and hacky way, and then invest time in making it clean and extensible after you've validated user demand. Yeah, you can pass a proof of concept to the customer and they'll ask if it can do one more thing.. and then, tweak this a little.. and add this one little thing.. before you know it, your proof of concept is in production and they just want a little feature here and another there and they're not interested in having it written "properly." Investing time making things clean is a bit tricky if the party you're supposed to bill for that time is not interested and you're not going to invest out of your own pocket.
  - samhw 5y ago
    Yeah, and that's when the complementary skill of knowing when to repay tech debt comes into the picture. I'm not sure what else you would be suggesting: that we should all build every experimental finger-in-the-air MVP as if it were core business-critical functionality, just so we don't have to be disciplined in judging when to repay tech debt?
selfhoster11 5y ago
Exactly. Consistently refusing to take on technical debt may work if you are drowning in demand for your skills and can easily switch. I don't think that's the case in most places outside the Silicon Valley.

by hobs 5y ago

samhw 5y ago

It doesn't even require management to be unreasonable/intransigent/whatever. It's perfectly rational to write a prototype feature in a quick and hacky way, and then invest time in making it clean and extensible after you've validated user demand.

hobs 5y ago
For sure! And most of the time I would say spending 20x the time on a thing that you have no flipping idea is going to land is worse than technical debt, its called closing your doors. I just wanted to call out the posters who blame individual eng for the product quality, they've either never worked in a toxic org or are helping be the source!
- samhw 5y ago
  Ah, yeah, I absolutely agree with you in that case. That's a very fair point. I'm sure there are lots of companies in which context it's not the engineer's decision at all, and therefore not their fault.
foxfluff 5y ago
> It doesn't even require management to be unreasonable/intransigent/whatever. It's perfectly rational to write a prototype feature in a quick and hacky way, and then invest time in making it clean and extensible after you've validated user demand. Yeah, you can pass a proof of concept to the customer and they'll ask if it can do one more thing.. and then, tweak this a little.. and add this one little thing.. before you know it, your proof of concept is in production and they just want a little feature here and another there and they're not interested in having it written "properly." Investing time making things clean is a bit tricky if the party you're supposed to bill for that time is not interested and you're not going to invest out of your own pocket.
- samhw 5y ago
  Yeah, and that's when the complementary skill of knowing when to repay tech debt comes into the picture. I'm not sure what else you would be suggesting: that we should all build every experimental finger-in-the-air MVP as if it were core business-critical functionality, just so we don't have to be disciplined in judging when to repay tech debt?

selfhoster11 5y ago

Exactly. Consistently refusing to take on technical debt may work if you are drowning in demand for your skills and can easily switch. I don't think that's the case in most places outside the Silicon Valley.