3 ms·

People where I work tend to act like their code is going to never be changed later. Like yo, I could rewrite my thing 5 times in the amount of time it took you

People where I work tend to act like their code is going to never be changed later. Like yo, I could rewrite my thing 5 times in the amount of time it took you to build the "generalized" solution that'll probably break anyway. My entire job the past 4 years has been keeping some overengineered thing on life support until its author leaves the team and I nuke/rewrite it, and one of my teammates is like me.

mikojan 4y ago
Where I work you decide whether to produce over-engineered or under-engineered crap prior to writing it and people cannot waste time on a rewrite just because someone left.
- hot_gril 4y ago
  Yeah I've got a lot of luxury here. Used to be in startups where the whole thing can be FUBAR from a mistake like that.
- simmerup 4y ago
  Where I work everyone decides to rewrite everything they inherit and nothing ever gets delivered because the business loses patience and reassigns priorities as the rewrite drags on.
einpoklum 4y ago
> I could rewrite my thing 5 times But in 20 years... 1. It is many people's thing, not your thing. 2. It is inter-dependent with code you can't rewrite 5 times 3. You're probably no longer there anyway. So I'll have the generalized solution, thank you. Of course, it's even better if you can use an already well-established FOSS solution, since that's likely to see improvements over time which may be applicable to your code.
- hot_gril 4y ago
  In 20 years, it's gone, the business requirements are unpredictably different, probably the language I wrote it in is gone too, maybe the entire company as well. I'm writing application code, not a kernel or something, but even kernel pieces have API boundaries and can be replaced. An API can live 20 years, so I take that far more seriously.
- foobarian 4y ago
  > 2. It is inter-dependent with code you can't rewrite 5 times We have a CSV parser library in our codebase. It’s probably from 2005 or so. I’m sure it was a good idea at the time but at this point it has resisted replacement because of dozens of legacy reports that rely on bugs or quirks in it (mostly around quoting).

mikojan 4y ago

Where I work you decide whether to produce over-engineered or under-engineered crap prior to writing it and people cannot waste time on a rewrite just because someone left.

hot_gril 4y ago
Yeah I've got a lot of luxury here. Used to be in startups where the whole thing can be FUBAR from a mistake like that.
simmerup 4y ago
Where I work everyone decides to rewrite everything they inherit and nothing ever gets delivered because the business loses patience and reassigns priorities as the rewrite drags on.

einpoklum 4y ago

> I could rewrite my thing 5 times But in 20 years... 1. It is many people's thing, not your thing. 2. It is inter-dependent with code you can't rewrite 5 times 3. You're probably no longer there anyway. So I'll have the generalized solution, thank you. Of course, it's even better if you can use an already well-established FOSS solution, since that's likely to see improvements over time which may be applicable to your code.

hot_gril 4y ago
In 20 years, it's gone, the business requirements are unpredictably different, probably the language I wrote it in is gone too, maybe the entire company as well. I'm writing application code, not a kernel or something, but even kernel pieces have API boundaries and can be replaced. An API can live 20 years, so I take that far more seriously.
foobarian 4y ago
> 2. It is inter-dependent with code you can't rewrite 5 times We have a CSV parser library in our codebase. It’s probably from 2005 or so. I’m sure it was a good idea at the time but at this point it has resisted replacement because of dozens of legacy reports that rely on bugs or quirks in it (mostly around quoting).