コードを書いていて行き詰まったらどうする

I’ve been in this major for over two years, have taken some public courses and read some books, but my actual programming skill is extremely limited.

Recently, while working on rcore, I ran into a problem—when doing a certain lab, a few test cases just wouldn’t pass. After more than a dozen hours of heroic debugging, I gave up.

Why emphasize “heroic” above? Because all my debugging was ineffective; I just reread the documentation, asked friends in the group, and if I was lucky, I could spend one or two of those many hours on refactoring. If God were on my side, the test cases would pass smoothly. If luck is average, the remaining time is spent permuting various functions, repeatedly pressing arrow keys for a few minutes to run the test cases, mechanically repeating dozens of hours without any breakthroughs.

The castle I build in my mind never collapses—if I can run through a program’s data flow and underlying logic in my head, it will run. In reality, often I can’t; I can only have a vague sense: this function is probably used like this, that method would have this effect, this syntax is written roughly like that, and maybe tweaking that syntax a bit will make it work.

Junior classmates and friends sometimes think I’m impressive, but I’m really just a conventional learner; at most I’ve read one or two more books or watched some odd lecture videos than those around me. Anyone who has completed 61a or implemented gitlet for 61b could easily outclass me by miles.

Whether it’s rcore or anything else—61C, 61B, algorithms, even front‑end—I mostly just permute approaches that any layperson could think of with a tap on the head; at most it’s a simple printf, and being able to use a debugger is already the limit of my scant experience. Whenever I encounter a problem, I feel as helpless as a child in a math exam who can only write the word “solution” on the paper.

In the end, I can only resort to cheating by looking at others’ solutions, or just give up entirely.

Sometimes I wonder if I should start from the basics: like

「いいね!」 1

:disappointed_face: I (Fei) don’t even know what to answer. Based on personal experience, the most efficient way is to write while copying. To quickly get started with something, just write it directly. Although this makes the foundation unstable, the early feedback will be better.

Even though it’s not the same type, the mbt I’ve been working on recently is done by reading the documentation and mimicking others’ examples to add my own ideas, then using some of the thinking I learned while studying Go to implement those ideas.

Debugging requires taking time to slowly build your own process; whether you start as a cheater or slack off, it’s all about gradually getting familiar.

If the trouble becomes overwhelming, put it aside for a while, learn something else, and later see if you can use the new knowledge to understand the old problem.

op is already amazing

Seeing those group members writing OS often get stuck at one spot for a week, so time has never been a big issue

Thanks for your answer :_1_smiley:

rcoreDDL is too tight, and the members in the WeChat group are moving too fast, my mindset is a bit broken :smiling_face_with_tear:

:persevering_face::persevering_face::persevering_face: Comparing leads to a vicious cycle.

「いいね!」 1