Artificial intelligence (AI) continues to change many areas of our lives, with new AI technologies and software having the potential to significantly impact the way programming is taught at schools. In our seminar series this year, we’ve already heard about new AI code generators that can support and motivate young people when learning to code, AI tools that can create personalised Parson’s Problems, and research into how generative AI could improve young people’s understanding of program error messages.

At times, it can seem like everything is being automated with AI. However, there are some parts of learning to program that cannot (and probably should not) be automated, such as understanding errors in code and how to fix them. Manually typing code might not be necessary in the future, but it will still be crucial to understand the code that is being generated and how to improve and develop it. 

As important as debugging might be for the future of programming, it’s still often the task most disliked by novice programmers. Even if program error messages can be explained in the future or tools like LitterBox can flag bugs in an engaging way, actually fixing the issues involves time, effort, and resilience — which can be hard to come by at the end of a computing lesson in the late afternoon with 30 students crammed into an IT room. 

But what is it about debugging that young people find so hard, even when they’re given enough time to do it? And how can we make debugging a more motivating experience for young people? These are two of the questions that Laurie Gale, a PhD student at the Raspberry Pi Computing Education Research Centre, focused on in our July seminar.

Why do students find debugging hard?

Laurie has spent the past two years talking to teachers and students and developing tools (a visualiser of students’ programming behaviour and PRIMMDebug, a teaching process and tool for debugging) to understand why many secondary school students struggle with debugging. It has quickly become clear through his research that most issues are due to problematic debugging strategies and students’ negative experiences and attitudes.

When students first start learning how to program, they have to remember a vast amount of new information, such as different variables, concepts, and program designs. Utilising this knowledge is often challenging because they’re already busy juggling all the content they’ve previously learnt and the challenges of the programming task at hand. When error messages inevitably appear that are confusing or misunderstood, it can become extremely difficult to debug effectively. 

Given this information overload, students often don’t develop efficient strategies for debugging. When Laurie analysed the debugging efforts of 12- to 14-year-old secondary school students, he noticed some interesting differences between students who were more and less successful at debugging. While successful students generally seemed to make less frequent and more intentional changes, less successful students tinkered frequently with their broken programs, making one- or two-character edits before running the program again. In addition, the less successful students often ran the program soon after beginning the debugging exercise without allowing enough time to actually read the code and understand what it was meant to do. 

The issue with these behaviours was that they often resulted in students adding errors when changing the program, which then compounded and made debugging increasingly difficult with each run. 74% of students also resorted to spamming, pressing ‘run’ again and again without changing anything. This strategy resonated with many of our seminar attendees, who reported doing the same thing after becoming frustrated. 

Educators need to be aware of the negative consequences of students’ exasperating and often overwhelming experiences with debugging, especially if students are less confident in their programming skills to begin with. Even though spending 15 minutes on an exercise shows a remarkable level of tenaciousness and resilience, students’ attitudes to programming — and computing as a whole — can quickly go downhill if their strategies for identifying errors prove ineffective. Debugging becomes a vicious circle: if a student has negative experiences, they are less confident when having to bug-fix again in the future, which can lead to another set of unsuccessful attempts, which can further damage their confidence, and so on. Avoiding this downward spiral is essential. 

Approaches to help students engage with debugging

Laurie stresses the importance of understanding the cognitive challenges of debugging and using the right tools and techniques to empower students and support them in developing effective strategies.

Some ideas of how to improve debugging skills that were mentioned by Laurie and our attendees included:

• Using frame-based editing tools for novice programmers because such tools encourage students to focus on logical errors rather than accidental syntax errors, which can distract them from understanding the issues with the program. Teaching debugging should also go hand in hand with understanding programming syntax and using simple language. As one of our attendees put it, “You wouldn’t give novice readers a huge essay and ask them to find errors.”
• Making error messages more understandable, for example, by explaining them to students using Large Language Models.
• Teaching systematic debugging processes. There are several different approaches to doing this. One of our participants suggested using the scientific method (forming a hypothesis about what is going wrong, devising an experiment that will provide information to see whether the hypothesis is right, and iterating this process) to methodically understand the program and its bugs. 

Most importantly, debugging should not be a daunting or stressful experience. Everyone in the seminar agreed that creating a positive error culture is essential. 

Some ideas you could explore in your classroom include:

• Normalising errors: Stress how normal and important program errors are. Everyone encounters them — a professional software developer in our audience said that they spend about half of their time debugging. 
• Rewarding perseverance: Celebrate the effort, not just the outcome.
• Modelling how to fix errors: Let your students write buggy programs and attempt to debug them in front of the class.

In a welcoming classroom where students are given support and encouragement, debugging can be a rewarding experience. What may at first appear to be a failure — even a spectacular one — can be embraced as a valuable opportunity for learning. As a teacher in Laurie’s study said, “If something should have gone right and went badly wrong but somebody found something interesting on the way… you celebrate it. Take the fear out of it.” 

Watch the recording of Laurie’s presentation:

Join our next seminar

In our current seminar series, we are exploring how to teach programming with and without AI.

Join us at our next seminar on Tuesday, 12 November at 17:00–18:30 GMT to hear Nicholas Gardella (University of Virginia) discuss the effects of using tools like GitHub Copilot on the motivation, workload, emotion, and self-efficacy of novice programmers. To sign up and take part in the seminar, click the button below — we’ll then send you information about joining. We hope to see you there.

The schedule of our upcoming seminars is online. You can catch up on past seminars on our previous seminars and recordings page.

The post How to make debugging a positive experience for secondary school students appeared first on Raspberry Pi Foundation.

After an 11-month wait, giant pandas will populate the zoo once again. A pair of pandas, which left China on FedEx's "Panda Express" cargo jet, are expected to arrive in the D.C. area on Tuesday.

(Image credit: Jacquelyn Martin)

Organizations are grappling with the risks of having outdated hardware handling core workloads, mission-critical applications no one knows how to update or maintain, and systems that IT and security teams don't know about.

Has your dentist ever told you that it's recommended to get routine dental X-rays every year? My (former) dentist's office did this year—in writing, even. And they claimed that the recommendation came from the American Dental Association.

It's a common refrain from dentists, but it's false. The American Dental Association does not recommend annual routine X-rays. And this is not new; it's been that way for well over a decade.

The association's guidelines from 2012 recommended that adults who don't have an increased risk of dental caries (myself included) need only bitewing X-rays of the back teeth every two to three years. Even people with a higher risk of caries can go as long as 18 months between bitewings. The guidelines also note that X-rays should not be preemptively used to look for problems: "Radiographic screening for the purpose of detecting disease before clinical examination should not be performed," the guidelines read. In other words, dentists are supposed to examine your teeth before they take any X-rays.

Read full article

Comments

Not (yet) an expert on BPF? No worries! We have you covered at P99 CONF, with a range of presentations that reveal just how powerful this technology is. The real beauty of the extended Berkeley Packet Filter lies in its ability to add custom functionality to the Linux kernel without modifying source code or introducing additional overheads. In other words, eBPF gives you the ability to monitor, observe and even optimize performance of systems while they are running.

Let’s take a look at four talks each of which explores innovative ways of applying eBPF to different system challenges. Starting with Liz Rice with a follow up presentation from last year, this year we will hear about …

Zero-overhead container networking with eBPF and Netkit

Liz Rice (Isovalent at Cisco)

Netkit is a new enhancement to eBPF that replaces the virtual Ethernet (veth) connections that previously connected containers to the network namespace of their host. Until now, the overhead of veth connections meant that containerized applications could not communicate as quickly as if they were running directly on the host. In this talk you’ll learn how Netkit and other eBPF-enabled capabilities now allow container networking to run as fast as host networking.

Bonus reading: Get the complete O’Reilly Learning eBPF book that Liz wrote; it’s free, compliments of Isolvalent.

Scheduler Tracing With ftrace + eBPF

Jason Rahman (Microsoft)

Understanding application latency requires understanding the underlying layers of the system. The operating system scheduler is one of those layers which impacts application latency and performance. Here, we’ll learn how to leverage both ftrace and eBPF (along with Perfetto for visualization) to capture the runtime behavior of the Linux scheduler. Along the way we’ll explore some interesting quirks (arguably bugs) in the existing CFS scheduler, and also begin exploring the new EEVDF scheduler appearing in recent Linux kernels.

Bonus reading: Read Jason’s blog “Intel CPU Die Topology,” where he looks at a pair of Intel CPUs and observes a few key details on their on-die interconnect topology and impact on cross-core communication patterns.

Using eBPF Off-CPU Sampling to See What Your DBs are Really Waiting For

Tanel Poder

At P99 CONF 23, I introduced the general concept of using eBPF-populated Task State Arrays to keep track of all Linux applications’ (including database engines) thread states and activity without relying on the built-in instrumentation of the application. For example, the “wait events” built into database engines are not perfect; some voluntary waits (system calls) are not properly instrumented in all database engines. There are also other involuntary waits caused by OS-level issues, like memory allocation stalls, CPU queuing, and task scheduler glitches. This year, I will show the latest eBPF-based “xcapture” tool in practical use, measuring where MySQL, Postgres, and DuckDB really spend their time, both when on CPU and sleeping. All this can be done without having to change any source code of the database engine or applications running on it.

Bonus reading: Browse Tanel’s 0x.tools site and see the discussion it sparked on Hacker News.

Noisy Neighbor Detection with eBPF

Jose Fernandez (Netflix)

In multi-tenant environments, performance issues often arise from the “noisy neighbor” problem, where one container’s excessive CPU usage degrades the performance of adjacent containers. At Netflix, we’ve developed a low-overhead solution leveraging eBPF to continuously instrument the Linux scheduler and detect these issues in real time. This talk will explore how eBPF is used to monitor run queue latency, associate process IDs with cgroup IDs, and emit actionable metrics. Attendees will gain insights into the implementation details, optimization techniques for eBPF code, and how this approach ensures high performance and reliability in a shared compute environment, offering practical guidance for similar applications in their infrastructures.

Bonus reading: Read the Netflix blog that Jose recently co-authored on “Noisy Neighbor Detection with eBPF” and review the Hacker News discussion.

The post 4 eBPF Tech Talks at P99 CONF: Optimization on the Fly appeared first on P99 CONF.

A question I often get is, how do you get experience in IT? For people trying to break into this industry, what can they do to gain experience? How can they showcase that experience to a potential employer even if they are applying for their first job? Breaking into a new industry can be the most difficult thing, you lack experience and most of all you probably lack a network. Here are my thoughts on how you can gain that experience.

University studies

The ROI on university studies will vary depending on if you live in a country like me where studies are financed by tax and there is no tuition, or in a country where it can be very costly. That’s not the argument here, university studies can give some things that is difficult to achieve in any other way. I did three years at a university and here’s why I think it’s really valuable.

Time – Having two or three years of dedicated studies is a luxury you won’t have at any other point in your career. You have a full-time job and trying to learn a new discipline on top of that is going to be much tougher. At the university, you’re one job is to study.

Hands-on – My university was also a Cisco networking academy. I did all the curriculum of CCNA and CCNP and we had physical labs with all the equipment needed such as routers and switches and computers. Building your first lab can be costly and complicated. I had plenty of hands-on training during my studies.

Internship – Initially, I was going to study for two years, six months consisted of internship at local companies, two times three months at two different companies. This means that I had the opportunity of applying the skills I was learning in real work environments. I also started building my network by getting to know people. Some of my fellow students ended up getting their first job at the internship.

Soft skills – The ability to write and present to others is something you get plenty of practice at the university. Don’t underestimate this as this is often that decides how far you go in your career.

The university is not for everyone, but by the time I graduated I already had three years of experience (to some degree), which is going to be better than someone with no experience.

Self studies

You don’t have to go to a university to study. You can, and should, study on your own. This is something that you will need to master for a career in IT anyway. You might for example decide to start with the CCNA. It’s really important to build a strong foundation of the fundamentals. Don’t rush through it, take your time and build a strong foundation that you will benefit from later. Get as much hands-on as you can by using a combination of virtual labs and optionally physical gear. A lot of labs can be virtualized, but if you are going to work in IT you also need to have seen what the devices look like and get some actual hands-on with the physical gear. Coming to an interview and showing that you have studied for and achieved a certification on your own, will demonstrate your commitment to breaking into the field.

Volunteering

Before you’re an established IT professional, people aren’t likely to want to pay for your services. How do you get experience? One way is to do volunteering. There’s plenty of churches, organizations, and smaller companies that need help, but don’t have much funds to pay for it. Even if these IT environments are small, much of the knowledge you gain from working in these environments is applicable also at bigger companies. You gain experience while also doing a good deed, I’d call that a win!

Helpdesk/NOC

You’re probably not going to land a job such as network administrator for your very first job. What you should be doing is trying to get a foot in, anywhere. Being in helpdesk or a NOC is no bed of roses, but you will get exposed to a multitude of things that you will benefit from later. Even if networks is your passion, you need to have some other skills as well, such as some knowledge around operating systems, applications, and so on. It can be strategic to work at a helpdesk at a big company where they also have specialized roles. If you do a good job in helpdesk, it’s much more likely you can get promoted to a networking job, for example, rather than applying from the outside.

Online communities

Online communities is a great way of studying and finding peers to study with. Many of the people that are now my friends, or at high positions at various vendors, are people I got to know by contributing to different online communities. Some of the online communities are geared towards people that are studying, some are more geared towards issues that people are having at their jobs. Both of them are really useful. You can learn a lot from seeing what type of issues people are having. Can you solve the problem they’re having? You practice your troubleshooting skills by helping others, then also learning yourself, and you start to network with other people. Perhaps this is the person that will help you land your first job?

Blogging/videos

When you’re applying for a job, your potential employer is most likely going to do an online search for you. What you don’t want to happen is that they either find you in places where you shouldn’t be, or that they find nothing. Both could be seen as red flags. It’s trivial these days to start a blog or YouTube channel. You’re a person with no experience in IT, what value does your perspective bring? Is something you might be thinking. It could be very interesting for others in the same position to get your perspective on what you’re doing to break into a new field. What’s your strategy? What are your focus areas? If you share that knowledge as you learn yourself, that’s going to provide a lot of value for both parties. You will also hone those soft skills. When someone does a search for you, they’ll see that you’re working hard on establishing yourself in a new field.

Contributing code

Even if you’re not applying for a programming role, it can be valuable to have a presence at places like GitHub. You could for example be contributing code to open source projects or displaying your own code that you’ve used to solve a problem. By contributing to projects you’ll get experience working with others and they may also be able to help you to land a job if you show proficiency at coding.

Closing words

Getting that first job is difficult. Anyone saying anything else is most likely a grifter, or got lucky landing their first job. My first job I got through a friend I had studied with in the past. I wouldn’t have gotten it if I didn’t put my heart into my studies, though. To land that first job, you need to do anything that you can to build experience and also a network of people that want to help you get that first job.

I’m curious to hear what other venues there are to building experience. Please put a comment with what you did and how you landed your first job.