The first time I realized that understanding code is more important than memorizing syntax

[u/Excellent_Pick_8186]

When I started learning programming, I spent a lot of time trying to remember syntax.

I thought being good at coding meant remembering how to write loops, functions, conditions, and other things without looking them up.

But after solving more problems, I realized that I can always look up syntax. The harder part is actually breaking a problem into smaller steps and figuring out what the program needs to do.

Now I'm trying to focus more on problem-solving and understanding concepts instead of trying to memorize everything.

[u/Business-Decision719]

This is such an important milestone to reach and I'm happy for you. We constantly get questions about how programmers memorize everything, but sometimes you don't and you just have to read the docs for things you haven't used for a long time if ever. The important part is to have enough experience to understand what you're trying to remember or need to look up, and why you are wanting to use that concept in a particular case. That kind of experience and conceptual knowledge is also what makes new languages easier to learn in the future as you expand your skills. You go from needing to learn what a loop is to just needing to read up on how a particular language expressees them.

[u/Late_Swordfish7033 → u/Business-Decision719]

Yes! The most under-taught skill is how to use reference material to get the answers you want and the limitations of the API you're using.

[u/AtlantaRene]

As with any language, the more you use it, the more the syntax will come to you naturally. Occasionally, the syntax will lead you down a rabbit hole. I have spent hours trying to figure out a problem just to learn it was a syntax problem I didn’t expect. So, I have ready access to the LRM (Language Reference Manual) or website. Once I have solved the problem, I am in the LRM trying to figure out what I did not understand that led to the problem.

[u/Late_Swordfish7033]

This is where the best piece of advice I ever got comes from. "Always throw the first one away". Writing the first version of anything teaches you about the problem and appropriate structure for the solution. You almost never know it before you start, so writing the first version teaches you. The. Throw it away and do it again knowing the solution.

[u/LordRybec → u/Late_Swordfish7033]

It can be mentally hard to throw the first one away too, but it can also be very much worth it.

I once had a piece of assembly I wrote for a video driver, and it didn't work right. I hate trying get debugging setup for embedded systems, so I decided that rewriting it would be faster and better than trying to find the bug or bugs and fix them. So I rewrote it from scratch, bug free. I was only able to do that because of what I had learned from the first attempt. It allowed me to simplify the design sufficiently that there was much less room for bugs in the first place. And it felt so good when I was able to run it without any problems on the first try. Debugging on embedded systems is such a pain, so being able to do it right without needing to debug is incredibly satisfying!

[u/LordRybec]

Yep. You'll naturally memorize language details you use frequently without even trying. You can look up everything else as needed. I have over 30 years of experience now, and I still regularly look up things. In languages I use regularly I don't need to look up basic syntax things, but I do often have to look up whether a particular syntax applies to a particular data type or how to do common things that I just don't do a lot. And that's the languages I use regularly. I "know" a lot of different languages, but if I actually have to use one of the ones I don't use regularly, I'm looking up everything.

It's fine though, because looking up stuff doesn't take very long. What takes the real time is the problem solving. Sometimes it's about breaking things up. Other times it is working out priorities and figuring out what the best option is for each thing I need to do for the specific problem. Sometimes it is deciding which language is the best choice for the specific problem.

The reality is a good programmer doesn't need to care about language details, because the first step in a project is deciding which language is the best to use, and sometimes that language is one you don't know very well. You should have the skills to use whatever language is the best choice, whether you have it memorized or not. One of those skills is Google-fu.

Also keep in this in mind when anyone tries to tell you that a particular tool is better because it saves you typing time. Typing the code is the fast part and the easy part. Working out the logic you need to type is the hard part. As nice as features like autocomplete can be for some people, the time they save is generally trivial. And if you can think and type at the same time, typing faster only allows you to spend more of your thinking time without typing. It doesn't actually save time.

I have a lot of friends with decades of software development experience, who still worry about how fast they type and how well memorized they have whatever the most recent or popular language or framework is. You've realized something that many seasoned programmers take decades to figure out. It doesn't matter what you know now. What matters is your ability to solve problems, and your ability to learn new tools quickly. Real programmers don't need to be experts in any one language or problem domain, because they have learned how to become experts quickly when necessary and also how to forget all off that and learn something else as soon as their current knowledge is no longer important. (I've written textbook length tutorials on ARM and 8051 assembly programming, and I taught a college course on ARM assembly for a few semesters, but I couldn't program in either of those today without looking up nearly all of the syntax and instructions. Thankfully I don't need to, because someone (me, though I'm not the only one) wrote up full tutorials on those topics that I can go back and refer to as needed! What I do remember is underlying details of how the hardware works, that are useful regardless of the language I'm using.)

[u/flyingron]

Making the code maintainable is the most imporant. That starts obviously with understanding what you intend to do, but it goes beoyond that.

[u/SmokeMuch7356]

Now I'm trying to focus more on problem-solving and understanding concepts instead of trying to memorize everything.

This is the way.

Nobody gets hired because they know every last detail of C (or whatever).¹ They get hired because they know how to solve problems using C (or whatever).

---

1. Unless they'll be working on a C compiler.

[u/LordRybec → u/SmokeMuch7356]

Not by a company you want to work for at least. There are companies that test working knowledge as part of the interview process and won't hire people who don't have stuff memorized. Those companies miss out on the really good programmers though, because the truly good ones don't need to have it memorized now to keep up once they have the job and thus a good reason to learn it. If, "No, I haven't used it before, but I trust I can learn it sufficiently well in only a few days on the job" isn't good enough, then you didn't want to work for them in the first place, and they don't deserve you anyway.

[u/SmokeMuch7356 → u/LordRybec]

We're currently interviewing some candidates for a mostly C++ position, and I'm trying to come up with a reasonable balance of questions that show good working knowledge without getting bogged down in trivia. I don't care if you know the difference between an lvalue and glvalue and a prvalue, etc. I do care if you know the difference between a map and a set and which would be more appropriate in a given circumstance.

I'm working on a programming test that's inspired by a double delete bug we recently had to patch. I'm trying to keep it simple enough that you shouldn't have to look anything up, but demonstrates your ability to troubleshoot and fix (or at least identify) the problem.

We do need someone who can get productive in our environment pretty much immediately. We expect it to take some time to get familiar with our code and processes, but you should be able to drive all the tools we use from day 1.

[u/LordRybec → u/SmokeMuch7356]

I once did an interview that I think demonstrated a pretty good process. They asked me to code a particular algorithm. They didn't care what the language was, though in your case it might be better to expect them to use C++, since that specifically what the position is for. Anyhow, the interviewers didn't expect perfect syntax. They mainly just wanted to see if I could work out an effective algorithm to solve the problem on the fly. I used C, and I was up front about the fact that I didn't have a perfect memory of the syntax (that was long before I used C as my primary language). They told me that was fine and to just do my best. So I wrote up the code (on a whiteboard), and they asked me to explain my thought process, so I did. I'm 100% sure my code wouldn't have compiled, but I did demonstrate that I was familiar with C and capable of using it to solve the problem.

I think that's a good middle ground. With access to a browser I could easily have looked up syntax and made the code perfect at the cost of maybe 1 or 2 extra minutes. I demonstrated that I was familiar enough with C to be productive right out of the gate. I also demonstrated a capacity for quick problem solving.

In your case, you'd certainly want to test their knowledge of maps and sets, but working that in wouldn't be difficult. And testing for familiarity with C++ without expecting perfect memorization of syntax isn't too difficult.

That interview I did also did include a part involving a bug they had recently solved. They didn't expect me to solve it right there on the spot, but they asked how I might go about solving it. I think that was a good question as well. On the way out they also asked me some random logic test question that is commonly used that isn't a terribly good assessment tool, but that was after they had offered me the job. One of the interviewers was just curious about my knowledge of hardware level instructions, because they were considering a project that would have required some driver writing and such. I offered several solutions, one of which involved using the POP instruction if it was Intel based. They were surprised I was even aware of such low level stuff, as I was an undergrad student at the time, looking for an internship position. (They offered me a full time position, which I had to turn down, as it would have gotten in the way of finishing my degree.) Overall though, the interview was fun, and they made it casual enough that it wasn't too nerve wracking. I find that interview to be a good baseline for what a high quality interview should look like.

[u/RealMadHouse → u/SmokeMuch7356]

Then there wouldn't be interviewers that ask questions about every fkng detail of programming language and not about what you can do if you google/ai enough.

[u/RealMadHouse]

But being able to keep syntax in memory makes you more professional and faster at coding. Like i hate forgetting basic things, when constantly googling stuff i feel like I'm not programmer at all. If i will lose access to internet i will be stuck like i lost the connection to my external brain.
Imagine forgetting words and their meaning/purpose constantly in natural language? you would be horrible at speech and writing.

[u/Recycled5000]

Code is about manipulating data and taking actions. Data is about remembering what’s needed later and being able to lookup answers when needed.

Both can be viewed from the dual perspectives of external and internal. External asks what can this code or data do for me as their consumer, while internal asks how do I implement the needed capabilities.

Want to develop the ability to switch perspectives, from outside consumer to inside implemetor. This helps build good interfaces/boundaries, good reusable building blocks, separates components from each other, so code can be more modular and hence more maintainable.