3 ms·

> Do they not appreciate some help to document their code? How does an LLM help there? What the code does should be obvious by looking at it, WHY it was writte

by MaKey 2y ago

> Do they not appreciate some help to document their code? How does an LLM help there? What the code does should be obvious by looking at it, WHY it was written that way is the interesting question. Answering it often requires more context and domain knowledge. > Do they never need to write or quickly understand scripts or code in one of the 100's of languages/stacks they're not too familiar with that they might encounter in the wild? I'd rather take the time to do it myself because if I'm not familiar with a language/stack I won't be able to spot mistakes made by the LLM as easily. > How to get out of yet another git mess? Learn to solve the git issue and apply the knowledge in the future so you don't rely on yet another tool. > Build a proof of concept in an hour that would've taken you days? I question the premise. > A refresher on how to set up x toolchain to get started asap (the nr 1 hardest thing in programming :p) etc etc. How often do you do that? I think it's worth spending the time to do it yourself so you get an understanding of what exactly you're doing there. When you're done you can document the process and come back to it next time.

bboygravity 2y ago
What you're basically saying here is: you should just learn more and know more faster. And what I'm saying is: that's exactly what LLM's are super useful for. To answer your last question: about every 6 months or so. I'm a freelancer, I do a new project for a new client every 6 months on average. All of their toolchains, build systems, OS of choice for the dev machine, OS of choice for the SoC, documentation methods, PCB design tools, version management systems, release systems, testing frameworks are completely different per client and change constantly (even within the same company) depending on department and moment in time.
- MaKey 2y ago
  > What you're basically saying here is: you should just learn more and know more faster. I didn't say anything about speed. I think you should take the time to deeply understand what you are working on. > And what I'm saying is: that's exactly what LLM's are super useful for. I disagree, LLMs aren't good teachers. You won't be able to spot subtle issues with their output if you're not already familiar with the topic. > To answer your last question: about every 6 months or so. [...] I don't see the big advantage of using an LLM there. It can't set up the environment for you.
  - bboygravity 2y ago
    > I don't see the big advantage of using an LLM there. It can't set up the environment for you. I can give it tons of random documentation without having to read through it to understand what parts are useful without having to filter through the irrelevant/mistyped/outdated/badly written stuff, even give it undocumented (shitty old) code and ask specific questions about how it works or what the likely intention was. I promise you it is useful to me. I use it every day. It can't set up the environment for me all by itself, but it sure can help me do it WAY faster and understand it way faster. Especially the boring stuff nobody wants to do. PS: who has time to deeply understand all aspects of what they are working on? This makes no sense to me in the context of a job. If I would take time to deeply understand every tool, script or even source code I touch, I would NEVER get to doing ANY work.

by MaKey 2y ago

bboygravity 2y ago

What you're basically saying here is: you should just learn more and know more faster. And what I'm saying is: that's exactly what LLM's are super useful for. To answer your last question: about every 6 months or so. I'm a freelancer, I do a new project for a new client every 6 months on average. All of their toolchains, build systems, OS of choice for the dev machine, OS of choice for the SoC, documentation methods, PCB design tools, version management systems, release systems, testing frameworks are completely different per client and change constantly (even within the same company) depending on department and moment in time.

MaKey 2y ago
> What you're basically saying here is: you should just learn more and know more faster. I didn't say anything about speed. I think you should take the time to deeply understand what you are working on. > And what I'm saying is: that's exactly what LLM's are super useful for. I disagree, LLMs aren't good teachers. You won't be able to spot subtle issues with their output if you're not already familiar with the topic. > To answer your last question: about every 6 months or so. [...] I don't see the big advantage of using an LLM there. It can't set up the environment for you.
- bboygravity 2y ago
  > I don't see the big advantage of using an LLM there. It can't set up the environment for you. I can give it tons of random documentation without having to read through it to understand what parts are useful without having to filter through the irrelevant/mistyped/outdated/badly written stuff, even give it undocumented (shitty old) code and ask specific questions about how it works or what the likely intention was. I promise you it is useful to me. I use it every day. It can't set up the environment for me all by itself, but it sure can help me do it WAY faster and understand it way faster. Especially the boring stuff nobody wants to do. PS: who has time to deeply understand all aspects of what they are working on? This makes no sense to me in the context of a job. If I would take time to deeply understand every tool, script or even source code I touch, I would NEVER get to doing ANY work.