3 ms·

Yeah, maybe they don't care about abstraction and beautiful code, but they suddenly start caring when technical debt caused by absence of these things starts to

Yeah, maybe they don't care about abstraction and beautiful code, but they suddenly start caring when technical debt caused by absence of these things starts to hit, but they are too often unable to see that the two are related. In my personal project I spend a huge amount of time tidying things up, abstracting, cleaning, commenting and that has really started to pay off as the project grew. If I'd let it deteriorate into a random bowl of software stew, I have come to a dead end by now, eternally firefighting instead of progressing. > if you aren’t moving the needle economically for the company, you’re a liability yup

rileymat2 2y ago
Yes, many people present a choice between “code quality” and speed, but this choice is false because tickets are not independent. Choices made with the current one affect the speed of the next. Sure you may make a tradeoff between speed and quality in a particular task, but that does not hold over a week or month of work.
mrkeen 2y ago
> If I'd let it deteriorate into a random bowl of software stew, I have come to a dead end by now, eternally firefighting instead of progressing. It's real. It's what I'm doing at work now. Every few months we start a new big project. Sometimes they're business-driven (end users can now have many X instead of one X), sometimes they're compliance-driven (we now need to block users who associate with users in blocked countries), sometimes they're tech-debt-driven (migrate from self-managed VMs into a dedicated provider). We keep finding missing parts we overlooked. Sometimes it's from us having rushed it, other times it's from consultants getting fired while they're working on it, and others struggling to continue the vision in the right direction. Sometimes it's bad tooling - our new managed Kafka host has a mirror-maker tool that doesn't quite mirror properly, or intellij/gradle will flag that a class is missing, but not why (i.e. which dependency is missing!).

rileymat2 2y ago

Yes, many people present a choice between “code quality” and speed, but this choice is false because tickets are not independent. Choices made with the current one affect the speed of the next. Sure you may make a tradeoff between speed and quality in a particular task, but that does not hold over a week or month of work.

mrkeen 2y ago

> If I'd let it deteriorate into a random bowl of software stew, I have come to a dead end by now, eternally firefighting instead of progressing. It's real. It's what I'm doing at work now. Every few months we start a new big project. Sometimes they're business-driven (end users can now have many X instead of one X), sometimes they're compliance-driven (we now need to block users who associate with users in blocked countries), sometimes they're tech-debt-driven (migrate from self-managed VMs into a dedicated provider). We keep finding missing parts we overlooked. Sometimes it's from us having rushed it, other times it's from consultants getting fired while they're working on it, and others struggling to continue the vision in the right direction. Sometimes it's bad tooling - our new managed Kafka host has a mirror-maker tool that doesn't quite mirror properly, or intellij/gradle will flag that a class is missing, but not why (i.e. which dependency is missing!).