3 ms·

To be fair though: "That code is horrible! Who the hell wrote this?!" git blames sees their own name Isn't that an experience everybody makes? For me it was

by Bewelge 2mo ago

To be fair though: "That code is horrible! Who the hell wrote this?!" git blames sees their own name Isn't that an experience everybody makes? For me it was like a year into working professionally. And I feel it's part of being a professional to know that you're not going to remember it in the long term and therefore provide proper documentation of why you did what.

Nextgrid 2mo ago
I am talking more about the knowledge of the code rather than an objective/subjective measure of code "quality". Code might be bad by some objective/subjective measure, but if you (or the author) can understand, navigate and work on it, that's often better than good quality code that nobody understands because it was written by an agent, especially under the time pressure of an ongoing incident where you need to fix it now. Even if the good code is easy to understand, you still need to read it and take it in, something you don't need to do because you got it implicitly by writing said code. > to know that you're not going to remember it in the long term From my personal experience, while I will not remember code character by character, a quick look is all it takes to refresh my memory and get the general gist of it and what the context was at the time, something I don't have if I'm reading someone else's (or an agent's) code.
thesz 2mo ago
git blames sees their own name Isn't that an experience everybody makes? Our fearless leader once did clang-assisted formatting of all of our code. Wherever we look with git blame, we see his name. Of course, we change code, etc, but for some year and a half it was fun. (to actually go to the specific commit that authored the code I skip two specific revisions, both are formatting changes) So you seeing your name next to the code you do not like can be an indentation change due to adding condition or something like that.

by Bewelge 2mo ago

Nextgrid 2mo ago

I am talking more about the knowledge of the code rather than an objective/subjective measure of code "quality". Code might be bad by some objective/subjective measure, but if you (or the author) can understand, navigate and work on it, that's often better than good quality code that nobody understands because it was written by an agent, especially under the time pressure of an ongoing incident where you need to fix it now. Even if the good code is easy to understand, you still need to read it and take it in, something you don't need to do because you got it implicitly by writing said code. > to know that you're not going to remember it in the long term From my personal experience, while I will not remember code character by character, a quick look is all it takes to refresh my memory and get the general gist of it and what the context was at the time, something I don't have if I'm reading someone else's (or an agent's) code.

thesz 2mo ago

git blames sees their own name Isn't that an experience everybody makes? Our fearless leader once did clang-assisted formatting of all of our code. Wherever we look with git blame, we see his name. Of course, we change code, etc, but for some year and a half it was fun. (to actually go to the specific commit that authored the code I skip two specific revisions, both are formatting changes) So you seeing your name next to the code you do not like can be an indentation change due to adding condition or something like that.