JenniferplusplusSo, what was up last week, when all of tech suddenly decided that writing software isn't good or useful or interesting?
Cuz, I gotta say, that sucks, and you're all wrong.
Like, I really don't get why so many of you are so eager to have statistical models write code for you.
I've been arguing for literally my whole career that the actual writing isn't the hard part of software development. But wow, did everyone take that in the wrong direction recently.
Understanding the system is the hard and valuable part. And I genuinely don't know how you think you're going to do that if you never get to do any of the safe and easy interactions with the system.
matzipan@jenniferplusplus @scottjenson I've been playing with copilot and I have found some genuine uses for it:
1. It uses context like comments and other lines of code and acts as an autocomplete++. If you have some repetitive code with some changes in variables it will pick up on those and make changes needed. In a docstring I wrote if a variable was 1, 2 or 3 bytes. I wrote the code for 1 byte and then copilot wrote the code for 2 and 3 bytes and correctly adjusted the asserts and encodings.
1. It uses context like comments and other lines of code and acts as an autocomplete++. If you have some repetitive code with some changes in variables it will pick up on those and make changes needed. In a docstring I wrote if a variable was 1, 2 or 3 bytes. I wrote the code for 1 byte and then copilot wrote the code for 2 and 3 bytes and correctly adjusted the asserts and encodings.
lj·rk@matzipan @jenniferplusplus @scottjenson But isn't the right way to do this to... not write repetitive code. Copilot just makes writing bad code easier.
@matzipan @jenniferplusplus @scottjenson And regarding comments: If you can deduce the comment from the code, that's a useless comment. Either re-write the code to be more obvious or document the ideas/design decisions behind it.
dr2chase@ljrk @matzipan @jenniferplusplus @scottjenson How much time should I spend deducing, when the comment could just say it?
Llama@dr2chase @ljrk @matzipan @jenniferplusplus @scottjenson It's pretty important to avoid noisy comments, IMO. The vast, VAST majority of useful comments I've ever written or encountered (only some of which I wrote earlier) have been about WHY the code is there and written the way it is. Even for abstruse "clever" circumlocutions where you write down what that impenetrable snarl does, you're stepping all over your own hair if you don't also explain why you had to create the Gordian knot in the first place.
I mean, write down what whole blocks or functions do, sure -- by all means, document your API properly -- but comments are much less impactful and much easier to skim past if there's too much spurious chaff about what the code does tanking your SNR.
@Llammissar @dr2chase @ljrk @jenniferplusplus @scottjenson I am not sure if you're replying to me but I agree and this was one of those situations where it didn't simply parrot out "this function increments by 1" but it somehow parroted out a higher level meaning of the code.
@Llammissar @dr2chase @matzipan @jenniferplusplus @scottjenson Yup. If the code is hard to read, a comment is not a proper fix, fix it in code instead.
Code should be as expressive as possible and only things not able to be expressed in code should be written in comments. Otherwise you also easily run into wrong comments which were either wrong from the start or became wrong due to change anomalies resulting from the redundancy: If comments contain redundant information, a change in code may forget to update the comment and result in misleading comments.
I do admit, this is maybe a bit tainted through my background in code audits/security. In my experience, most comments are just wrong. And in many cases dangerously wrong. But reading those comments could mislead the reviewer to think the code was right. At some point I started stripping comments from code pre review because most comments are just distractions from the real problem and not design explanations – which they should be.