What's the best way to teach problem-solving skills to newcomer developers?

General
1

In recent years, I’ve noticed a growing number of new game devs, including a few who have reached out to me for help in the past. I’m genuinely happy to see more people getting into programming and game development, but I noticed a concerning trend among many of them.

While they’re great at following tutorials or examples, they often struggle when faced with even minor issues. Sometimes, their IDE provides clear error messages explaining exactly what’s wrong and how to fix it, yet they still get completely stuck. It’s as if they shut down entirely, avoiding any attempt to debug or troubleshoot the problem on their own. Instead, they immediately ask me or others to fix it for them. I’ve tried encouraging them to read the error messages, think about what they mean, or undo their recent additions to their code to identify what caused the issue. While this approach has worked a few times, many still revert to ignoring the information and relying on others to solve their problems.

Does anyone have any tried and true methods for teaching newcomer devs on how to solve and break down problems themselves?

1 Like
2

It’s a language-agnostic issue that isn’t specific to Godot or engines in general. I’m a long-time IT infrastructure person who at most made scripts in Powershell/Bash/Cloud CLIs for automation and alerting, but not really “programming” per se, let alone actual software architecting/engineering. I’ve only just started taking on more programming-heavy tasks the past ~2 years and still learning a lot when it comes to conceptualization, maintainable structures, etc.

But one thing that persists from IT is troubleshooting and problem-solving which entails a lot of your suggestions:

I’ve tried encouraging them to read the error messages, think about what they mean, or undo their recent additions to their code to identify what caused the issue. While this approach has worked a few times, many still revert to ignoring the information and relying on others to solve their problems.

What type of audience is exhibiting this behavior? Back when I was in education running computer clubs doing Scratch, Visual Basic, etc. with middle/high schoolers this behavior just really sussed out either (1) Those who would be better suited to have more fun/growth in another club, or (2) The differences in capabilities between each member. I had some all-star animators who would go a whole session without 0% progress on math-based/logic-based programming, but there were all-stars in those domains and they cross-pollinated work. I typically only ever recommended club swaps to 1-2 kids a semester, so for me it was moreso them finding their niche.

The benefit I had in IT training early on was labs and simulated issues, you could give known-broken projects for them to fix or similar. Also maybe take a step back and givem a real good exercise on print()/err() statements, making them human-readable, where user:// is at, etc. For more nitty gritty examples it’s hard to teach no matter what, when I’m working on Godot TCP projects I bring out Packet Sender + Wireshark for validation, but that’s a lot to ask from just a developer perspective.

2 Likes
3

Seen it from people on this forum, a few friends I have online, and one friend I know irl who recently wanted to start making games as a hobby, and he’s the one I’ve been doing my best to mentor. He has no programming experience or background at all, but I don’t know that for others online.

I can imagine this being something most people struggle with when they start programming for the first time, and while GDScript does seem to make it easier for people to get into it, often times the error messages given by Godot are completely ignored sadly.

4

Really interesting you post this.

I was going to start making youtube tutorials AND written tutorials on this very subject.

Coming from some major software development experience, compilers, ui components, system development, audio apps, etc. I know that understanding systems is a major part of software development.

What I wanted to focus on is teaching devs how to see the whole picture, the systems and understanding connections.

I think OOP design patterns teach this through experience because in the start a dev will use them WAY too much and then you introduce refactoring. I think the two together show the yin and yang of actually creating a piece of software.

Creating a foundation to refactor leads to understanding why for instance you want unit tests. It’s not that you are wasting time, you are getting the ability to abstract your thoughts into small chunks of non dependency.

For example, the giving up part, this is like they are getting lost in the maze and the mind shuts down, with proper training in design and assembly, there is no lost feeling because you are aggregating the development experience into proper iterative chunks.

I really think this is a lost art that needs to be reintroduced to create concrete experiences, even with game development.

What I have noticed in my decades journey is, most shy away from some simple UML, tests, etc, but when you practice this, you can actually speed up because the way you develop works as fast as your motivated brain because you have correctly created aggregates of information and systems.

Anyway, ramble off for now. :slight_smile:

Peace.

4 Likes
5

Debugging is it’s own tough skill, and I feel Godot’s error messages are very bad, plus code warnings only show in-editor as a tiny triangle in the corner. I think a checklist for common errors would do very well. “Invalid assignment … on base object of type ‘Nil’.” comes up so often, but it’s so rare that the object is null for the same reason. @exports could be left un-assigned, @onready could be triggered when a sibling isn’t ready (especially with Globals), the object could’ve just been queue_free()'d!

I’ve noticed my younger students are usually more privy to trying things, where older students will be hesitant, they fear losing progress if anything get more messed up. It’s also common behaviour with tech, if you aren’t a programmer and you get a error message; click close it! it’s broken!

Make sure your students know that a error message is the machine working with you, not against. And set up backups or version control early, create a space that allows mistakes, more than just your undo history.

4 Likes
6

Screen sharing is the most effective way of teaching that I have found. Either remotely using Zoom, or sitting side-by-side. Pair programming is the most effective way for developers to learn IMO. And when you do that - let them drive. Making mistakes and correcting them is the best way to not be afraid of error messages.

I agree with @gertkeno that error handling is abysmal in Godot. Debugging is ok, but still sometimes a pain. I’m so used to just being able to try/catch/throw, and the fact that I cannot do that basically means I return a lot of nulls up the chain just so I have something to track down. I’m personally a huge fan of unit testing, and love GDUnit, but I’ve found it overkill for most things I work on.

The biggest patterns I see in the questions on the forums here is people scripting instead of programming. They grab a bit of this and that, and don’t actually have a foundation in how to problem solve by turning a problem into a coded solution. I think the best way to combat this is to recommend a Godot programming book. The ones I’ve read take the traditional approaches of having you create errors and fix them, as well as write code and refactor it.

I started writing an online course last year, and it was taking me a full week at 40+ hours a week to write one lesson. But it was intended to teach people with no programming experience how to program using Godot - with the added goal of making them professional developers at the end of the program. I ended up just shelving it after 7 lessons because I didn’t see it as financially viable. So I might as well see if would be useful to anyone. If you follow the link below and sign up for the Founder’s Package with the code FREEFOUNDER it’ll be free forever for anyone who wants to try it (like your students/friends.) The code is good for a week until the 19th at midnight.

It covers a lot of stuff, including how to use Git and GitHub, how to write Unit tests, how to import and animate 3D models, use sound effects, grid maps, animation players, etc. It also has a lot of additional information, history about programming, why we do things, teaching OOP concepts, and game design.

I’d be curious if anyone finds it useful and/or has any ideas what I could do with it.

3 Likes
7

Well damn, you started what I was going to do, I guess I can focus on other stuff, hahah, jk but that is great that I am not a lone with what I was saying.

Peace!

8

Take a look. Maybe there’s a way to work together on it. Right now it’s not something I am focusing on.

1 Like
9

Wow, that is GREAT!

Yeah, lets keep in touch, you can find me anytime. I would like to enter the “Application” dev with Godot arena as well, teaching how to write professional UI components etc, I am really blown away at your work, great job.

That is literally what I was aiming for.

The nod to “Agile” and unit tests… :wink:

2 Likes
10

Thanks. I’ve done the timekeeping app. A number of people use it, but I haven’t gotten any feedback about it. I got to the point of getting signed up in the Apple, Google and Windows developer programs and then just kinda lost steam as it’s expensive to get certs for a program I intend to make for free.

That’s what happened with the lessons too. I wanted to move away from what I’m doing and try to make money doing something I enjoy more. But the amount of work it would take to keep those lessons going just doesn’t seem worth it.

1 Like
11

I’d love to give it a shot (and maybe introduce a young family member to healthy dev habits) but it seems you cannot apply to Founder pack anymore

12

Let me take a look.

13

I just set the first 6 (finished) lessons as Public Preview. You can now click Preview Course and try them all out. No need to subscribe at all.

3 Likes
14

Again, nice work here, didn’t even know gdunit4 was a thing. :smile:

This is def stuff people can learn from.

1 Like
15

Thanks a lot ! :pray:

1 Like
16

Thanks. There’s another Unit testing framework for Godot as well. I just happen to like GDUnit4 more. There’s also three logging libraries, which I never got around to introducing.

I’ve spent a career helping organizations and individuals learn new skills, especially around Software Development, Agile and Testing. I realized after a while of doing this though, that right now it’s not a way to financially support myself. I do like teaching though - and I prefer written lessons to video lessons because I find it faster and easier to navigate when I am learning.

Thanks for trying it out! I’m glad it’s useful for someone. Keep in mind the 6 lessons I made free are the only ones done. (Though 7 is mostly done I never published it.)

1 Like
17

When I was new to programming, errors were intimidating and frustrating. It took seeing quite a lot to learn that they are (a) useful, (b) specific, (c) once you’re familiar with them, you can instant-solve 80% of problems. I think the hurdle is getting familiar enough with some of the lingo (index, null) so you develop an intuition.

Ah yes, I did just probably create an index situation.

Rather than

Oh god, what now.

So for teaching, I think you need to communicate that the above (a), (b), (c). There’s some necessary pain, which you’ll overcome so long as you don’t ignore them.

1 Like
18

A comparatively new issue we are facing in CS education is that students no longer even read error messages or the hints the IDE is shouting at them.
Often they ignore them and continue writing code while everything is already ‘red’ or just copy & paste back and forth between IDE and LLM until it somehow works, mostly, kind of, don’t know & don’t care.

So the tip I always give them is the one they don’t want to hear: one gets better at solving problems, by actually solving problems oneself, starting with smaller ones and then branching out, and not by operating as a mindless human clipboard.
It might sound boring, but taking an empty sheet of paper and just writing down what steps are necessary to solve a problem - not the code, just a ‘recipe’ - can be a good first step. Once that works, we only have to translate it to the syntax of a programming language.

It is hard to grasp for experienced developers, because we already have in our mind the code we want to write and then getting it auto-completed and quickly checking for correctness can be a time safer. But a beginner doesn’t know what to write or how to structure it and more often than not they will not think through the suggested solution but simply accept it and move on. I suggest to my students to turn off all their little helpers at least in the week before the exam to realize in which situations they still get stuck.
These modern issues aside: training, training and more training, best with a fun pet project.

5 Likes
19

You can tell those students that as a hiring manager, when I see people like that (and yes, I can tell in an interview) I consider them assembly line coders. They exist and have careers, but they basically get handed what to do and do it. People like that are now becoming fact-checkers for AI. There’s nothing wrong with that if that’s what they want to do. But neither job is that interesting IMO. You just clock in and clock out and get your paycheck. There’s no initiative needed or wanted.

3 Likes
20

If they are even capable of fact-checking… Getting handed something for free is very tempting and we should all make sure to avoid the ‘AI will make XZY obsolete within 6 months’ spins which are not only baseless hype but also detrimental for juniors.

In any case, I always tell them that to get a good, fun/challenging job they have to be better than all those tools, so in reality it is now tougher for them than it was back then when I started my career.

1 Like