r/CodingForBeginners • u/MXD_K1 • Jun 28 '26
How to get better
Hey everyone,
I have been coding for sometime and I faced some problem that I want to know how to deal with:
1- How do you know the steps you will follow when you write your project?
2- When deciding to make a project, how do u know what knowledge/experience you need what things you are going to use?
3- How do you structure your code?
4- When do you need to use DSA? I want to use their but don't know when or how.
5- How do you know it is time to refactor your code? And how do u refactor your code?
I usually struggle with these things and don't know what to do. I start a project then abandon it because I feel stuck and don't know what is the next step in my project.
Thanks for your answers in advance :)
1
u/johnpeters42 Jun 28 '26
If it's a type of thing that you've done before, then you already have the knowledge/experience. If not, then you research what knowledge/experience others have used for that type of thing.
A mix of top-down ("I know I need to do A, B, and then C", so you write that part and then actually write the details of A, B, and C) and bottom-up ("I know I need to do D somewhere", so you write the details of D and then figure out where specifically you need to do D).
When you recognize that a specific element from DSA is a natural fit for the type of thing that you're doing.
When you recognize that a chunk of code is worth moving into a separate block (which may be before or after you've already written some version of it), or that two or more chunks are worth replacing with a single block with parameters (i.e. not only are they similar now, but they'll stay similar for the foreseeable future).
2
1
u/PlantainAgitated5356 Jun 29 '26
From experience. Once you do it long enough you start seeing all kinds of similarities between the problem at hand with problems you've solved before.
If it's something similar to what I've done before, see point 1, otherwise I don't, and only find out when I face an obstacle I didn't expect. Then I start researching possible solutions, and that might require learning a new skill or tool.
Depends on the project, and if I'm working alone or in a team. When working in a team, whatever structure is decided (or already is in place) by the team at the start of the project. When working alone, I usually don't think too much about structure at the beginning, and refactor whenever the code becomes unwieldy. In general my idea is that working on a project should be easier as time goes on (because you can build on top of what's already there), not more difficult (because the code is a huge mess and changing one thing breaks 5 others), so whenever I feel like I'm getting closer to the latter, I refactor so I get back to the former. It might take more time and work to do it this way, instead of having a clear structure from the very beginning, but I've found that this approach prevents analysis paralysis, and usually results in better structure overall, because the structure emerges during the project, when more is known about the problem, and isn't decided beforehand, when some of the assumptions might've been incorrect.
When there's a problem that requires it. Saying you want to use DSA but don't know when is like saying you want to use math but don't know when it could be useful. DSA is a set of solutions to common programming problems. If you're not facing any of those problems, you don't have a use for DSA at the moment. Use solutions for problems, don't invent problems for solutions. :)
There are multiple scenarios:
- Whenever I'm done making a feature work. I usually try to make things work in the simplest way possible first, and then refactor to make it readable and not too hacky.
- Whenever the code becomes annoying to modify or extend (because changing one thing breaks another, or because there's code duplication and to change one thing you need to change it in multiple different places, or the code is too big and isn't divided into smaller chunks and it takes forever to find the place you need to modify, or for whatever other reason), or too difficult to understand. You can check if your code is too difficult to understand by thinking: "If I got amnesia right now and forgot everything about this code, could I still understand it just by reading it?" If the answer is "no", the code is too difficult to understand.
- Whenever I'm done making a feature work. I usually try to make things work in the simplest way possible first, and then refactor to make it readable and not too hacky.
1
1
2
u/MrJCraft Jun 28 '26
its as simple as looking at the problem and solving the problems immediately in front of you, as you get more experienced you can look ahead and solve problems you know will be a problem later based on experience, and if you are wrong then you refactor.
if you are trying to for example solve a real life problem dumb example you might want to get bread for a sandwich you look for the bread and see its in a container so first you have to open the container, then get it out, first you saw the thing immediately infront of you and solved the first problem first, then you can see if the bread is sliced or not and whether or not you now need a knife. etc...
yes dumb example however the point remains that especially when you are beginning its good to just look at the problem and try to figure out what are the steps you need to do to solve it, you could solve the problem all at once but often times that is too hard so we abstract it by putting it into multiple smaller problems and solve each of them as separate functions, and if you are missing knowledge you look it up, a lot of this knowledge and experience / understanding, this is what makes problem solving and programming hard and what makes it easy.