I really love computer science, coding and mostly all the amazing things you can do with this knowledge, i feel i finally landed in my world.

I’m doing a Javascript course now and while it is really engaging to learn about how a language like that works and how to build with it, i’m getting quite tired and frustrated…

Now, i’d say i am quite meticulous when studying and i use some studying techniques to really integrate what i’m learning, but that means that 1h or even less lesson can take me all the time i have to study in a day to be understood, noted down and then repeated over the following days…

There are a lot of quite complicated concepts to understand and memorize, and, as i’m also working, sometimes it gets quite tiring.

I feel like there’s this huge amount of never ending work and concepts before i can actually start do something cool with the knowledge i have, and i really want to start doing something cool.

I re-started to study after many years so i’d say it’s also because of that if i’m not really used to it and i can’t process much informations at the time.

How can you get better into gaining knowledge? how can you prevent getting fatigued?

  • 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.

    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.

    • Don’t bother memorizing and knowing every language feature and detail. Just get a general awareness of what it can do.

      Exactly. You won’t remember features, but your intuition will handle patterns.

    • Even further, I think it’s important to keep in mind that you learn something every day in the programming field. There’s constantly new languages and new features. Learning these shouldn’t be a difficult undertaking that takes all day or you’ll burn out so fast. Your learning needs to be agile so you can learn while continuing to work. Your boss won’t allow you to take a week off to learn a library, sometimes you’ve just got to start slapping it in there and learn by doing.

      Just start building! You’ve got to build and roll with the punches

  • 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.

    • Agreed.

      If you’re doing this for fun, then don’t ruin it for yourself. Doing a course should enable you to do stuff you haven’t been able to do before. Just pick a project and do it. And then maybe you’ll use some of the things you’ve learned, maybe you won’t. You’ll never use all the things you learn, and there is always more to learn.

      I’ve been a principal engineer for a long time, and I still learn new stuff every single day. There is no end. Which is pretty amazing if you ask me. You can always learn more stuff, but you shouldn’t feel obligated.

      If you start a project, you’ll apply some of that knowledge, and it’ll stick much more.

    • I agree. When I learned programming over a decade ago, I didn’t follow a course and I’m not sure courses were particularly widespread. Looking back, what I made was terrible quality but it got better with time. At first I’d even copy entire sections of code into place unsure of what it really does and eventually I would make it work. It sounds like OP is much further along than that. Just make something, it’s the best part!

  • 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 can definitely attest to this advice. Learning how to search for answers, and parse options builds a whole of confidence when you’re trying to solve something.

      And nothing makes you search for answers more than having a problem to solve.

  • 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.

  • 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.

  • This is terrible advice… but it’s what worked for me. If you’re the same kind of idiot as me, maybe this will work for you, too:

    Give up and come back later. Yes, I’m serious – take a break for as long as you like so long as you pinky promise to try again someday (I did say this was terrible advice). That’s the beauty and curse of learning something for fun! You can be inefficient and make progress (or not) on strictly your own terms.

  • 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!

  • Just some feedback from someone who sounds like they may be similar to you in some ways — if you’re talking about SRS / Anki type notes … that’s definitely overkill, for programming.

    (And from your description, it sounds like “overkill” is, indeed, killing you.)

    You genuinely shouldn’t worry about memorizing programming topics! As a field, we all tend to search up anything we need to know, in real-time, as we run into it; everything from syntax for a programming language we haven’t used in a while, to data-structures we’ve forgotten the details of, even to terminology that’s a bit different than our particular sub-field is using daily.

    Mostly, if not almost entirely, the effective way to master “programming” (which, again, is mostly a synthesis of ‘stuff that’s at the front of my brain from working on this current project for a while,’ and ‘everything i can extract from Google on short notice’) … is to just do. And do a lot. Start projects. Get obsessed. Get bored, move on, do another!

    tl;dr stop taking notes and just hang your head against code! I swear, it’s genuinely far more effective.

    (If it helps you to believe me, some credentials: dev for, idk, more than 15 years; entirely self-taught; have built everything from programming-languages and compilers to mobile apps to massively-distributed systems running across 500,000 CPU cores; I’ve learned, taught, forgot, and then learned again, more languages and frameworks than I can count.

    You can do this!)

  • 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.

  • I feel like there’s this huge amount of never ending work and concepts before i can actually start do something cool with the knowledge i have, and i really want to start doing something cool.

    I have been a software engineer for almost a decade and have used at least half a dozen languages professionally with as many frameworks and platforms. There are still concepts I don’t understand; that is the nature of our work. There are always more things to know.

    Part of the job is being able to emotionally grapple with this. We can’t know everything, but we can try to get the job done with what we know right now.

    I look back at my past work and laugh at how little I knew—but I still am proud of the work I did because I brought real value to the companies I worked for. I could probably do what took me 6 months at the beginning of my career in less than a week today. But I still did the work and helped my team. And what takes me 6 months right now I will probably be able to do in a week, if I were to try it 10 years from now.

    Keep your head up. I would wager that you are more qualified than you think.

  • Every hour you spent learning my friend, is 10 hours saved on a future project. It takes the amount of time it takes. I learned that the best feeling in the world besides complicated code compiling is actually finishing projects in a reasonable time frame.

  • I’m a teacher (I teach design) but I’m learning programming for my own fun at the moment. The advice I give to my students when it comes to study in general and more specifically when studying something that requires a lot of thinking, is to give yourself time away from the study. Like really give your brain time to process the stuff you’re learning.

    For me, I have a plan to make small games. Not for an App Store, but more as a personal challenge to myself. I’m not a natural programmer at all, but I love it. Some relatively simple concepts will have me wanting to punch my monitor but I’ve learned to stop, go and cook something or play the drums and let my brain get away from the code.

  • I definitely recommend either working on your own project (as others have suggested), or also just try modifying an existing project.

    If you’re into Video Games, there’s a great FOSS project called RomM which is basically a game manager website for roms. You could try to run the project locally, dig into the code, and add a new text field onto the site (maybe a link to HowLongToBeat?) From there, you could even tackle one of the issues. https://github.com/zurdi15/romm

    Obviously it could be any project that you are passionate about, but the point is that sometimes it’s better to understand someone else’s code base before doing something from scratch. Plus that’s a skill you will need to have when working as a JS developer.

  • Repeat after me: perfect is the enemy of good enough. Don’t let perfect be your enemy when good enough will do just fine. Obviously this doesn’t apply to everything in life always, but it 100% does here. It’s okay to not know how to build the most efficient, elegant version of something right now. I’m slowly learning R to make my life easier at work (research lab tech), and I’m just doing my best with what I’ve learned so far. I know that down the line when I’ve learned more or face bigger challenges that require more sophisticated tools, I’ll look back at the work I’m doing now and think ‘why the hell did I do it THAT way?!’ and that’s okay! The cool thing about code is that you can always go back and tinker with it. It’s not like woodworking where once the glue is dry, it’s set. Go easy on yourself, embrace being a clunky beginner, start doing things with what you’ve got.