[deleted]
Who wrote this shit?
211–220 of 300 posts
Re: Who wrote this shit?
#212> Who wrote this shit?
In both my personal and professional lives, when this comes up or I have the thought, way too often the answer is:
I did.
Re: Who wrote this shit?
#213When I was the first engineer at one job my manager (who joined after I did) anticipated others saying this kind of thing about me, and told me to always remember that "the reason any of us engineers have jobs is because of your code".
It's a good reminder, and I appreciate others taking care to build others up.
Re: Who wrote this shit?
#214Many people in this thread are saying they are surprised by their own shitty code, 6 month ago. I read this everywhere on the Web. It's like I should myself be finding my code from 6 months ago horrible. I don't know. I tend to remember what code I wrote, and recognize my own code when seeing it, even years later. My code from 6 months ago looks good to me. My code from 10 years ago looks "reasonable, if a bit messy"…
If I felt my code from a year ago was still good, I'd be worried I've stopped learning and growing.
I still don't get this. Not knowing everything I've learned for the past year did not prevent me to write clear code back then. I hope I'm writing better code now because I actively reflect on how to write correctly, but that does not prevent my old code to be reasonable.
If I found my code from a year ago bad despite all these years of programming, I'd be worried I'm not in fact any good. The whole point of taking care to write good code is that it will still be readable and maintainable (i.e., good) in a year and more, and I'm sure I can achieve this, and could back then.
I'm also able to recognize good code from other people from years ago, if I systematically thought my code from one year ago was bad, that would mean I'm consistently bad too.
It just does not compute.
Re: Who wrote this shit?
#215Earlier quoted context omitted.
If I felt my code from a year ago was still good, I'd be worried I've stopped learning and growing.
I still don't get this. Not knowing everything I've learned for the past year did not prevent me to write clear code back then. I hope I'm writing better code now because I actively reflect on how to write correctly, but that does not prevent my old code to be reasonable. If I found my code from a year ago bad despite all these years of programming, I'd be worried I'm not in fact any good. The whole point of taking c…
I was "not any good" relative to how much better I am now. I'm happy and fortunate that trajectory is continuing. Thirteen years and counting, in fact.
Who knows, maybe you're a better coder than I am and you just "got" it instantly! It's immensely important for me to keep growing, so I guess it's a good thing I may be so much worse than you?
Re: Who wrote this shit?
#216Earlier quoted context omitted.
I still don't get this. Not knowing everything I've learned for the past year did not prevent me to write clear code back then. I hope I'm writing better code now because I actively reflect on how to write correctly, but that does not prevent my old code to be reasonable. If I found my code from a year ago bad despite all these years of programming, I'd be worried I'm not in fact any good. The whole point of taking c…
I was "not any good" relative to how much better I am now. I'm happy and fortunate that trajectory is continuing. Thirteen years and counting, in fact. Who knows, maybe you're a better coder than I am and you just "got" it instantly! It's immensely important for me to keep growing, so I guess it's a good thing I may be so much worse than you?
I'm not sure I'm above average and would not assume to be better than you, but you could be more self-critical than me.
Few more years than you (it depends when to start counting), definitively in the same range.
Re: Who wrote this shit?
#217Who is Torben?
Re: Who wrote this shit?
#218One of us!
The most prolific writer of absolutely shit legacy code, in my experience, was always me. I was happy I had evolved to at least be able to recognize it as shit. Sometimes I didn't yet have a better idea!
Sometimes I knew it was shit when I committed it, too. Deadlines, frustration, tip-toes, and maybe even imposter syndrome contribute to that.
Re: Who wrote this shit?
#219Earlier quoted context omitted.
Eh, I'm not sure I agree. What has gotten me the most value is having either the branch or the commit message tie back to a ticket somewhere. -That- has the original bug, the comment thread that led to the decision around why this particular fix, any additional comments around tradeoffs we were aware of, and what other options we dispensed with, etc. A well written commit message might explain what the issue was, but…
These two aren't mutually exclusive. Tickets, however, have lower long-term survivability (in my experience). Outsourcing, migrations, there are many scenarios in which the original tickets become inaccessible over time - and some codebases do last for years and years. Meanwhile the repository content (and thus the complete version history) usually survives as-is.
The commit message idea always felt a little strange/off to me. It's a string that you can't (generally) fix/extend later for those who may seek this information. Also nobody except the committer can write them. (Imagine an explicit @docsguy role for documenting commits along with writing ticket-based documentation.)
What if VCSs used a single file or a folder, like .gitcommits, where anyone could append any sort of info in the same commit, so it could be a part of it. Then, when you commit a feature, you add to this file(-s):
@@ @@
+---
+added websocket support to the server
+ /ws - main socket
+ /ws-events - events socket
@@ @@
+---
+added json-rpc over websockets
+ /ws-json-rpc
...
4509812 added websocket support to the server
0732691
8712389 added json-rpc over websockets
@@ @@
---
-added json-rpc over websockets
+added lifetime-related json-rpc over websockets
+task: ./tasks/1873.md
+supports 'start' and 'stop' methods: ./doc/ws-lifetime.md
/ws-json-rpc
@@ @@
+---
+enhanced commit descriptions
A tasks/1873.md
A doc/ws-lifetime.md
4509812 added websocket support to the server
0732691
8712389 added lifetime-related json-rpc over websockets
6034007 enhanced commit descriptions
@@ @@
+---
+refactored foo bar heavily, @docsguy please expand
+---
+fixed a bug in baz, didn't care to backport
...
0923423 refactored foo bar heavily, @docsguy please expand
fixed a bug in baz, didn't care to backportRe: Who wrote this shit?
#220Earlier quoted context omitted.
> context dependent Isn't that by definition what good enough means? That on safety critical code "good enough" is a very different level than on a throwaway-script?
I suppose, but by that same token standards would be the definition of pre-defined "good enough". In my experience, the nebulous nature of the term is usually a means of rationalizing a sub-standard effort. The benefit of defining that threshold upfront is that it's hopefully more objective, before you let cognitive biases influence your decision making. It really comes down to understanding why the goalposts have mo…
The point is that there is no one predefined "good enough", but rather the level of quality that code needs to reach is context dependent. That is why you end up constantly refactoring a little each time you touch the code as that context has usually shifted.