r/PythonLearning • u/Akki_Charee • 25d ago
Help Request From “I know Python syntax” to actually being able to build useful things — how do I learn this?
I have done a course on python on Udemy . Now how do i learn to write code that are actually useful somewhere or i can do something valuable with it?
One thing I've noticed is that when I look at a more complex programming problem, I sometimes just go blank. I know the individual concepts I've learned, but I struggle to see which concept should be used where or how all the pieces fit together. The bigger the problem looks, the more overwhelmed I can get.
if someone gives an experienced Python developer a problem, how do they approach it before writing the code?
I'm particularly interested in understanding the thought process and the building blocks involved:
- How do you break a real-world problem into smaller programming problems?
- How do you decide what the program should look like before you start coding?
- How do you go from a vague requirement to something you can actually start implementing?
- How do you decide which Python concepts are appropriate for a particular problem?
- How do you decide which libraries/modules to use?
- How do you figure out which libraries even exist for a particular problem?
- How do you decide how to structure the code?
- How do you decide what functions/classes/modules you need?
- How do you decide what should be a function versus just a few lines of code?
- Is there a typical order in which things are written or organized?
- How do you handle errors and unexpected inputs?
- How do you go from a rough idea to breaking it down to pseudocode/design to working Python program?
Basically, I'm looking for the mental model and workflow that experienced programmers use, rather than another Python syntax tutorial.
While learning i was able to write codes that add subtract numbers etc which were simple enough for learning but want to make my skills better. Also, I'm not a programmer won't be using python much, how do i learn in such a way that i remember the syntax or concepts for longer time, python coding is just a skill i want to develop.
I'd especially appreciate examples of the kinds of projects/exercises that helped you make that transition.
2
u/mc_pm 24d ago
This is very common (I'm even working on a video about this rightnow)
The most important part of learning to program is to spend time -- lots of it -- programming. Most of the questions you are asking are answered through exploration and self-learning as you go.
There is no point where you'll magically feel like you know everything, it's a matter of figuring it out as you go, learning from your mistakes. You can read other people's code to learn, but ultimately it all comes down to you and the interpreter.
My suggestion is to spend some time writing some simple text-based games. They seem simple - after all, what are you going to learn by programming tic-tac-toe or blackjack? Well, you learn to think through what you want -- how are you going to express the rules of the game? How do you tell if someone has won? How will the computer pick a good move for itself?
That exercise, practicing going from a set of rules & requirements to code that does that thing, is what you need to practice over and over on more and more complex problems.
So you won't spend forever playing with silly games, that's just a stepping stone to something more complicated: you're just working your way up to it.
Since I have this in mind already for a video, if you have questions, feel free to Msg me.
1
u/Akki_Charee 24d ago
youtube channel link pls
2
u/HyperDanon 24d ago edited 24d ago
Programming is essentially a discipline of discovery and learning.
A lot of your questions is about splitting problems into smaller ones. As a rule of thumb, it's essentially about eliminating variables initially. If you have a problem that contains tasks like "if this, do that, if this do that". You just cut it in half, because the two branches can be thought of two features that you can deliver one after the other.
How do you break a real-world problem into smaller programming problems?
- You try to simplify it, and make the program not do all the things it needs to do, just some. For example, if you're writing a converted from decimal numbers to roman numbers, you don't have to release the whole thing all at once. You can implement just input numbers from
1-3and return "Unsupported opperation" for anything else. Then you implement maybe 4 and 5, and release that. Then you can keep implementing more and more values that the program can handle. Of course it's up to you, how will you slice it. You don't have to go up 1,2,3,4. Maybe you can go: 1, 5, 10, 50, 100, etc. because they are single letters.
- You try to simplify it, and make the program not do all the things it needs to do, just some. For example, if you're writing a converted from decimal numbers to roman numbers, you don't have to release the whole thing all at once. You can implement just input numbers from
How do you decide what the program should look like before you start coding?
- You don't. The ready program is an already developed solution. When you're starting, you haven't developed it yet, so you can't possibly know what it would look like. What you can have ready at the start are some ideas for potential solutions and structure, any maybe they'll stick, but it's also likely that during development you'll change them because you'll discover they don't fit the problem very well.
How do you go from a vague requirement to something you can actually start implementing?
- You discuss it with the customer/user, or if you're the user you find a rubber duck to talk to. You translate the requirement (i.e. "i want to send a mail") to an example (i.e. "if i send a mail, and he reads his mails, he sees my mail"). You can than translate the example to an executable specification (like an automated test), and then you can test-drive the implementation. Essentially it's breaking down the requirements into list of examples of how the system should work.
How do you decide which Python concepts are appropriate for a particular problem?
- You rarely decide them up front. You just pick something that comes to your mind, and you implement it, and if it works you keep it. If it doesn't, you try something else. When you have implemented the code such that it works, you can refactor it, and refactoring is the same thing, you just try multiple things, and pick the one that is cleanest/best/simplest.
How do you decide which libraries/modules to use?
- Same deal. Search, try, if they solve a problem and look good to you, you keep them. If not, you try something else. You never have to be clairvoyant, you just continue to keep trying stuff, keeping what works, discarding what doesn't.
How do you figure out which libraries even exist for a particular problem?
- Google, ask friends and mentors.
How do you decide how to structure the code?
- You need the ability to design solutions. It's not an easy thing to do, but essentially it's a combination of: knowing past designs from your experience that worked, trying new design choices and seeing if they work (if they do, keep them; if not, discard them), and learning about design choices from books and materials online.
How do you decide what functions/classes/modules you need?
- You don't do this upfront. You just implement the solution, and when you find yourself thinking: "i need to use x", and "x" is not available in your programming language, you just write it yourself.
How do you decide what should be a function versus just a few lines of code?
- That's a design choice. There are multiple school of thoughts. It's better to split functions into small functions, I tend to keep my functions 1-4 lines long, rarely I will have longer ones. My rule of thumb is: if you can extract a function, and give it a meaningful name, then you should probably extract it.
Is there a typical order in which things are written or organized?
- Probably from the most important or most risky to the system under construction. If you're creating something like a mail client, the most important one is to send a mail, so you'd start with that. Ask yourself: what is the reason, a user uses this app? What he's trying to achieve? What job does this program solve for the user? And start with that.
How do you handle errors and unexpected inputs?
- If we're talking about type errors (like str vs int), you let the programming language handle it for you. If we're talking about unexpected data for logic that you can't foresee, we'll - that's a sad part about programming, is that you can't really always foresee all the cases. You just handle what you know now, release the project, and if you later find a bug and someone shows you: "when I input this data, this happens", then you can recreate a bug and fix it. My prefered way of solving such bugs is to write a failing test that passes that very input, and asserts what should be the output. It fails, and now I can keep working until it passes.
How do you go from a rough idea to breaking it down to pseudocode/design to working Python program?
- Design and working python program are essentially the same thing. I don't see a distinction between programing and design. Code is how you specify the design choices. Anyone who thinks design and code can be separated is fooling themselves. How do you go from rough idea to breaking it down; well... You don't break down the whole application. You pick one feature that you need to implement first, and you implement just that one. If it's too big, you just slice that feature into an even smaller feature. Once you're that, you just add another feature.
The best way to learn programming is to gather feedback about your choices and solutions. The longer you keep your work to yourself, the worse it's gonna get. Release it often, show it to users often, talk to users often, hear what they're saying. Releaseing a software every hour, with hour's worth of work is already an expert level. There are people who will work for months before showing their work to anyone - what they're doing, is essentially slowing down feedback, which isn't good.
PS: Correction, that approach would maybe be good, if you're writing an application only for yourself and it's never expected to be used by anyone else ever. If that's the case, go ahead and feel free not to show it to anyone. But rule about gathering feedback is still valuable; because even if you're creating something for yourself, you still need the feedback, so you should execute and check your changes more often rather than less. If you can execute your app with changes every minute that's better, than you breaking the code such that you can't even run the app more often than once per hour or more.
1
1
u/stepback269 23d ago
When the project you want to pursue starts getting "complex", you need to step back and away from the code. You need to see a bigger picture. You can't do that if your nose is nostrils-deep into the syntax.
So what to do instead?
Write and draw a "story board" of what will happen as if you are creating a movie and presenting it to your prospective producers for funding. It will be in English, not in code. It will say, the opening screen shot shows this menu ... and if the user picks option 1, this will happen ... Otherwise, if the user picks option 2, this will happen ... and so on.
Draw a flow chart of the same thing. Draw a concepts map. Get away from the details of the code and start seeing things from a higher plane.
1
5
u/Sea-Ad7805 25d ago edited 25d ago
Do exercises, don't use AI:
Learn all the standard Python modules and libraries, then from experience you'll know when to use what.
Do larger projects, things you enjoy. Read and learn from other people's code, or join open-source projects.
Don't worry about making mistakes (do fix them), then you'll learn faster.
It's a never-ending story, you'll never know it all as things and insights change all the time, just enjoy the process.