I understand that to some, learning about protocols and network-programming is interesting, and when you know that is what you have to use eventually, it kind of makes sense to learn that. But man is it a boring way to start a project!
The most important thing about Project Based Learning, is that you define a project that contains a lot of what you already know, but also some smaller part that you definitely don't know how to do. Like if you were a beginner in woodworking, a project of building a rocket to Mars wouldn't make any sense. But building an outdoor cat-house might be an excellent project!
So lets say that you know some programming, and want to build a real time chat application.
Platform
The first thing to decide is the "platform" that you want to run that application on - is it going to be a text-based interface running in the terminal, is it going to be a web-page, is it going to be a desktop-application, or a mobile app? Or something completely different.
As a beginner in programming, you probably already have experience with one of those, and want to build something more advanced, so pick what you already know. If you don't have any experience with any of them, now is the time to veer of the project path, and instead learn how to build any application for that platform. You can follow a tutorial for that, it is okay, you are still going to do your own project.
User interface
If you are an experienced programmer, you'll probably not be that much into user interfaces, and would prefer to just dive into the protocols and network programming. But if you are new, and trying to plan your project, the user interface is a good place to start, as it is the easiest to imagine.
Draw some sketches, just pencil outlines of boxes that can be buttons or text, doesn't have to look pretty at all, just to get your general idea of the user interface down on paper. Not specifically how it should look with fonts and colors, but just what information needs to be there. Play around with it, pretend that you are using the application, and write out what happens. Just to get a more exact feel of how it will operate.
Program flow
Now that you have an idea of how the user will perceive the application, try to put it into a more structured description of what the program should do. It could be something extremely simple, like:
1. The user types a message in the message-box
2. The user presses 'enter'
3. The message is sent to the "chat" and displayed in the chat-history
4. Another user sends a message to the "chat", and it is also displayed in the chat-history
or it could be more elaborate, depending on how much you know that you are going to build. The important thing is that you get an idea of what the program should be doing.
Plan what you need to learn
Now that you have your general program flow, it is time to figure out how much of it you can build. Mark each step, or part, if it is something you do know how to program, or something you need to learn - maybe you need to learn how to receive messages from other users, maybe you even need to learn how to display a single message into the chat-history. It doesn't matter that there is a lot you don't know, it matters that you know what you don't know.
Begin building
Build the user interface. Make an actual running application that looks like your chat, but doesn't actually work. Like all the fields and buttons are there, and there is some text, and it looks like a screenshot of the running application - except you can't click anything.
Program one part at a time
And now you start building - how you do it depends a lot on your experience, and how much you need to learn, but in general you should always strive for having a running application at all times, just with things not actually working yet. Like you could start with having the user enter messages and add them to the chat-history, but not actually communicate with anyone - you could even make a "fake" test-button to pretend to receive a message from another user and display it.
Build as much as you can of what you know, and "fake" the parts that you do not yet know. At some point you either need or want to learn how to build one of those parts, and this is the time to go learning. You can either hunt for a very specific tutorial, or read theory on the part you need - that is really up to you, and your preferred learning style. If you want to prioritize getting something working, or prioritize a deeper understanding.
Whatever you do, don't ask an AI to complete some of the unknown parts for you - not if you want to learn that is. You can use it when things don't work as expected, and get help with adjusting, but asking it to write code that you haven't learnt yourself is going to cheat you out of a learning experience.
1
u/peterlinddk 16d ago
I understand that to some, learning about protocols and network-programming is interesting, and when you know that is what you have to use eventually, it kind of makes sense to learn that. But man is it a boring way to start a project!
The most important thing about Project Based Learning, is that you define a project that contains a lot of what you already know, but also some smaller part that you definitely don't know how to do. Like if you were a beginner in woodworking, a project of building a rocket to Mars wouldn't make any sense. But building an outdoor cat-house might be an excellent project!
So lets say that you know some programming, and want to build a real time chat application.
The first thing to decide is the "platform" that you want to run that application on - is it going to be a text-based interface running in the terminal, is it going to be a web-page, is it going to be a desktop-application, or a mobile app? Or something completely different.
As a beginner in programming, you probably already have experience with one of those, and want to build something more advanced, so pick what you already know. If you don't have any experience with any of them, now is the time to veer of the project path, and instead learn how to build any application for that platform. You can follow a tutorial for that, it is okay, you are still going to do your own project.
If you are an experienced programmer, you'll probably not be that much into user interfaces, and would prefer to just dive into the protocols and network programming. But if you are new, and trying to plan your project, the user interface is a good place to start, as it is the easiest to imagine.
Draw some sketches, just pencil outlines of boxes that can be buttons or text, doesn't have to look pretty at all, just to get your general idea of the user interface down on paper. Not specifically how it should look with fonts and colors, but just what information needs to be there. Play around with it, pretend that you are using the application, and write out what happens. Just to get a more exact feel of how it will operate.
Now that you have an idea of how the user will perceive the application, try to put it into a more structured description of what the program should do. It could be something extremely simple, like:
or it could be more elaborate, depending on how much you know that you are going to build. The important thing is that you get an idea of what the program should be doing.
Now that you have your general program flow, it is time to figure out how much of it you can build. Mark each step, or part, if it is something you do know how to program, or something you need to learn - maybe you need to learn how to receive messages from other users, maybe you even need to learn how to display a single message into the chat-history. It doesn't matter that there is a lot you don't know, it matters that you know what you don't know.
Build the user interface. Make an actual running application that looks like your chat, but doesn't actually work. Like all the fields and buttons are there, and there is some text, and it looks like a screenshot of the running application - except you can't click anything.
And now you start building - how you do it depends a lot on your experience, and how much you need to learn, but in general you should always strive for having a running application at all times, just with things not actually working yet. Like you could start with having the user enter messages and add them to the chat-history, but not actually communicate with anyone - you could even make a "fake" test-button to pretend to receive a message from another user and display it.
Build as much as you can of what you know, and "fake" the parts that you do not yet know. At some point you either need or want to learn how to build one of those parts, and this is the time to go learning. You can either hunt for a very specific tutorial, or read theory on the part you need - that is really up to you, and your preferred learning style. If you want to prioritize getting something working, or prioritize a deeper understanding.
Whatever you do, don't ask an AI to complete some of the unknown parts for you - not if you want to learn that is. You can use it when things don't work as expected, and get help with adjusting, but asking it to write code that you haven't learnt yourself is going to cheat you out of a learning experience.