No you’re wrong. For example you can have a full conversation with GPT-4 about pointers or garbage collection, and come away from that with a really good understanding of the fundamentals.
You won’t get that from just reading a book or article, because you can’t ask an questions. The conversational nature of ChatGPT is amazing. I’ve learned things in days that have taken months in the past.
You can also paste in a snippet of code that doesn’t work, and it will usually explain why and how to fix it.
Can’t say that I struggled to understand pointers but if GPT helped you conceptualize em that’s good. I really don’t see much utility in even the current iterations of these LLMs. Take copilot for example, ultimately all it actually helps with is boilerplate which if you are writing enough for it to be meaningfully helpful you can have a fancy IDE live template or just a plain old snippet.
Theres a lot of interesting things it could be doing like checking if my documentation is correct or the like but all it does is shit I could do myself with less hassle.
There’s also the whole issue of LLMs having no concept of anything. You aren’t having a conversation, it just spits out the words it thinks are most likely to occur in the given context. That can be helpful for extremely generic questions it’s been trained on thanks to Stack Overflow but GPT doesn’t actually know the right answer. It’s like really fancy autocorrect based on the current context. What this means is you absolutely cannot trust anything it says unless you know enough about the topic to determine what it outputs is accurate.
To draw a comparison to written language (hopefully you don’t know Japanese) is 私 or 僕 “I”? Can you confidently rely on auto correct to pick the right one? Probably not cause the first one わたし (watashi) is “I” and the second ぼく (boku) is also “I” (more boyish). Trusting an LLMs output without being able to ensure it’s accuracy is like trusting auto correct to use the right word in a language you don’t know. Sure it’ll work out fine generally but when it fails you don’t have the knowledge to even notice.
Because of these failings I don’t see much utility in LLMs especially seeing as the current obsession is chat apps geared at the general public to fool around with.
Thanks! Lot of people don’t seem to realize that GPT doesn’t actually have any idea what words mean. It just outputs stuff based on how likely it is to show up after the previous stuff. This results in very interesting behavior but there’s nothing conceptually “there”, there’s no thinking and so, no conversation to be had.
Reimplementing stuff from scratch, overengineering and, if you’re coding in a compiled language, knowing a bit of assembly to be able to make better performance-related decisions.
EDIT to clarify the overengineering part: the idea is not to do it at work obviously because there you will have to meet deadlines and you will have to spend time on what’s most important, but the idea instead is to do that when working on your own personal projects. Try to make every component of your project as “perfect” as possible as if you were trying to rebuild a Mercedes-AMG car. That’s how you’ll learn a bunch of new tricks.
I find that reading a lot of code helps. From the bad code, take note of what to avoid. From the good code, take note of what to emulate.
To be clear, it’s often more useful to read code within your specialization than to read any ol piece of code on the Internet. That said, drawing from other programming languages and across a rich variety can be useful into itself.
Lol. That’s why we comment with “why”, rather than “what”. The answer to “what the duck where we even thinking?” usually doesn’t need updated until the commented code goes away.
Never understood this argument, it’s the person’s responsibility who changed the code to update the comments if needed. Otherwise they just implicitly admit that they did not read it or understand the context, or just plain did not care.
I hear this quite a bit, and think there’s actually a good deal of nuance to it. I’ve seen places that insisted on comments for everything, and it was silly, a significant number of comments had no value. This made people not read comments, as opposed to other places I’ve worked with very few comments - when you ran across a comment you gave it more weight (something here was complex, or not as simple as it seemed).
So imo, use comments which can communicate effectively, but use them sparingly for important parts that are complicated, for the rest attempt to communicate with the code itself.
step 1: learn to comment everything. This will helps code reviewer to catch errors because your code doesn’t match the comments
step 2: write your code in a way that makes comments useless and stop writting them
step 3: write your code just like you did in step 2, but documents all the things that you didn’t do, or why the code is more complicated than the naive approach. If your arguments are weak you are not in step 3, but in step 1.
I find that writing detailed comments about things that aren’t clear in the code often lead me to a better, more clear solution. Same thing with writing detailed commit messages. So many times I realize something better during the message, I’ll finish the commit and then almost immediately amend that commit with the better way.
I generally say, “I want to make X” then I slowly work up to it. Currently I’m making a pathfinding algorithm.
I input a map with my starting point and finishing point and it has to get there. It has to know where to go back to if it goes the wrong way, when it’s allowed to stop, etc.
The next steps will be getting it to only show the finished path, then to work out the fastest path when it has multiple possible paths etc.
lots of tutorials in different languages, a base project that you start to rewrite over and over forever whenever you aren’t motivated to do something else. write scripts to start new projects with a readme, git, a logger, and a unit test or two. You should be able to run a command to have a new working project ready to test any new library or idea. don’t be afraid to write code and not use it. writing is the point itself.
When I had to fix a bug, I made sure not to just fix the problem, but to understand it.
There’s a massive difference between the two. When I was a junior I would often find out how to fix a problem by googling and trying different things until something worked, but I wouldn’t understand why.
Then I started digging into what was actually going on under the hood and finding out the why of things - sometimes it was to do with a framework, sometimes a language, sometimes it reveals a fault in yours or someone else’s programming.
But every single time you learn something new and it solidifies your knowledge of your tech stack and programming in general.
Also, one of the best phrases I’ve ever heard in programming is “every bug is a missing test” - these days the first thing I do with a bug is write a test to expose the bad behaviour - then you can go about fixing it with confidence and preventing regression errors.
Test driven development has really helped me understand bugs and functional changes well. Doing a red green change has done wonders for me over the years.
Reading code. Not just your primary language. But other languages too.
Most problems are already solved. Someone out there solved it. Maybe they didn’t solve it in the language you need. But fortunately, they provided their code on GitHub.
B) Interacting with programmers other than yourself.
On a more specific note:
Don’t work “around” problems. Identify what the problem actually IS and work backwards. When you try to take a step and find that you don’t know what step to take, or you’re stepping into something you don’t understand, go research and learn about it.
Learning how to read technical documentation is a valuable skill.
Recognize and challenge your assumptions. Which plays into working “around” problems. Do I know the error I’m researching came from this bit of code? Is this bit of code even running? Is the source file I’m looking at even part of the binary I’m running? Is the binary that’s running actually the one I’m trying to test?
The longer answer is, do it a lot. Listen in code reviews. When you investigate bugs, do actual root cause analysis, understand the problem, and understand how it got missed. Don’t stop learning, study your languages, study design patterns, be intentional in what you learn.
I had good mentors that were hard on me in reviews. Developing a thick skin and separating criticism of you from criticism of your code will help a lot in terms of learning in reviews.
Source: 10 years in the field. (Senior SW Eng. Focused on embedded systems and VnV)
23 years in and I don’t think that there is better advice here. Listen. Practice. Experiment.
If it’s something you want to get good at, do it as a hobby. Pick projects that you don’t know entirely how to do. Adversity is a better teacher than anything else I’ve run into.
Learn other languages too. I learned more about C from a year of rust than two decades of C.
The only caution I’d add about doing it as a hobby too is that it’s super easy to burn yourself out. I think that’s why so many of us get into woodworking and gardening lol
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programming@programming.dev
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person’s post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
Follow the programming.dev instance rules
Keep content related to programming in some way
If you’re posting long videos try to add in some form of tldr for those who don’t want to watch videos
Lately - ChatGPT 4 has been amazing.
If you’re not sure how to do something - the answer is a few seconds away now.
GPT is amazing at hallucinating the answer not much else
No you’re wrong. For example you can have a full conversation with GPT-4 about pointers or garbage collection, and come away from that with a really good understanding of the fundamentals.
You won’t get that from just reading a book or article, because you can’t ask an questions. The conversational nature of ChatGPT is amazing. I’ve learned things in days that have taken months in the past.
You can also paste in a snippet of code that doesn’t work, and it will usually explain why and how to fix it.
I very rarely encounter halucination.
Can’t say that I struggled to understand pointers but if GPT helped you conceptualize em that’s good. I really don’t see much utility in even the current iterations of these LLMs. Take copilot for example, ultimately all it actually helps with is boilerplate which if you are writing enough for it to be meaningfully helpful you can have a fancy IDE live template or just a plain old snippet.
Theres a lot of interesting things it could be doing like checking if my documentation is correct or the like but all it does is shit I could do myself with less hassle.
There’s also the whole issue of LLMs having no concept of anything. You aren’t having a conversation, it just spits out the words it thinks are most likely to occur in the given context. That can be helpful for extremely generic questions it’s been trained on thanks to Stack Overflow but GPT doesn’t actually know the right answer. It’s like really fancy autocorrect based on the current context. What this means is you absolutely cannot trust anything it says unless you know enough about the topic to determine what it outputs is accurate.
To draw a comparison to written language (hopefully you don’t know Japanese) is 私 or 僕 “I”? Can you confidently rely on auto correct to pick the right one? Probably not cause the first one わたし (watashi) is “I” and the second ぼく (boku) is also “I” (more boyish). Trusting an LLMs output without being able to ensure it’s accuracy is like trusting auto correct to use the right word in a language you don’t know. Sure it’ll work out fine generally but when it fails you don’t have the knowledge to even notice.
Because of these failings I don’t see much utility in LLMs especially seeing as the current obsession is chat apps geared at the general public to fool around with.
Fucking love your example dude.
I’ve found ChatGPT3 OK for low level stuff, but I stopped using it pretty quickly once I went to trying to get it to help build intermediate stuff.
If its making errors in simple script design, it can’t handle more.
It is fab for the basics, but I wouldn’t truste it for learning anything else more complex for exactly the reasons you said.
Be liable to write my own backdoors that way hahah
Thanks! Lot of people don’t seem to realize that GPT doesn’t actually have any idea what words mean. It just outputs stuff based on how likely it is to show up after the previous stuff. This results in very interesting behavior but there’s nothing conceptually “there”, there’s no thinking and so, no conversation to be had.
Reimplementing stuff from scratch, overengineering and, if you’re coding in a compiled language, knowing a bit of assembly to be able to make better performance-related decisions.
EDIT to clarify the overengineering part: the idea is not to do it at work obviously because there you will have to meet deadlines and you will have to spend time on what’s most important, but the idea instead is to do that when working on your own personal projects. Try to make every component of your project as “perfect” as possible as if you were trying to rebuild a Mercedes-AMG car. That’s how you’ll learn a bunch of new tricks.
Working with engineers that were better than I was and actually listening when they reviewed my code… Asking why and going from there.
“if you’re the smartest person in the room, you’re in the wrong room”
Well, if every person thinks this way we will never have a stable room of people xD
Maybe that’s a good thing?
Unless you’re giving a lecture
Finding some project that I really enjoyed working on, and just absolutely going ham on it. That’s the best way to learn.
This is The Way.
Enjoying it, and time.
I find that reading a lot of code helps. From the bad code, take note of what to avoid. From the good code, take note of what to emulate.
To be clear, it’s often more useful to read code within your specialization than to read any ol piece of code on the Internet. That said, drawing from other programming languages and across a rich variety can be useful into itself.
deleted by creator
“I don’t need to comment this code, I wrote it so I know what it does”
And then
“Fuck, I should’ve commented this code, I have no idea what it does”
Comment. A lot.
Yep, was going to say that refactoring my own code taught me a lot
Stage 2, “why does this code have nothing to do with the very detailed comments?”
git blameIf the comments don’t match the code then someone failed to properly review it.
Always comment the why, not the what/how. Bonus of doing this is you only need to update the comments when the why changes
Lol. That’s why we comment with “why”, rather than “what”. The answer to “what the duck where we even thinking?” usually doesn’t need updated until the commented code goes away.
Never understood this argument, it’s the person’s responsibility who changed the code to update the comments if needed. Otherwise they just implicitly admit that they did not read it or understand the context, or just plain did not care.
It just never works. Its important documentation breaks if changes are made. The best docs are baked into unittests
I hear this quite a bit, and think there’s actually a good deal of nuance to it. I’ve seen places that insisted on comments for everything, and it was silly, a significant number of comments had no value. This made people not read comments, as opposed to other places I’ve worked with very few comments - when you ran across a comment you gave it more weight (something here was complex, or not as simple as it seemed).
So imo, use comments which can communicate effectively, but use them sparingly for important parts that are complicated, for the rest attempt to communicate with the code itself.
step 1: learn to comment everything. This will helps code reviewer to catch errors because your code doesn’t match the comments
step 2: write your code in a way that makes comments useless and stop writting them
step 3: write your code just like you did in step 2, but documents all the things that you didn’t do, or why the code is more complicated than the naive approach. If your arguments are weak you are not in step 3, but in step 1.
I find that writing detailed comments about things that aren’t clear in the code often lead me to a better, more clear solution. Same thing with writing detailed commit messages. So many times I realize something better during the message, I’ll finish the commit and then almost immediately amend that commit with the better way.
I generally say, “I want to make X” then I slowly work up to it. Currently I’m making a pathfinding algorithm.
I input a map with my starting point and finishing point and it has to get there. It has to know where to go back to if it goes the wrong way, when it’s allowed to stop, etc.
The next steps will be getting it to only show the finished path, then to work out the fastest path when it has multiple possible paths etc.
You may find these concepts interesting (if you don’t know them already) Recursion algorithms for graphs: https://en.wikipedia.org/wiki/Shortest-path_tree Dynamic programming: https://www.baeldung.com/cs/tabulation-vs-memoization
lots of tutorials in different languages, a base project that you start to rewrite over and over forever whenever you aren’t motivated to do something else. write scripts to start new projects with a readme, git, a logger, and a unit test or two. You should be able to run a command to have a new working project ready to test any new library or idea. don’t be afraid to write code and not use it. writing is the point itself.
When I had to fix a bug, I made sure not to just fix the problem, but to understand it.
There’s a massive difference between the two. When I was a junior I would often find out how to fix a problem by googling and trying different things until something worked, but I wouldn’t understand why.
Then I started digging into what was actually going on under the hood and finding out the why of things - sometimes it was to do with a framework, sometimes a language, sometimes it reveals a fault in yours or someone else’s programming.
But every single time you learn something new and it solidifies your knowledge of your tech stack and programming in general.
Also, one of the best phrases I’ve ever heard in programming is “every bug is a missing test” - these days the first thing I do with a bug is write a test to expose the bad behaviour - then you can go about fixing it with confidence and preventing regression errors.
Test driven development has really helped me understand bugs and functional changes well. Doing a red green change has done wonders for me over the years.
Reading code. Not just your primary language. But other languages too.
Most problems are already solved. Someone out there solved it. Maybe they didn’t solve it in the language you need. But fortunately, they provided their code on GitHub.
A) Practice.
B) Interacting with programmers other than yourself.
On a more specific note:
Don’t work “around” problems. Identify what the problem actually IS and work backwards. When you try to take a step and find that you don’t know what step to take, or you’re stepping into something you don’t understand, go research and learn about it.
Learning how to read technical documentation is a valuable skill.
Recognize and challenge your assumptions. Which plays into working “around” problems. Do I know the error I’m researching came from this bit of code? Is this bit of code even running? Is the source file I’m looking at even part of the binary I’m running? Is the binary that’s running actually the one I’m trying to test?
deleted by creator
The short answer is “practice”
The longer answer is, do it a lot. Listen in code reviews. When you investigate bugs, do actual root cause analysis, understand the problem, and understand how it got missed. Don’t stop learning, study your languages, study design patterns, be intentional in what you learn.
I had good mentors that were hard on me in reviews. Developing a thick skin and separating criticism of you from criticism of your code will help a lot in terms of learning in reviews.
Source: 10 years in the field. (Senior SW Eng. Focused on embedded systems and VnV)
23 years in and I don’t think that there is better advice here. Listen. Practice. Experiment.
If it’s something you want to get good at, do it as a hobby. Pick projects that you don’t know entirely how to do. Adversity is a better teacher than anything else I’ve run into.
Learn other languages too. I learned more about C from a year of rust than two decades of C.
The only caution I’d add about doing it as a hobby too is that it’s super easy to burn yourself out. I think that’s why so many of us get into woodworking and gardening lol