AI Written Code and Making Assumptions

I’ve been writing some code for my own amusement the last few days. I have happily using Microsoft CoPilot to help me out. One really has to be careful with prompts though. CoPilot loves to make assumptions about what the developer desires. Often, it assumes correctly. Often enough, it assumes incorrectly.

I spent a good bit of time trying to figure how where it was doing some things I didn’t want done at all and other places where it got my intentions backwards. For example, we both had different ideas about what a variable called _defaultColor should refer to. That took me a bit.

I could have tried to ask CoPilot to fix the problem for me but if I had a better idea of how to express what I wanted it would probably have gotten things right, for my definition of right, the first time. So I fixed it myself.

I also made some assumptions about what certain methods were doing. I mostly assumed correctly but mostly is not really good enough when dealing with code. I really should have spent more time reading the code and making sure I understood it before trying to modify it. Yes, I said it before knowing how to read code is more important than ever.

Reading code on a screen can be painful though. One tends to get a sort of tunnel vision looking at little bits of code at a time. Many years ago I worked with a developer who had a terminal that was originally developed to typesetting at newspapers. It was tall and could hold a lot of lines of code. It was great for reading code. I don’t have anything like that. For me, the answer is printing listings out on paper. Maybe its just me but that is what has worked well for me for over 50 years of writing code.

I have more modifications I want to make to my program. I’ll spend some serious time reviewing the generated code before I try to make those modifications.

Related read: "Source code is the literature of computer scientists." https://www.cs.uni.edu/~wallingf/blog/archives/monthly/2025-12.html#e2025-12-26T18_28_37.htm A post by Eugene Wallingford

One other note, CoPilot added a lot of helpful error handling code to what I asked. That’s awesome in a lot of ways. I think that spotting a lot of error handling code may be something that tips off an educator that a student used artificial intelligence to write their code. Keep a look out and be sure to ask the student to explain it all.

How Much Debugging Knowledge Do CS Teachers Need

Mark Guzdial's blog is number one on my “must read” blog list. If you are a computer science educator it should be on your list as well. Mark had another particularly interesting post recently.

Dr. Tamara Nelson-Fromm defends her dissertation: What Debugging Looks like in Alternative Endpoints | Computing Ed Research - Guzdial's Take

In it, Mark talks about some of the work by his student, Tamara Nelson-Fromm. interesting stuff and I hope to read her papers when they come out next year. One question from Mark’s post really hit me:

“[W]hat does a K-12 teacher need to know about debugging?”

A partial answer given is “maybe it’s enough to just have checklists.” of things to check. Now “maybe” is a big word. I wonder how far it goes? That is to say, how often is a checklist enough? What happens when it isn’t enough?

I’m reminded of Kernighan's Law:

Everyone knows that debugging is twice as hard as writing a program in the first place. So if you’re as clever as you can be when you write it, how will you ever debug it?

Students write code that is as clever as they know how. If a teacher is more experienced and more knowledgeable than their students they maybe able to handle any problems the students have. The word “maybe” comes to play again. Over the years I have had a number of teachers approach me with a student program they could not debug. I’ve had to get help myself from time to time. Debugging is hard.

[As an aside, I love debugging code. It may be more fun for me than writing original code. I may also be weird.]

Experience helps of course. I have debugged student code without looking at the code. Lots of teachers have done the same. We do see a lot of students making the same errors year after year. Students are good at coming up with unique bugs though. They’re clever that way. (See Kernighan's Law) That’s where checklists are likely to come up short.

Why is this a problem? After all, students do, generally, fix the problem. Sometimes on their own and sometimes with help. For different definitions of “fix the problem” of course. There are always workarounds. That is especially true of the type of projects assigned to beginners.

My concerns start frustration levels. The cognitive load of learning to program is high already. Spending a lot of time on a bug can be very frustrating and that can be a turnoff for students. A demotivator. Worse, if the teacher can’t solve the problem what chance does the student have? Maybe programming is too hard!

Circling back to the teacher, if they don’t have a good plan for debugging than they are not likely to be able to teach students how to debug. Sure they can share checklists and that’s not a bad thing. Like most things, students will learn more by watching a teacher model debugging than from reading about it.

Now when we are teaching, most of us try to avoid making mistakes or creating code with bugs. Generally, we practice demos multiple times to make sure we can demo the code error free. Yay us, looking like we are amazing. The occasional error, planned or otherwise, is a teaching opportunity that should be welcomed however!

Circling back to the question asked earlier, how much should a k-12 CS teacher know about debugging? It’s hard to come up with a definitive answer. Probably more than is covered in most professional development though. Arguably, it should start with technical knowledge a good bit beyond staying a chapter ahead of the students. So more than a lot of teachers who have been voluntold to teach computer science have.

They should also have some solid experience reading code. Now a few years of teaching will give you some good experience reading code. It will give one a lot of experience seeing errors as well. That’s not much help for a beginner teacher though.

I’m not sure what the answer is and finding time in the already far to limited time for training that new teachers have now is a struggle as well. I am uncomfortable with the idea that “it’s enough to just have checklists.” though.

Teaching Reading Code–More Important Than Ever

Thanks to Facebook memories and a link that was almost a dead link I reread a post on my old blog – How To Read Code. It got me thinking about Artificial intelligence writing code. What? Let me explain.

If students are going to use AI to write code they are going to have to know how to read and understand it. There are several reasons for this. One is that AI almost never write 100% of the code necessary for a project. Without being able to read and understand the generated code students will be unlikely to be able to take the project to the finish.

Reading code for understanding can also be helpful to learning more about computer science. Not just coding but computer science. Code is the language of CS but there is a lot more to understanding computer science than just writing code.

AI systems have been trained on a wide variety of code samples from a wide variety of developers with a wide variety of coding styles. That means that students reading AI generated code, potentially, have exposure to more styles and techniques than their instructors are likely to show them.

Having students read explain the code they read can be a powerful tool for their learning and for teachers to use for evaluation. Keeping students from asking the AI to write the explanation is probably a good idea though.

All of this makes me think about code reviews (Archived blog post on that - The Art of the Code Review)  Organizing code reviews may also be a good teaching tool. Reviewing student code, AI generated code, or perhaps publicly available code examples on the internet. If AI can train on other people’s code why not students?

I am wondering what having an AI explain student code would look like. Would it help students understand their own code better? It might. I have seen a lot of students tossing different code snippets into a project hoping it would work but not really understanding what the code was doing. Would it also help them understand the process of reading code? Interesting idea I think.

Hardware–Heat and Cold

Not all computer problems are caused by software. Sometimes the hardware is the problem. It’s not always easy to tell where the blame lies. One underappreciated factor is the environment. Both mechanical and electronic parts are impacted by heat and cold. There is a reason that computer companies specify operating temperatures.

I think most people understand about overheating but maybe not the problems of to cold.

One day I received a support call from a customer. They were a tomato distributor receiving tomatoes and sending them to supermarkets and grocery stores all over New York City. The problem was that their computer did not work on Monday moorings. Monday afternoon was fine as was the rest of the week. Sure, people have trouble getting started on Mondays but computers should not care about days of the week.

Their computer used floppy disks. Now floppy disks were not sealed in vacuum and the read/write heads had to be a specific distance from the disks. I’d visited the company and knew something about the office. Most of the building was unheated for the good of the tomatoes. I asked if they ran the heat in the office over the weekend. The answer was “no.” The office got pretty cold over a winter weekend. The cold caused the parts of the computer, especially the disk read/write heads to contract pulling away from the disks. As the office  warmed up the tolerances returned to normal and the computer worked just fine.

Electronic parts get hotter as current runs through them. This can cause expansion which can cause all sorts of problems. That’s why fans are installed in computers – to keep things from getting to hot.

Back some years ago, Microsoft donated  a bunch of computers to a school. The computers had been purchased as part of an investigation into counterfeit software. Once the court case was over there was no need to keep the computers. Now these computers had been sitting in a warehouse for quite some time and not all of them were in perfect running order. I was one of several volunteers who were tasked with diagnosing and, hopefully, fixing some of these computers.

One of the computers had a note on it that said it was crashing at a certain part of the installation of Windows. Software problem? Perhaps. So I started an installation and sure enough the computer crashed at the noted location. I tried again but this time the computer crashed almost immediately. So probably not software. I opened up the computer and it seemed a little hot to me. And the fan was not working.

Aha! It turns out that one of the wires connected to the fan was not actually connected. The fan was not getting power and so was not running when the computer got hot. Connecting the wire fixed the problem and everything went perfectly.

It pays to be aware of environmental conditions both inside and outside the computer.

Coding With AIs Prompts Are Important

Last night, when I could not sleep, I got up and wrote some code. I added some features and data checking to my Wordle solver helper program. When I finished I felt good about my work and myself. I think that made it easier to get to sleep and I slept well.

It got me thinking this morning. When I was in university and still learning how to code I would occasionally get frustrated and feel less confident. So I would write some simple program to help me feel like I could actually code. I must have written code to display the multiplication table from 1 times 1 to 12 times 12 at least once a semester. It worked for me.

Now that is a trivial program but it involves nested loops (for me anyway) and I am not sure I would assign it to students today. It’s really a meaningless program in today’s world when everyone has a calculator app on the phone they don’t leave the house without.

I did wonder how an AI would write the code. So I opened the chat option in Bing and asked it “Write some C# code to display multiplication tables in a list box” It gave me some code that displayed this:

Not what I wanted at all. The problem is ambiguity! So I tried again with “Write some C# code to display the multiplication table from 1 times one to 12 times 12” and got this:

Not what I wanted either. So I specified at grid format “Write some C# code to display the multiplication table from 1 times one to 12 times 12 in a grid format”

This reply required a dataGridView object and the program did not work. Looks like I need to set up the dataGridView object in ways the AI did not explain. Now there is a problem worth thinking about. I asked Bing what settings I needed for the dataGridView and it gave me several. Program still did not work. At this point I gave up on the dataGridView option. It sort of feels like overkill anyway.

So I tried another prompt “Write some C# code to display the multiplication table from 1 times one to 12 times 12 in a grid format in a list box”

Finally I got what I wanted even though I am not thrilled with the formatting.

I’ve got a number of takeaways from this. Yes, students could use  these AI tools to get code for typical school assignments. On the  other hand, I think it would be fairly easy to tell when they do. The use of features that are not typically covered in class lectures or demos would be one clue.

It’s not always easy to provide the right prompts to the AI. Sometimes it takes some iteration. I think though, that teacher have to reduce ambiguity in assignment descriptions in many cases. Arguably some amount of ambiguity is helpful to allow for creativity. It can be a fine line,

As noted, I didn’t like to formatting so I did modify the code to get closer to what I wanted. I think programmers are going to be needed in a lot of cases to finish off what AIs generate. Both providing the right prompt and finishing off will be important skills for some time to come. Finishing off is going to require some serious skills in many cases BTW. Programming is not dead yet.

Book Recommendations for CS People

tl;dr Book recommendations:

• Overnight Code: The Life of Raye Montague, the Woman Who Revolutionized Naval Engineering
• Code Girls: The Untold Story of the American Women Code Breakers of World War II

Overnight Code was recommended to me after I recommended Code Girls on Facebook. Overnight Code is a truly inspiring story of a woman with two strikes against her (female and Black) whose hard work, determination, and talents helped her do some revolutionary work in naval engineering and integrating hardware/software systems.

Debugging code is arguably a lot harder than writing new code. Raye Montague was amazing at debugging code and integrating disparate systems. But also a good person who helped mentor and advance others. She was given tasks that others had said were impossible to complete. Talent and hard work (Raye had a lot of both) allowed her to accomplish beyond expectations.

There is a lot of good career and life advice woven into this story as well. Advice for everyone. I could have benefited from this book early in my career.

"Code Girls: The Untold Story of the American Women Code Breakers of World War II"  was recommended by several people in a Facebook group dealing with a Kindle Challenge that Amazon is running. The idea about code breaking sparked my interest right away. This book was more than just that though.

There were plenty of insights into code breaking but the look into the lives of these amazing women was the highlight. It was a different time and women would not as respected as they should have been. Yet, these women put their considerable talents into working for the war effort and their country.

Code breaking is a fascinating subject in itself of course. I enjoyed reading about the “bombe” machines, how they were created and used. I also found the difference that code breaking made in the conduct of the war (World War II) to be interesting. This is not the sort of thing many history courses cover.

It’s easy to label these books as books for Women’s History Month or the Raye Montague book as being for Black History Month but that would be a mistake. These are books for all year long. I recommend them to anyone interested in the progression of computing in society. Code Girls is a great read for cybersecurity or cryptography students. Overnight Code is a powerful read for anyone not just computer science people. It is just that inspiring.

Troubles with Error Messages

Error messages, in theory, are there to help programmers. Of course there are problems with then in practice. With students, the biggest problem is that  they don’t read the messages. I’ve long ago lost count of the times a student told me they had an error but can’t tell me what it is (or was) because they closed it without reading it.  Getting students to read the message and to try to work out the problem themselves can be a struggle but one we have to attempt.

Even if they do read the message, messages are not always clear. Have you seen this poem?

Roses are red
Violets are blue
Missing {
at Line 32

Seems simple enough but that can be deceiving. Often the message doesn’t actually give the right line. The reasons for this can be complicated for a beginner, or even an experienced programmer, to understand. It is a constant source of frustration.  At least one knows that a missing curly brace is (probably) the problem even if we are not really sure where it is missing from.

Other messages are less helpful because the programmer lacks knowledge to understand the words being used.  Or the message just does a poor job of explaining the problem.

Why are error messages less than helpful? Many reasons. One is that error messages are not fun and interesting to write. There are also strict limitations on the number of characters allowed. Still another is that the person writing the message is often so familiar with the software and the error that they write something that, while meaningful to them, is somewhat opaque to people newer to the software.

Reading error messages is not just a problem for students of course. When I was doing technical support for professional developers I would regularly get calls asking to explain an error message. A little secret here – a good explanation could often be found in the documentation! More than once I just looked up a message and read from the documentation. Even the explanation in the documentation needs a little help sometimes but it is a great place to start.

When teaching beginners we don’t often spend a lot of time on error handling which means we don’t spend much time talking about writing good error messages.  We do ask students to write messages in programs about games over and winning and losing. Occasionally we have to suggest rather strongly that an error message that calls the user “an idiot” is perhaps not appropriate.

Perhaps we should spend a bit more time on error handling and as part of that talk about good error messages. Maybe if we had beginners talking about the error messages they see from their systems and how they could do better we;d get better error messages later when (if) they turn professional?

Regardless, I think error messages should be a bigger part of the conversation. Reading them, researching what they mean, and thinking about how they could be done better.

Debugging–Slow is Smooth and Smooth is Fast

Mike Zamansky had an interesting post called  What They Used To Know that got me thinking about the old days. Now Mike is a youngster and didn’t really start in computers until the 1980s.  I started in the 1970s with punch cards and batch processing. That meant that there was no instant gratification seeing your program run.

With batch, one handed their cards to an operator and some time later, hours or maybe a day, one got their cards back with a listing that showed the results. Results usually meaning a list of errors that kept the program from running.

Desk checking, studying the listing and trying to fix as many errors as possible before trying again was a bit of an art form. To this day I will often print out a program to look at the big picture in a way that still doesn’t feel effective on a screen. It’s tempting to see that as a way to go – limited opportunities to have the computer check ones code.

There are downsides to this sort of thing though. Specifically, having limited runs or at least long waits between runs encourages writing large amounts of code at a time and discourages writing and testing small pieces of code regularly.

Being able to hit “compile” every other minute though tends to encourage, or at least support, the beginner tendency to “throw some code in and see what happens.” This wastes time in the long run and often leads to ugly, hard to maintain, and inefficient code.

The military has a saying that “slow is smooth and smooth is fast” that some what applies. Slowing down to really analyze code, think smoothly, generally leads to a faster result. Tossing code in on a wing and a prayer is not smooth but chaotic. Slowing down to really look at what is happening is smooth and looks slow to the casual viewer but leads to faster results.

As I was thinking tonight and asking, “what if we limited people to some limited number of compiles a day?” It seemed like a good idea until I thought of the possible problems. That’s when I realized that external controls on speed are not the answer. Rather the answer is for developers to regulate themselves. To slow down and focus in ordered to make faster progress.

What I miss and don’t miss about teaching

Fall has come and while students are back in school I am not. I’ve been reflecting a bit about that. I don’t miss getting up at 6 AM and driving for close to an hour to get to school. I don’t miss running my life by a bell schedule. I don’t miss grading, report cards, and other administrivia. I don’t miss classroom management issues.

On the other hand, I do miss interacting with students. I especially miss the interactions that take place outside of class. I miss the look, and sound, of students when they get a concept or when their program works – finally. I miss debugging student problems with programs or their project. Students are very good at finding ways to mess up a Visual Studio project. That’s the one big downside to using a professional tool. But I had fun putting things back together.

There are all sort of debugging issues that come up in the code. There is syntax issues (semi colon hide and seek anyone?) and logic problems. Both are fun little puzzles to solve. And I am sure there are still many that students have not discovered.

But the big miss is the students. I still think I retired at the right time for me.

I hope your school year is going well. I am following all sort of teacher/school things on social media and I know its not easy. Stay safe. And if you have a student program you can’t debug let me know.

More Fun With Live Coding

Live coding or as I like to call it coding without a net is a wonderful way to teach.There was a time when I thought that having prewritten code that was pasted in during a demo was a good thing. You see it a lot in demos at events for coding professionals. It turns out that in a marketing presentation that is fine and dandy but for teaching it just doesn’t work.For one thing, it moves to fast. Students can’t follow it all. And secondly, it avoids making mistakes.

It turns out that making mistakes is useful. When teachers make mistakes students feel less bad about making their own mistakes. Programmers make lots of mistake. Getting very upset or feeling inadequate when one makes a mistake is a sure fire way to get burned out very quickly. So seeing a teacher make a mistake can be comforting.

Of course, what is really important is how the teacher reacts to making a mistake. The obvious advantage to making a mistake is that the teacher gets to model how to fix the mistake. A teacher will, I hope, read the error message and then explain it to their students. For some  reason students have to be taught that reading the error message is helpful. That is strangely not intuitive.

I find that I make several kinds of errors regularly. The most common error is the typo. It’s amazing how poorly my keyboard it as typing what I mean. A great opportunity to point out that they computer is not as good at handling ambiguous spelling as people are. Typos are often a good reminder to slow down as well. Sometimes taking your time is the fast way of doing things.

I also get bit by the logic error. Now you would think that would not happen for a long time professional writing simple code for beginners. What tends to happen in real life is that the good idea fairy strikes in the middle of a demo and I decide to make the demo more interesting by adding something I have never added before.This turns into a great example of why planning BEFORE writing code is such a good idea. It is yet again a wonderful opportunity to model problem solving and debugging. Always take advantage of opportunities to model how to solve problems.

I teach several courses using several different programming languages so the other sort of problem I run into is using code for the wrong language. Visual Basic and C# (and JavaScript) declare variables differently and that seems to be a problem for me some days. As does remembering which languages use semi colons and which ones don’t. I haven;t figured out how to really take advantage of those errors. Any ideas? At least they don’t happen to often.

For me, I have decided to embrace the chances for mistakes. I’m not going to be afraid to make a mistake in front of my students. Life is to short and there is a legitimate upside to it. Now I have to make sure I can explain the error I made at the end of last class.

How Do Teachers Without CS Experience Debug Student Code

My Programming Honors students are wrapping up their semester projects today. Actually they should all have been handed in by now but I’ll give them until the end of the day. In any case, my students have come up with some interesting and difficult to solve bugs. One involved a png file that had an unexpected transparent  section. The other was more confusing and I’m not sure I could have solved it without a good bit of CS knowledge. Even then it was not obvious. (Long story short – passing addresses can be tricky )

I wonder how less experienced teachers handle the really hard debugging tasks. I’ve been writing code since 1972 and teaching beginners for about 15 years. I have seem a lot of errors. A LOT! Often I can debug code without even looking at it. Some errors are that common. And of course I have developed a lot of ideas about debugging. The debugger in Visual Studio is very familiar to me as is how to use it to narrow things down. Students are very good at finding new ways to mess things up though.

I saw a Facebook post from a teacher who has been assigned to teach AP CS A but who has no coding or CS experience. No, really, I’m not making this up. How in the world will they be able to help debug code? And forget about teaching/modeling debugging practices.

Over the years I have had a number of teachers ask me to help with debugging student code. I saw a very interesting recursion problem once. Doing a stack trace was key to that one.

Debugging may be the single biggest reason to say that one week crash courses are not enough for professional development of new CS teachers. A full semester course would be a good start but without experience a new teacher is going to be just barely staying ahead of their students.

But how to you teach debugging? Have you ever had a course or even just a class on debugging? I haven’t.  How would such a course run? Anyone know of a syllabus for a course like that?  I’ll have to think about that one. In the long run though they is no substitute for experience.

What does “doesn’t work” mean?

Every computer science teacher has heard it “My program doesn’t work. What is wrong with it?” Sometimes they will show you the code without any more explanation than “it doesn’t work.”  One generally replies with something like “define ‘doesn’t work.’” Or you are told the program is giving an error. When you ask “what error?” you get a blank stare. The student has shut the error message away without reading it. Somehow you, the teacher, are supposed to know the answer without really knowing the question.

Debugging seems to be the hardest thing to teach students. To be fair, debugging is hard. One quote on my bulletin board is:

“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”

- Brian Kernighan

There are a few good, and easy, places to start though. One of them is actually reading the error message. For some reason that doesn’t seem to occur to many students. Of course they often don’t read the directions either so I probably shouldn’t be surprised.

Giving some serious thought to the error message is often enough. To be fair, I like to be fair, some error messages are less than helpful. Helping students to understand the error message is better in the long term than just telling the student what they did wrong. Why do you think the computer doesn’t think that variable exists? Did you spell it right? Did you declare it in the wrong place? Remember when we talked about scope?

Another helpful technique is to explain what the program is supposed to do, how it is going wrong, and how you think the code is executing. Many teachers use the rubber duck scheme and ask students to explain all of this to the duck. This works for some people and some errors. I don’t have a classroom set of ducks but do have students explain that to peers. Sometimes that is enough. Sometimes it is not.

When they explain things to me I often prompt with questions. Often students are wrong in their explanations. I remember one student telling me that of course the code did something because here it was in the comments. There was no code to execute what the comment described but the student thought the compiler actually read the comments. Sigh.

In all cases it starts with knowing what should be happening and what is or is not happening. The more detailed one can explain that the easier debugging becomes.

Debugging Student Code for Fun and Learning

Students are really good at creating strange hard to solve bugs in their code. I am convinced that the code of a raw beginner can easily be harder to debug than that of a professional coder.

I had a couple of good ones today. One was actually pretty easy once I realized the cause. I have some international students. Great kids, very smart, hard workers. English is not their first language though. In fact, English letters are not their first character set. In one class I have boys from Cambodia and Viet Nam. The character sets they grew up with are very different from English characters. This means that sometimes English characters confuse them. l, I and 1 can all look alike to them especially in some fonts. Like this one. So I had some non obvious "spelling errors." They and I have a better idea of what to look for next time.

The other one was harder. We’re using C# and Windows Forms. Now normally this makes things easy. But you can also cause some very puzzling errors. In this case, the code seemed to be doing everything it was supposed to do EXCEPT showing the results in a list box. I tried a lot of my bag of tricks. Single stepping through code, displaying intermediate results (that didn’t work because nothing was displaying in the list box). I copied the code into a new project. I created new objects. I tried a lot of things.

Finally, I did a side by side comparison with a project that worked and that showed me the problem. For the curious, Windows Forms projects run a subroutine to initialize and instantiate the objects on the form. Some how, probably a copy paste error, this student was calling it twice. Without going into detail, this resulted in two sets of objects with one of them covering the set that was actually being acted upon for the display.

I try to look on the bright side of things. In this case, I have new things to look for that I didn’t have before, I have gained insight into issues that my international students have (and may change some variable names I use), and I got to demonstrate debugging techniques to some students. That’s a win right?

Programming is easy. Debugging is hard.

I may be in a minority in this but in some ways the most fun part of my job is debugging student code. Students are very clever at wring code that doesn’t work in obscure ways. Some how they manage to create errors that look like they are in one place but are really in a completely different place.

The end of the year involves a lot of debugging. Students know more ways to do things wrong than every before. It’s a lot of fun. No, really it is.

Now I know that letting students struggle with logic errors is sometimes (often? mostly?) a good thing. On the other hand they usually lack the experience to see the possibilities. In general I find that struggling students are focused on the wrong part of their code. At some point a teacher has to step in and help out a little.

Today I had a student working on a Pong program and it was not recognizing when the ball hit a paddle. He was looking at the speed of the ball, the arrangement of the code, the working of the if statements and generally focused on a lot of different code. The problem could not be with the IntersectsWith method of the rectangle class. That is part of the system library so it must work. Right?

Maybe we are not updating the location of the rectangle in the right place and time? Maybe we’re checking in the wrong place in the code? Maybe it is a timing problem?

In the end it turns out that all of the code was correct EXCEPT that he was updating the height and width when he should have been updating the width and height. Yes, the order of the parameters matters. I’m kicking myself that I didn’t check that first but at least I did think of it eventually. Next time I will check that first.

And to think I posted a somewhat related post last week (My Code is the Same as Yours But Mine Doesn’t work ) Sigh! I should have known better.

Student Programmer Fix This Code

Recently I came across this cartoon and shared it on Facebook.

Responses were interesting. The newer one was to programming the more likely people seemed to be to explain why the if statement wasn’t working correctly. The more experienced one was the more likely they were to point out that you probably shouldn’t have written that code (an option to kill humans) in the first place. There is some validity in both responses of course.

In teaching we often create code that is less than ideal to force a particular observation of a concept if less code. How often do we explain that to students? And how well does it take? I’m not sure but it does concern me.

Returning to asking students to debug code. I like the idea and it is something I want to do more of in the future. The problem comes when students don’t have enough experience yet to find the less obvious errors. On the other hand how will they get experience if we don’t let (make?) them practice debugging? Most debugging practice students get is on their own code. Often they are too close to it to see what is wrong.

Last semester I gave students code written by other students and asked them to test it. Most of the code worked as advertised and what students reported out was missing functionality rather than “broken” code. Maybe I need to write some broken code of my own and have students look at it?

How are you helping students learn to debug code? Any ideas to share please leave them in the comments.

BTW there is some discussion if asking students to debug code is better than asking them to write code on the new CS Educators Stack Exchange. You may want to join in there as well.