How do you retain the information you’re learning?
Posted by Just-Chillin-Wbu@reddit | learnprogramming | View on Reddit | 41 comments
Obviously as developers we are constantly learning new things, but how do you go about retaining this information?
I notice I struggle to remember things I’ve learnt on the job if I don’t practice them. So wondered if anyone has used like Anki or got any other methods to reinforce their learning?
CodeTinkerer@reddit
One way is to pretend you're teaching a class on the topics you've learned. Write out a lesson plan. Imagine a new hire just arrived, and you've been tasked with explaining it to them.
They should be able to read what you wrote and get a good idea of what is going on, including code examples.
It's a little tedious to do this, especially if you don't like writing.
The other way is to make it more active by creating a "quiz" that tests you on how to use something. Then, write solutions to that "quiz" separately. Review the quiz.
By writing it like a quiz, you are making your brain think of a response. This could be, say, how do I do X in React? Or how do I write a Javascript function that does Y?
besseddrest@reddit
Yeeaaaah I like this - this is also a useful approach when talking about your projects with potential employers, giving a presentation, system design, etc.
My version of this is: Teach me about your project. I don't know anything about it. You are the expert, and I'm here to just learn about it. I'll have questions, but they're not to test you, they're for me to make sense of your project. You're the owner, you drive the convo.
I found this to be useful at a previous job, with an apprentice who was a little shy in general, and we had set up a team meeting so he could show us a task/project he had been working on - an improvement to one of our services. I hadn't worked with that service at all before, and was hoping that I would find out more from this presentation. I didn't learn a thing. So I just sync'd with him after to help him out for the next time.
CodeTinkerer@reddit
Did the next time help?
besseddrest@reddit
I don’t actually remember if he had another presentation in the remaining time that I was at that company, but I would say that I wouldn’t have expected him to just immediately adjust
CodeTinkerer@reddit
Yeah, it takes a while to learn how to teach, and you have to be motivated to do so.
besseddrest@reddit
yeah in this case i think there's a bit of an intimidation/anxiety factor - he was pretty fresh/apprentice and we're just a bunch of seniors just kinda quietly watching. It certainly felt like the first time he's ever had to share code.
But there's also this thing where, when you're pretty green sometimes you just do the work and you don't fully understand the bigger context of what you're doing, or even the task itself. You don't have the command/repetition/muscle memory of this thing you've worked on for a sprint or two, half of that time ur probably learning. If he had to talk about Golden State Warriors basketball as if we were just friends at a bar that are watching basketball for the first time, there's a level of comfort there and you don't have to think about it, you just go
CodeTinkerer@reddit
Maybe? Let's say he was an avid basketball fan, and you were new. It might be challenging to explain stuff especially since basketball has so much slang/terminology. He might assume you know what it means to dribble or what a foul is or what constitutes a foul or why people foul if you're penalized for it (because sometimes you get away with it...).
If you were equally avid, then you could discuss it at a higher level, but figuring out how to explain something you know well to someone who doesn't know it well at all can be a challenge.
For example, I once asked what a possession arrow is (used in college basketball). Someone answered, it goes back and forth.
That's not a good answer. A better answer is: when a basketball is in contention in the NBA, they have a jump ball where the referee puts a ball between two players, one from each team. The players jump up, and try to swat it to one of their team mates.
However, in college ball, they have an alternate rule. They do not have a jump ball. In equivalent situations where they would have a jump ball in the NBA, they give the ball to whichever team has the possession arrow. If the possession arrow points to team A, then team A gets possession, and the possession arrow switched to team B.
That way, unlike the NBA, in college basketball, jump ball situations award the ball first to one team (say team A), then next time, to the other team (team B), and each jump ball like situation, the opposite team gets awarded possession of the ball.
In the NBA, it's possible one team always wins the jump ball (they have a particularly tall player or that player can jump high), but in college basketball, they go back and forth.
The first explanation assumes I knew this was due to a jump ball situation and this was a replacement for that situation.
Of course, it doesn't go into "when does a jump ball occur".
So you see, when explaining something you know well, you often assume the other person knows it equally well. The less the other person knows, the harder it is to convey that information and not get frustrated by having to explain what they think are super basic concepts.
besseddrest@reddit
ah no so i actually don't agree with this but maybe basketball was a poor example
so i think we're straying from OP's original question/topic so i'll try to bring it back
"how do you retain the info while you're learning"
My suggestion is - when you're learning from new, you essentially start from zero. You learn a little bit, now it's time to share. You can probably teach an audience of folks who don't know anything abotu that topic, if you can display some command of that topic, even if it is just 'a little bit'.
Now, in the case of my old coworker - he learns a little bit about the product/service he's working on, and he's scheduled to present to us seniors. What I'm suggesting is he shouldn't try to communicate his 'little bit' as if we're still seniors, because when you're green and you do that u reach for terminology or technical explanations that are outside of that 'little bit', because you want to elevate yourself, and it just falls apart. You only understand a little bit, so command that little bit, because you should assume that we know nothing about engineering. So retaining is the practice of being able to explain the bit that you do know, very well, in a way that it teaches your audience.
anyway, that's just my own advice, maybe i'm wrong or this isn't applicable but in general i think when you're learning i think its good practice to take something you dont understand quite well and put it into a vocabulary where you are able to make sense of it. Build on top of that and your understanding and ability to communicate that gradually becomes more tehcnical
CodeTinkerer@reddit
Oh, I completely agree. I learned a lot by teaching (several years) of programming. I used to write out my lecture notes as if they were mini-chapters in a book with diagrams, complete sentences, etc.
If the explanation I wrote didn't make sense, then I knew I didn't understand it well enough and had to think about it some more.
When I wrote, I constantly thought "did I make too many assumptions on what they know". That came from an AI teacher (back in the day, not LLMs of today) that dropped NLP terminology without defining it. She was just unaware that terms she used every day were terms we had never heard of, so I tried to be careful with my terminology.
For example, I would stick to one term if possible. Quite often, you hear multiple variations of some concept in programming. For example, when to use parameter vs when to use argument. Some people use it interchangeably. But I followed a book that always used parameters for function definitions and arguments for function calls, and I'd stick to that.
I'd also follow some stuff they tell you about public speaking esp. on a something that might be a bit complex. They say
So, preview, content, and review.
I've even entertained the idea of a reverse quiz. Most chapters start with content, then might have review (quiz) questions afterwards.
Instead, pose the questions first, then explain the content. Listeners will be much more attuned to hearing for the answer if they know the questions in advance. In essence, it's tell them what the review questions are, then explain the concepts, then review those questions again at the end.
besseddrest@reddit
nice! one thing i find helpful from a teaching standpoint is i prompt the person by asking them to show me what they do know, and how they understand the issue/task they're facing. This gives me the opportunity to spot the disconnect and also an idea of their actual technical understanding of it - and generally this is how i approach folks when I need help with something
so yeah, sounds like we're on the same page - really important to understand the person you're talking to, so we can understand how to help them best. Thank you for sharing!
CodeTinkerer@reddit
A lot of teachers often like the fact they inspire students that didn't seem likely to succeed or to help a student to amazing heights. However, for me, I found it more interesting to figure out where my explanations were inadequate. To do so, I needed an understanding of how my students (back in the day) interpreted what I was saying. Was it too abstract? I often used an analogy.
For example, to explain problems with caching, I said imagine there's a parking lot with 1000 spots, numbered from 000 to 999. You can park at a spot which has a number that matches the firs 3 digits of your social security number (SSN). Is that a good idea?
First, if you're not American, the SSN is a 9 digit number usually written as ddd-dd-dddd. It turns out the first 3 digits depend on when you got your SSN. Most get it quite young with their parent's help. The first 3 digits indicate the region of the US you got your SSN from.
A state university is a university that's partly paid for by the state (e.g., Florida) so many that go to a state university (which is often the cheapest options) live in that state and got there SSNs in that state (this examples work better if you know SSNs already), then the range of the first 3 digits can be rather narrow, no more than 100 different digits per state, so that means most people will contend for the same 100 spots out of the 1000 available and the spots are not well-utilized.
The abstraction of these cache problems isn't obvious, but a good analogy helps with visualization. I was always in search of ways to explain confusing technical aspects. Sometimes I just had lengthy detailed rules such as how a nested for loop executes (I won't go into detail) using something that resembled a flow-chart.
But yes, I think we do share these ideas in common. Nice to hear your thoughts as well!
optical002@reddit
A good book about how to learn efficiently programming:
The Programmer’s Brain: What Every Programmer Needs to Know about Cognition Book by Felienne Hermans.
It explains how brains retain information and hives techniques how to retain information efficiently with programming examples
Dari93@reddit
Everyone says build project but what if i dont have time to write projects? Writing from scratch without asking chst gpt requires so much time for me. Time that most times I don’t possess. Work, married life and study dries me up.
person1873@reddit
I used to maintain a personal MediaWiki instance when I was in college. It was really only for you own use, but it gave me a framework to broaden my understanding of things. It showed me what I had a good understanding of, and where I was lacking.
It also meant that if I'd forgotten something, I could go back and re-read it in my own words.
Cybasura@reddit
Write comments, always add comments explaining what you are doing, especially if you write difficult logic
Slodin@reddit
i remember the keyword or something close. and what did it solve.
recite back when I something similar and use google...the keyword will most likely popup and now I know.
Working for many years and juggle a bunch of platforms, languages, and frameworks I simply cannot remember every single thing. So I just remember the general idea and search it up when I need it.
chubberbrother@reddit
Go slow, understand, and make a mental note.
You're not expected to remember everything.
I go into VPs and a ton of the technical meetings are "Wait let me double check this".
Nobody expects you to be an encyclopedia.
Get the fundamentals down and be confident that you can look up what you need to look up.
tlaney253@reddit
When you were learning to write words with a pencil in primary school i bet it was hard but with practice it became a lot easier, right? Same applies to programming, you need to write code in order to retain the information. How does one write code, “Idk what to write! or what sorta project to start”
Write small projects and go bigger as you gain more proficiency, anyone who codes will tell you that this is valid.
Even something as simple as a calculator, or a program to calculate something such as the area of a square or just anything.
Good luck and remember that consistency is key, even if you’re programming for ten minutes a day try your hardest to maintain your consistency during your core learning stages.
dafcode@reddit
Impossible to retail so much information. You take notes, or better, start a blog.
parnmatt@reddit
Use them.
Even if it's a toy project. Write something, add a little complexity, hit the edge cases. Debug the issues.
Anus_Enchanted@reddit
I agree. Use them and it's okay if you forget because you will eventually have an idea of how things work and you know exactly what to search for.
Eldiablo2471@reddit
Many small projects better? Or less projects but bigger scale? Just wondering
parnmatt@reddit
Whatever works best for you.
I found that writing concepts as if they are a library, this have to think about how it will be used, be quite generic and force thinking of edge cases, and in general written with more thought.
Then I try and use that library in a smallish project or two. Sometimes I develop it more and more over time.
Small becoming refined and larger.
However nothing wrong with dozens of throw away toy projects. At the end of the day anything that gets you both thinking and writing code the better.
Eldiablo2471@reddit
Wow dude. You just gave me an idea right now honestly. Creating my own small libraries and use them in projects rather than the ones that are built in Python. Dude you rock. Thanks.
I've mostly had problem with the logic of the project I want to do like I start with a small idea and somewhere in the middle it's not exactly clear to me what I am trying to achieve so I find myself stuck when changing the program again and again and never feeling like it is perfect the way I want it.
So I will just start braking things up in very small pieces. Cheers
InitialAgreeable@reddit
Exactly, write tiny little projects to put your learnings into practice. Store everything in a repo, and get back to it after n months
sswam@reddit
Using Anki would work. I don't bother doing that though. I'm working on an AI app that will work a bit like Anki, so I'll probably use that to learn things at some point.
armahillo@reddit
practice as much as possible
Digicrests@reddit
Poorly.
Olimejj@reddit
I don’t retain anything that I’m not actively using so I use a Notes system. When I set something up or learn something new start using a new technology I will take careful notes that I can use when I need to later. Eventually, your notes become a part of your brain and really act as a tool to help you remember the things that you kind of remember. There are plenty of Notes systems the one that I used was Evernote, though they have recently changed their business model and I will probably end up switching systems next time I have a job, that requires me to take lots of notes.
AlekseyVY@reddit
I use anki
Pale_Height_1251@reddit
Build projects.
Any_Sense_2263@reddit
no app will make your brain learn like hours spent on solving problems... so create a side project and develop it daily and add new things you just learned at work... play with it
mxldevs@reddit
You basically have to practice them. If it's not something you're using on the job, you have to figure out how to use them outside the job.
Gerardo_Salinas@reddit
Practice. Don't feel bad for not retaining information you don't use frequently, it's just natural your brain will prioritize memorizing information you frequently use even if you don't actively set the goal to memorize it.
Duffy13@reddit
Repeated use, the more you use it the more you reinforce it. I was a DBA/Database Dev for a decade, I’ve since switched to a SRE role and have forgotten so much about SQL. Sure the general bits are rattling around in there and I’m sure I’d have an idea of what I’d need to do or look up to accomplish whatever, but the instant recall of details/syntax is definitely eroding as time and lack of use goes on.
did_i_or_didnt_i@reddit
take notes and go through your old code and review, run it again, change some stuff. Anki is great on the surface but it makes it feel like way more of a chore than an explorative adventure. I would use anki if you really want to memorize stuff from the docs but like….. the docs are right there
did_i_or_didnt_i@reddit
I run a ‘c:/notes’ folder personally and also have notes on paper if I’m actively learning
LoneArcher96@reddit
I need to relearn what I didn't HAVE to use repetitively.
WhoIsSidi@reddit
Through using Anki (Spaced Repetition + Active Recall) and teaching others.
aqua_regis@reddit
Use it or lose it.
Memorizing via Ankhi or somolar is meaningless.
The only proper way to retain and improve is using, not memorizing.
MoonLighter011@reddit
Using the information is big. Learning other topics that relate to the subjects you learned, and manipulate the way the process or data is handled, possibly going to a deeper level can also be very helpful. A concept like this would be going from database queries, like with SQL, and moving to ORMs (Object-relational mapping) to abstract the process.