I’m a 55 year old senior developer. I’ve been coding since I was 12 (yeah, RPG II in punch cards and COBOL stored in 8" floppies), and I have a TERIBLE memory.

Don’t bother memorizing and knowing every language feature and detail. Just get a general awareness of what it can do. Then when you need to accomplish something, it’s good enough that for the first times you do it you go “hey, I recall there’s a way of doing it” or at least (often happens to me) “hmm, this sounds useful enough that this language must have a built-in way of doing it”. Then you google or ask some AI, and you’ll get pointed to the general direction most of the times.

Then if you use it often enough, you’ll remember it. (and in my case, if I don’t use it for 3 months, I completely forget about it, and even get surprised when I see how I did it in my own old code).

In the old days, you could indeed know every feature and library (if any existed at all) of a language. Heck, I knew almost all hex op codes for the Z80 assembly by heart (still recall more of those than I recall my relatives names). Nowadays it is impossible to memorize everything.

In JS realm, if you look at the amount of components you have available in most frameworks, for example in UI5, or existing node modules for your node.js project, even trying to “memorize” them all is a waste of time. In cases like this, you just need to assume there’s a component or module that does what you need, then be good at finding, choosing, and understanding how to use one.

Not to mention the reduntant stuff they throw in “modern” languages, like javascript’s forEach. Some languages have 10 ways of doing the same thing, each one 0.1% more efficient for each particular case, but may catastrophically fail in some other specific case. Screw it. Learn the one that works well for every case and stick with it - you’re not coding ultra performance critical stuff in js anyway.

Programming today is usually more an integration of functioning pieces than building from scratch (assuming that if you’re talking about JavaScript, we’re not talking about creating microcode for bare silicon).

Worry about building an efficient and robust logic in your head. Then the programming language is just a tool, way less important than the logic you came up with.

I would say to give yourself the opportunity to have some fun with it. Maybe that could take the form of trying to apply what you know into some fun little project. Think about whatever you just studied and try to imagine what you could do with that knowledge. Don’t worry about constantly making progress. You will learn a lot just from picking a little project and trying to solve all the little problems you run into.

I think you’ve answered your own question - be less meticulous. Oh, and memorise less.

A good programmer knows where their knowledge boundaries are. For example, if you’re working in JavaScript, you probably don’t need to know bit-shifting.

A good programmer doesn’t know every feature; they know where to go to find that information. They know how to read the manual of an unfamiliar feature.

The most important thing you can do is do practical work. Build a website. Try new things. Look up how to implement something and then do it yourself. Find a project that interests you - like building your own website - that’ll stave off the fatigue.

You don’t need to memorise how to implement a linked-list - you need experience in building.

Good luck.

I’m a senior developer with about a decade of experience in the .NET sphere. My advice would be to flip around your approach and evaluate if it doesn’t work better that way. I would suggest that you find a project you want to make, maybe something related to another hobby or interest (even if it exists already), and start on building that. Now, for every bit that you need, you look up the theory and examples that apply to it and learn those. Then you take a break, personally I find I need at least one night’s sleep, which is probably because it moves stuff from short term to long term memory. Then, you sit down and try your best to do a little something, and evaluate how that went. Maybe you executed it perfectly, great! But maybe you found you learned the wrong thing, or missed something… Also great because now you have your next step.

I would also suggest once you get a little further in your studies that you find an established project to be a part of. Both in my professional career and in my hobby work, I have found that the biggest motivation to learn something and put up with the effort that takes is by having a reason to. There are other subjects I can study for the sake of learning them, but software development is not it. I will also suggest that if you move on to actually do this for a living, that you keep a hobby project around, because programming for money is a whole different beast than programming for joy. It may sound like “extra work” but it’s been instrumental in steering me away from burnout, I thought the suggestion was absolute madness, but I’m glad to admit I was wrong there!

And yeah, I absolutely hit fatigue too. Sometimes at work there are longer periods where I have very little to do, and a common piece of advice is to do self study that is relevant. Great, but after an hour my brain is full and it is like a bucket with a few tiny holes at the bottom, it needs to sit and drain before you can put more into the bucket. That is when you need to do something that isn’t work. I often ask my team to go get a coffee / other drink, so we all step outside and talk about non-work stuff. Which sometimes means we cycle back to work stuff or someone hits an aha moment. I might also put on some familiar music and just zone out for a while. I also worked with someone on a hobby project once, who had in fact put a whiteboard in their shower, because they’d often find stepping into the shower meant their brain started to suddenly generate ideas. All of this is to say that non-work is as important as work-work, and why I personally very much dislike the pressures of presentism. There are concious and subconcious processes in your head and both are vital, just like your computer has foreground software running and services in the back.

The best way to learn is by doing. Nobody knows all the answers. And doing courses/learning for the sake of learning only gets you to the surface.

I’ve been a software engineer for 15+ years at this point and I still end up googling/stack overflowing issues that I’ve encountered. Not suggesting I’m copy-pasting code, but more of a “oh, I can do that!” type of thing.

So start making something that interests you (with the full expectation that you won’t make money/benefit anyone). You hit a roadblock? Great! Time to learn how to fix that problem. Repeat. You hit a point where your code is spaghetti? Learn how to avoid that—look up design patterns. Etc etc.

I get fatigued too! At the end of an especially busy day of coding I have trouble forming sentences for a bit until I take some time to rest. Programming is complicated, and all that mental work literally uses up calories, and fatigues brain cells. Have you heard of the waterfall illusion? The short version is if you watch stuff moving down for a while your downward-motion-detecting cells get tired, and become less active which which messes with your ability to perceive not-moving-upward things for a minute. Your other brain cells get tired too - but it doesn’t take long to recover if you take a break.

Here’s the thing:

Fatigue is normal, but will get worse over time if you don’t address it.

First, recognize that you might be putting too much on yourself. If you studied / programmed 10 minutes a day, every day, you would achieve more than someone who studied 2 hard hours every weekend. So consider whether you’d be fine doing a half an hour or less on some days if you don’t have the energy.

Also as others have pointed out, memorizing everything isn’t that useful, practicing is. Build something fun!

I enjoy programming but I get kinda OC when learning something new, and have to remind myself to be patient. I usually plan projects that are way over my skill level (just a hobbyist).

Most of my successful programs have started out very small and then re-written numerous times over a couple years, gradually becoming large in both scope and complexity as my mind. This allows my mind to envision the programs entirety and make better choices instead of immediate results.