There’s a difference between ” it hasn’t changed because it doesn’t need to be changed” and ” it hasn’t changed because it’s impossible to predict the impact of any change, and no one wants to be responsible for things breaking”.
I was once spelunking a file that hadn't been touched in like 7 years, and there was a weird line where it was adding 2 to the index for seemingly no reason. The comment was like // Sam: not sure why this is off by 2 here. See ticket #12345 for discussion
Whatever issue tracking software it was referencing was no longer used, so that ticket was gone, and who TF is Sam?
And that’s why so many core Linux utilities have worked almost exactly as they did from the very beginning. If your input and output demand no changes, the only improvements left to make are performance.
I've written semi-personal tools that other team members sometimes use that will break in 2100. The comments note this and really hope they aren't still using these by then
I get to say that I've truly made it as a programmer. The reason is that I wrote around 75 lines of Rust, came back a year later, and I could see exactly how it works.
In case you're wondering, it's a command line Slack client for sending notifications. Colored highlights and everything.
I inherited code that contained files that were last updated in 1997
That isn’t a bad thing. On the contrary, according to the open-closed principle, you should strive for writing code you never have to touch again.
There’s a difference between ” it hasn’t changed because it doesn’t need to be changed” and ” it hasn’t changed because it’s impossible to predict the impact of any change, and no one wants to be responsible for things breaking”.
I was once spelunking a file that hadn't been touched in like 7 years, and there was a weird line where it was adding 2 to the index for seemingly no reason. The comment was like
// Sam: not sure why this is off by 2 here. See ticket #12345 for discussionWhatever issue tracking software it was referencing was no longer used, so that ticket was gone, and who TF is Sam?
And that’s why so many core Linux utilities have worked almost exactly as they did from the very beginning. If your input and output demand no changes, the only improvements left to make are performance.
I haven't touched those files. The code works, I don't need to change it. I've mostly been working on the later additions.
Even if it was my code, after 6 years:
“Who the fuck wrote this garbage?! …..oh.”
2019
don’t do this to me
I keep forgetting 2019 is not 1 year ago
Ah yes, the “fuck it, no-one is going to use this” code.
I've written semi-personal tools that other team members sometimes use that will break in 2100. The comments note this and really hope they aren't still using these by then
I mean if it’s worked without modification for 6 years….
I get to say that I've truly made it as a programmer. The reason is that I wrote around 75 lines of Rust, came back a year later, and I could see exactly how it works.
In case you're wondering, it's a command line Slack client for sending notifications. Colored highlights and everything.
“Lmao, who runs mathematically optimized assembly? Let’s get this objective-c rewrite going.”
One title would have been enough.
When you're working on a file that was last updated six years ago
Is that...The 7th Guest?
Can't relate, unless you're editing
.gitignoreorLICENSEfiles for some reason.