DEV Community: Jemma

The AI pitfall while learning C

Jemma — Mon, 13 Apr 2026 05:29:18 +0000

I’m currently learning C programming, and I’m going to be completely transparent and say that I’ve been struggling to stick to the recommended timeline. The coursework states that some of the projects should only take 1.5 hours. Me? Two months later, finally figuring it out.
The project I’m specifically referring to required creating a program that played poker. You give it two hands of cards, then it figures out the ranking of each hand, compares them, and decides which hand wins.
Another confession—and one I’m ashamed to say: in moments of desperation, I pasted my code into AI (Chat365 Copilot) and asked what was wrong with my program. I found this quite useful for smaller syntax errors and logic issues around edge cases, but it was also a huge pitfall for me, and I’ll tell you why.
AI is not always correct. It introduces syntax, library functions, and concepts that I haven’t covered yet in my course and don’t yet understand, and it doesn’t register the assumptions that are part of the course assignment. This led to countless arguments (and so much wasted time) with AI about what it was getting wrong, what the assumptions were, and what I should use versus what I should ignore from the AI-generated output.
I also found that copy-pasting snippets of AI-generated code into my program would fix some issues but create others. Then, because some of the code was outside my understanding, debugging was impossible. I ended up removing all the AI-generated code and redoing the project from scratch on my own—again. This was a journey, and I honestly don’t know who could do it in 1.5 hours, but they must be a genius!
I came to the conclusion that AI has its place and can be quite handy for jogging one’s memory, hinting at edge cases, or clarifying syntax. However, when it comes to the bulk of a project (especially when studying) I need to do the hard yards and take the time to figure things out on my own. It’s slow going, but the learning sticks and actually saves time in the long run.

Hello all, I tend to get imposter syndrome. When can I legitimately start telling people that I'm a computer programmer? When I've finished a course? When I've built my first project? When I've done my first paid job?

Jemma — Fri, 27 Feb 2026 06:31:03 +0000

Reframing recursive functions

Jemma — Wed, 25 Feb 2026 22:13:59 +0000

I’ve been learning about recursive functions lately (functions that call themselves), and at first they felt pretty overwhelming. Trying to keep track of what happens in the first call, then the second, third, and so on — plus figuring out which values get passed where and when the arithmetic happens — felt confusing.
For a while, I really struggled with even simple recursive problems because I kept trying to hold everything in my head at once, and it just wasn’t working. After experimenting with different approaches, I finally found a method that helps me make sense of recursion. If you’re finding recursion tricky too, I hope these tips are useful.
Think of each recursive call as creating a new stack frame.
Just like any normal function call, each recursive call gets its own space in memory. Draw a little box for each call and write down the variables and their values for that frame.
Remember that none of the stack frames disappear until the base case is reached.
Every call waits for the next one to return before it can finish. This follows the exact same rules as any other function — nothing magical or different is happening.
At the end of the day, recursive functions behave like normal functions.
The name might make them feel intimidating, but the underlying mechanics are familiar. If you carefully track each stack frame as calls are made, recursion becomes much easier to reason about.
Good luck, and don’t give up on recursion — once it clicks, it becomes a really powerful tool!

Hindsight is 20/20

Jemma — Tue, 10 Feb 2026 02:10:56 +0000

I'm going to take a wild stab in the dark here and guess that every single one of us has made a programming error, and when you finally figured out the problem, you thought to yourself 'what an idiot I am!'.
Well...that was me this week.
I'm going to share the course project I worked on, and what mistake I made which had me face palming.

My project was to write a function which took an array and array size and return the length of the longest sequence of increasing values.
It didn't matter if they were consecutive or any other pattern, as long as they were increasing. e.g. for array[] = {1,2,3,0,8,50,55,70). The longest sequence of increasing values would be 5 (0, 8,50,55,70).

My code succeeded with all the test parameters passed to it until it came to grading time where it failed.
This was my failed code.

`#include

int maxSeq(int *array, int n) {
int counter = 1;
int max = 0;

if (n == 0) {
    return 0;
}
if (n == 1) {
    return 1;
}
for (int i = 1; i < n; i++) {
    if (array[i] > array [i-1]) {
        counter++;
        if (counter > max) {
            max = counter;
        }
    }
    else {
        counter = 1;
    }
}
return max;

It took me a long time to figure out the problem. Even then, only by re-writing the programs in Clion IDE and running through numerous test cases.
I discovered that I had not accounted for situations where the program had not entered into the first if statement of the for loop. In that situation, max remains at its initialized value of 0. e.g. array [] = {2,2,2,2}

Corrected code
`#include

int maxSeq(int *array, int n) {
int counter = 1;
int max = 0;

if (n == 0) {
    return 0;
}
if (n == 1) {
    return 1;
}
for (int i = 1; i < n; i++) {
    if (array[i] > array [i-1]) {
        counter++;
        if (counter > max) {
            max = counter;
        }
    }
    else {
        counter = 1;
    }
}

if (counter > max) {
max = counter;
}

return max;

When I finally figured it out, I felt like a complete idiot. I had to remind myself that hindsight is 20/20 and that it's all part of the learning curve. Also, I could have put more effort into testing with all the corner cases I could think of. Be thorough, even when the code seems simple enough.

How a simple pointer exercise had me pulling my hair out.

Jemma — Fri, 30 Jan 2026 21:31:18 +0000

I was tasked to write out (by hand) the outputs for a given pointer exercise. It seemed simple enough, but when I got to a certain stage, I found myself lost. And the harder I thought, the deeper I went down a rabbit hole of confusion. Asking for AI did not help.
I will give the example that stumped me, some of the mistakes I made, why they were wrong and the principles that I learned from this experience.
Spoiler, in the end I went back to the introduction to pointers in my course material, and thinking in this simplistic way decluttered my brain and the answer became clear.

Here is the code;

`
int f(int** r, int** s) {
int temp = r;
int temp2 = **s;
int *z = *r;
*r = *s;
*s = z;
printf("r = %d\n", r);
printf("s = %d\n", **s);
*z += 3;
**s -= 8;
**r -= 19;
return temp + temp2;
}

int main(void) {
int a = 80;
int b = 12;
int *p = &a;
int *q = &b;
int x = f(&p, &q);
printf("x = %d\n", x);
printf("*p = %d\n", *p);
printf("*q = %d\n", *q);
printf("a = %d\n", a);
printf("b = %d\n", b);
return EXIT_SUCCESS;
}
`

This code will output the following.
**r = 12
**s = 80
x = 92
*p = -7
*q = 75
a = 75
b = -7

These are the mistakes I made;
I returned an int value of 64 (not 92) back to main from function f. In lines 5 and 6, the pointers are dereferenced to the int values of 80 and 12 respectively. But I mistakenly believed that the arithmetic on **r and **s affected the final value of temp and temp2 not realizing that those initializations in lines 5 and 6 are locked into the memory addresses of temp and temp2 and to manipulate those values I would need to explicitly perform arithmetic on temp and temp2. e.g. temp += 3.

Again, I changed the wrong addresses. Instead of changing what *r and *s points to within the function f stack, I changed what *p and *q point to in the main stack.

Finally, I forgot that *z was a pointer to an int. So, I was thinking that I had to perform arithmetic on the address at *p. So, I believed that *z += 3 meant *z = &p + 3. My thinking was that if I was supposed to perform arithmetic on int a, then the expression at line 7 would be *z = **r. This one got me so confused and going around in circles.

My take-aways;
Go back to basics.
Write out every step, even if it seems straight forward or insignificant.
Remember what the type is
Visualize the memory addresses

Grassroots for the green

Jemma — Mon, 19 Jan 2026 06:01:28 +0000

I'm a female, mid-career forestry machine engineer with 15+ years' experience in my field. I've had my fair share of challenges to get where I am, but nothing quite as daunting as hacking into the world of computer programming.
The amount of strange jargon and odd rules can feel endless. It turns out that = doesn't actually mean =, and git is not just a British insult.
However, I'm doing an 'Introductory C Programming' series of courses through Duke University via Coursera. This is a grassroots course that not only looks at syntax but takes a few extra steps back before writing any code. It covers best practices for developing algorithms and emphasizes that code development is 90% planning and shows how to do so in seven simple steps.

If you're green, I highly recommend it.

https://www.coursera.org/specializations/c-programming