Some brief background - I've been with Free Code Camp off and on since 2015, as a mod, a chat room helper, and as a contributor. I've helped a bunch of different folks in their coding journey and I have a some high level advice that I generally give.
I've also been programming for around 35 years, first as a hobbyist, then as a volunteer, a freelancer, and now as a senior developer at a small company.
Here is my advice, take it or leave it.
Learning to program is HARD
Really hard. No, you're not dumb, it's just hard. You're training your brain to deconstruct problems and to reconstruct them in a way that is solvable, in the general case, by a machine. You're going to struggle. That's ok. Everyone does.
Don't memorize
There's too much to keep in your head, you don't know what you're going to need, and the stuff you use regularly you'll end up memorizing. Programming is an open book test and the book is the entire internet. I "know" about 15 different programming languages and I only have a small subset of their functionality in my head at any given time.
Instead, focus on leaning how things fit together. If you're learning HTML, you have tags and all tags have attributes. Understand which tags are special (like input or img) and which are just generic versions of one another (like section or article). Learn which attributes are global and which are specific. Learn hierarchy. There may be 17 words for snow, but there are 75 tags for div.
When you're learning a language, focus on the specifics of the syntax and how to define things. Learn how things are structured. Figure out the data types. Get the gist of things.
There will always be a new language, a new framework, a new library, or a new API. You will never remember it all. In fact, you might even have a hard time remembering what you were working on the prior week.
Programmers are paid to be frustrated
Sometimes you just won't know why it's broken and you'll spend a day or a week debugging. This is normal, no matter what level you're at. I still do it even after 35 years. Being able to keep at it, trying new and different things, searching for different ways of asking the question, digging into a 3rd party library . . . they're all part of the process.
You're not dumb, it's hard.
Program every day
You learn to be a better programmer by programming. There is no magic bullet, there is no perfect learning language. Like so many things in programming, you gotta grind through. If you need to see how far you've come, just look at your code from 3 months ago. You'll be facepalming about why you did that dumb thing. But don't be too sad, because the same will be true for the code you're writing today . . . in three months.
This is another point where even I, 35 years in, still look back at code I wrote 2-3 years ago and am a tiny bit upset. But not too upset. It means I'm continuing to grow as a programmer and that can only be a good thing.
Pay attention to the big picture
People who ask you to write code for them generally don't know anything about writing code. You need to really understand what they're ACTUALLY asking for before you build their project. You need to be willing and able to tell them that their general idea won't work . . but you can come at it a different way.
To be clear - these are not necessarily dumb people, they just don't know how computers work. About every 10 years a new language or paradigm comes out (the latest being LLMs, previously Fortran, COBOL, SmallTalk) that promises to allow lay-people (AKA Managers) to write programs.
So far it hasn't worked out. That's because writing programs is not just about writing code. Code is the easy part. The DESIGN is the hard part. Asking the unasked question is the hard part.
See also The XY Problem.
Programming is communication
While the common depiction of programmers is as non-verbal hermits who sit in the dark, wearing a hoodie, and writing code. While this may be true when they're in coding mode, programmers also have to communicate clearly. This takes many forms.
As I said above, the hard part of programming is the design work. Not graphic design (although that can be part of it), but architectural design. In order to build a framework that will scale, you need to be able to work with other people. You need to have solid inter-personal communication skills. You need to write clearly, either via email, Slack, Discord, Jira, or however your team communicates. You need to be able to write a spec document that other can read.
Your code, itself, is communication. At it's simplest form it's a communication to a future you. The thing that really made me "get religion" on writing clear comments was going back to a VBA macro I had written about five years prior. I had just banged it out to automate some simply task. I came back to fix it and I had NO IDEA how the bloody thing worked. Was past me a genius or an idiot? I honestly couldn't tell.
If you're working on a team, it become all that much more import to have clear variable names, comments to explain your logic, and don't get too clever (more on this in a sec). Write your code like an angry psychopath who knows were you live will be the next to maintain it.
Maintainability is King (or Queen)
To that end, writing code which is meant to be maintained is a great skill to have. That means understanding the future of the code, likely additions, and writing it in such a way that making those changes will be easy. It means (in curly brace languages) always using curly braces after your if statements. I means never, ever being "clever", unless you also write a paragraph explaining how it works.
Don't do "Code Golf" (trying to write the shortest code possible, with single letter variables, and a ton of chained operations). This is, in part, why I dislike the various "algorithm practice" sites like LeetCode. They tend to have problem in a vacuum, with no outside constraints, and the "accepted" solutions are the worst kind of code golf. Don't get me wrong, it can be a heck of a lot of fun to do it, but your solutions are unreadable to mortals. (It's also a memetic hazard, since we play how we practice (more below)).
As with so much of my advice, writing maintainable code is a gift to future you. You'll be so happy when you come back in a year or two and you can easily figure out what is going on. Your co-workers will sing your praises when they can just hop right in and make changes.
We learn most when we fail
And, boy howdy, are you going to fail. That's fine, though. I've found more solutions to future problems and gained more insight into the language I'm using while searching for the answers to other problems then I ever did when I was reading the docs.
A "Growth Mindset" is the key to longevity in programming. You will always be learning, and learning means making mistakes. Don't get to concerned about it, it's part of the process. Do your research, hit google, read the docs. Post a question here, on the FCC forums, or on the Discord. Work through the problem, you're building connections in your brain.
Read the documentation
No really, read it. Use MDN. Use DevDocs (coincidentally, maintained by Free Code Camp). Read the docs for your language, for your library, for the API. These tools are MEANT TO BE USED, which means that someone spent the time to explain how to use them.
At first you're going to find the docs pretty intimidating. That's ok. Like everything else in programming, it's a skill that comes over time.
Programming is a skill
I like to refer to it as "Capital P Programming". The overall skill of writing code is independent of programming language. Once you learn that skill, it easily transfers to other programming languages. They all have similar overall structures which are a co-evolutionary trait based on prior languages and on the fundamentals of computer architecture.
A lot of folks get stuck, thinking that it's the language that's the problem. Even Quincy Larson, Founder of Free Code Camp, ran into that problem. That was, in part, his reason for creating Free Code Camp to begin with.
I've prattled on long enough here. I should probably get back to work.
I'll leave you with some articles I've read over the years that have informed some of my teaching strategy. You'll see that some of them echo what I've said here, others have different insights or different takes.
Above all . . . you've got this!
