Ask Lemmy
A Fediverse community for open-ended, thought provoking questions
Rules: (interactive)
1) Be nice and; have fun
Doxxing, trolling, sealioning, racism, and toxicity are not welcomed in AskLemmy. Remember what your mother said: if you can't say something nice, don't say anything at all. In addition, the site-wide Lemmy.world terms of service also apply here. Please familiarize yourself with them
2) All posts must end with a '?'
This is sort of like Jeopardy. Please phrase all post titles in the form of a proper question ending with ?
3) No spam
Please do not flood the community with nonsense. Actual suspected spammers will be banned on site. No astroturfing.
4) NSFW is okay, within reason
Just remember to tag posts with either a content warning or a [NSFW] tag. Overtly sexual posts are not allowed, please direct them to either [email protected] or [email protected].
NSFW comments should be restricted to posts tagged [NSFW].
5) This is not a support community.
It is not a place for 'how do I?', type questions.
If you have any questions regarding the site itself or would like to report a community, please direct them to Lemmy.world Support or email [email protected]. For other questions check our partnered communities list, or use the search function.
Reminder: The terms of service apply here too.
Partnered Communities:
Logo design credit goes to: tubbadu
view the rest of the comments
I would urge caution for using it. I already see too many of my juniors starting to rely on it.
The problem (when it works perfectly - and it doesn't all the time), is that you don't learn anything from using it. You aren't learning why it's picking the way to write a specific piece of code. You can ask it to explain it, but you have to go out of your way to do that in standard gpt, in vscode it won't. This is incredibly important when trying to get code to fit within an organization or team's code, where there are already standard patterns, worries about things like runtime, or scalability. You need to understand line by line what that code is doing.
So, I won't say don't use it, but don't depend on it. Learn why it made the choice it did, and dig deeper into the ramifications. Ask it for alternatives and why it chose that one. Ask it for runtime information, how it performs at scale, if it's concurrent and thread safe, anything you can. I use it to help me think outside the box, and it's great at that, but I wouldn't want an engineer working for me who didn't understand what the code was doing.