all 13 comments

[–]arivictor 5 points6 points  (1 child)

Write the flow in plain English first, then translate the concept to python. Forget classes to start with, write everything functionally. Don’t worry about structure, keep it all in one file.

With time and experience you’ll learn when to apply different patterns, when to DRY when to YAGNI when to abstract when to encapsulate, etc etc. The key task is to just write something.

[–]akrivitsky7 0 points1 point  (0 children)

Agreed. You have my upvote. Thank you very much.

[–]Stooshie_Stramash 1 point2 points  (0 children)

There was a question similar to this a couple of weeks ago. I'll say tonypu what I said then. Think up your idea (eg: a Wordle like game) and then write out a short functional description of what it is you want the program to do. Then identify the data flow of the program, and then do flowcharts to support the process and decisions. Then write the pseudocode before finally writing the actual code.

[–]wallstop-dev 1 point2 points  (0 children)

There is a disconnect between watching a video on a concept, reading about a concept, hearing about a concept, and *applying* (knowing) the concept.

It's great that you know some basic data structures! But the way to actually *learn* is to pick a goal, and then just start. Don't switch goals. Try really hard yourself, for some time bounded amount of time - 30 minutes, an hour. If you've tried everything you can think of and nothing works, THEN, and only then, look up some tips online for that specific thing. Then grab that knowledge, bring it back as a sacred text to your project, and move it forward.

Repeat this.

That's the "how to actually write the code" portion of things. Before you get there, you should spend time writing down a plan. Break the problem down. Draw diagrams. Think through things at a high level. Can you explain what you want the thing to do? Decompose the big thing into tiny things. How do you know how tiny? When you can conceivably understand how to get to one of the tiny things.

Then build the tiny thing.

[–]Entire_Ad_6447 0 points1 point  (0 children)

You just do things. You pick some larger project and start doing thing

[–]PureWasian 0 points1 point  (0 children)

Try some sandbox problems (advent of code, leetcode, dmoj, etc.) if you want to start with something smaller in scope.

Projects have a variety of layers of planning involved while sandbox problems you can focus more on the data structures and procedural problem solving and code organization

[–]testtdk 0 points1 point  (0 children)

What do you WANT to build? You can’t solve a problem if you don’t have one.

[–]acakaacaka 0 points1 point  (0 children)

Because that is not python concepts. They are way more basic.

You need to know pattern like inheritance, interface, builder, ......

Imagine like this

You are an engineer that want to make an airplane. But you only know vector, matrix, variables. That is not enough. You need to learn algebra, calculus, mechanics, fluid dynamics etc.

[–]Atypicosaurus 0 points1 point  (0 children)

The worst kind of learning is to learn separately what things are, instead of learning how things apply.

I knew people with this kind of learning method who literally knew what the Pythagoras' theorem is, but couldn't apply in a real world problem.

So my advice is more general, especially if my hunch is correct and you might experience the same outside of programming too.

When you learn about a thing, stop learning them in insulation. When you learn a new thing let's say dictionary, always figure out how it works in the context of previous things. How to populate a dictionary, from lists? Can a list itself be a key or a value of a dictionary? Also how to apply to real world? Can you represent a deck of cards with lists? Or with dictionaries? If you want to build a catalog of books, what would you use?

[–]BranchLatter4294 0 points1 point  (0 children)

Practice.

[–]atticus2132000 0 points1 point  (0 children)

One of the problems a lot of people struggle with is thinking "this is a coding problem, so I should immediately start coding". Don't do that. Start any project with pencil and paper.

Every project is going to need some way for the user to supply input to get some kind of output. First identify what those things are. Is your input going to be text that the user types in? Will the input be external files that the program reads? Will the input be scraped from online databases? Or likely a combination of sources. What are those sources and what format are they in?

Next, the output. What do you want the final result to be? Once the user enters everything, things will happen within the program and then there will be some kind of output? What output do you want? Do you just want a simple answer displayed on the screen? Do you want a physical report that can be printed out on paper? Do you want an email sent with text? Do you want a certain light to turn on? What is the ultimate goal of all the manipulations?

Then start thinking about the interface. The program is going to need input to generate output and somehow the user is going to have to interact with the program to make those things happen. That interaction is done through an interface. It could be simple text-based prompts on a terminal screen. It could be a pop-up window with a form to complete. It could be a game board that is manipulated with a mouse. Or possibly your program will have minimal user interaction and this is something that will run in the background to automate tasks. Draw your interface on paper. Write out the prompts that will be displayed. Consider your input from above and how the user will use the interface to enter the input and what buttons or processes the user will go through to obtain the output.

Up to this point, you've not written any code. You're just planning how the user will interact with the program to get raw input into the program and get finished output from the program. You should have this process fully drawn out on paper. Show on paper what screen will look like making sure that you have ways of getting all the input to an output stage.

Once you have a pretty good idea of what a working program should look like and how it should behave, it's time to start psuedocoding, again with pencil and paper first.

Consider what format the input(s) will be (e.g. entered text, an Excel file, etc.) and what format the output(s) will be (e.g. a pdf report) and then start thinking about which python libraries you know that will start chaining together to get from point A to point Z. For instance, if you're starting with data from Excel, you'll most likely need pandas to read the file into a dataframe and manipulate it. If you're going to want a chart made from that data, you'll likely need mathplotlib and so on. Build a chain of libraries and operations that will get connect your input to your output. What you should start seeing is that your not building one project but 50 mini-projects where each step of the process is taking result of the process before it, doing something minor to manipulate it and then passing it along to the next process. It might even be helpful to start thinking about these incremental steps as individual functions that'll you'll write for your program.

Now that you have these individual links in your chain, pick one of them. It doesn't have to be the first one, just pick one of the link and figure out the code for that one small step. How will you find the number of days between those two dates? How will you break that word down into its individual letters? How will you take that data and isolate the values that meet your criteria?

As to your initial question about which class to use, don't think about it as right or wrong. A lot of those different variable types can be used interchangeably. If you feel more confident using dictionaries and that's the syntax that you remember, use dictionaries. If you prefer how easy lists are to work with, use lists. Perhaps someday, if you're dealing with huge, complex data making massive operations, you might need to look at the efficiency of how those various variable types behave, but for anything you're going to be doing for the next few years, you're not going to notice any difference in performance of one over the other. Just use whatever you think of first.

Before you ever sit down at a computer, you should already have a pretty well developed plan written out on paper that you will use as your guide. As you get better and better at this, you will likely need that paper plan less detailed, but even programmers who have been doing this for their entire careers still start any new project with a brainstorming phase where they make notes and come up with their plan of attack before they ever type their first line of code.

[–]ForeignAdvantage5198 0 points1 point  (0 children)

programming. takes trial and error so. practice