i want smaller applications with fewer updates made by people who are paid more to produce less code and i'm not kidding
-
i want smaller applications with fewer updates made by people who are paid more to produce less code and i'm not kidding
-
i want smaller applications with fewer updates made by people who are paid more to produce less code and i'm not kidding
-
i want smaller applications with fewer updates made by people who are paid more to produce less code and i'm not kidding
-
i want smaller applications with fewer updates made by people who are paid more to produce less code and i'm not kidding
@eniko Same, and also not kidding. I would rather have a group of three or four well-compensated maintainers who know the codebase very well (+ newer contributors they can afford to & have time to help teach/train) releasing security and bug fixes, with, maybe *one* feature release every year or two and a clear 'it's done'/feature complete state after which it's just bug fixes and maintenence/porting.
-
@eniko Same, and also not kidding. I would rather have a group of three or four well-compensated maintainers who know the codebase very well (+ newer contributors they can afford to & have time to help teach/train) releasing security and bug fixes, with, maybe *one* feature release every year or two and a clear 'it's done'/feature complete state after which it's just bug fixes and maintenence/porting.
@eniko (Early on - like in alpha, when it's not even close to feature complete, then more feature updates is fine - but if at any point it hits a "Stable" release, I want that shit to be ACTUALLY stable - which means new features come slowly, and the priority is keeping it functional and reliable.)
-
@eniko That, and also I'd want internet-connected applications out of things where they have no sane reason to be.
-
-
i want smaller applications with fewer updates made by people who are paid more to produce less code and i'm not kidding
-
@eniko Same, and also not kidding. I would rather have a group of three or four well-compensated maintainers who know the codebase very well (+ newer contributors they can afford to & have time to help teach/train) releasing security and bug fixes, with, maybe *one* feature release every year or two and a clear 'it's done'/feature complete state after which it's just bug fixes and maintenence/porting.
@miss_rodent @eniko You want ANATHEM. It’s okay. I would prefer ANATHEM over whatever hellscape this is.
-
@miss_rodent @eniko You want ANATHEM. It’s okay. I would prefer ANATHEM over whatever hellscape this is.
-
i want smaller applications with fewer updates made by people who are paid more to produce less code and i'm not kidding
-
i want smaller applications with fewer updates made by people who are paid more to produce less code and i'm not kidding
-
i want smaller applications with fewer updates made by people who are paid more to produce less code and i'm not kidding
@eniko But then the boss would have fewer people to manage, and be unable to justify his job. Most software changes are about employment for engineers, not necessity. Grr.
As a software engineer I want computer languages and frameworks that stay stable for decades rather than have a new release every year that obsoletes old programs and requires a rewrite. But I don't get to have that :(.
-
@eniko But then the boss would have fewer people to manage, and be unable to justify his job. Most software changes are about employment for engineers, not necessity. Grr.
As a software engineer I want computer languages and frameworks that stay stable for decades rather than have a new release every year that obsoletes old programs and requires a rewrite. But I don't get to have that :(.
-
-
i want smaller applications with fewer updates made by people who are paid more to produce less code and i'm not kidding
-
i want smaller applications with fewer updates made by people who are paid more to produce less code and i'm not kidding
-
@badtux @eniko I actually had to re-write large chunks of a program I wrote for a client because Haskell's ncurses wrapper just kind of... stopped being a thing.
Fortunately, I never liked ncurses to begin with and had abstracted much of it away. The code I'd written was fairly easy to retrofit into brick instead.
-
i want smaller applications with fewer updates made by people who are paid more to produce less code and i'm not kidding
-
i want smaller applications with fewer updates made by people who are paid more to produce less code and i'm not kidding
@eniko Product: What's this ticket for, this one you're working on, it doesn't seen to be delivering any new feature? Why are we doing it?
Devs: It lets us delete a couple of thousand lines of no-longer-used code. Which will then no longer need to be maintained, tested, documented, ect ect.
Product: Great! That's what we like to hear!
