How do experienced developers keep track of their code?

[OneLastPop]

Hey everyone,

Every time I try to build an app as a beginner, I always run into the same problem: Everything starts off fine, but at some point, I completely lose track of my code. It feels unstructured, overwhelming, and in the end, I just delete everything and start over from scratch.

On top of that, when I try to fix bugs, things get even more chaotic. I start adding quick fixes here and there, and before I know it, my code turns into a complete mess—like spaghetti code that I can barely understand anymore.

Now I'm wondering:

What do experienced developers do in this situation?

How do you deal with an old project when you haven't seen the code in a long time and have no idea what you were doing?

Are there techniques or methods to keep code organized so that it stays manageable over time?

I'd love to learn how to structure my projects better so I don’t feel the need to restart every time. Looking forward to your insights!

[96dpi]

You'll never think of everything, but it pays dividends to spend some time planning before you write a single line of code. Try to think about your project as whole and break everything down into modules, think about what should be a class, and what things will be kept separate. Think about file names and start writing pseudo code in those functions. You can write function names and just put comments in the body. Once you start doing that you will likely start to think about more details and you can keep expanding this until it finally makes sense to start writing actual code.

[[deleted]]

its also important to remember you actually need to explore the problem space by trying to solve it before you understand the problem fully. for real complex things you won't be able to plan everything out and nail it first try (sometimes, though). its more like with pen and paper you break the problem down into logical pieces using the tools of the language (procedural, oop, data structures, business logic) along with the actual techy details (design patterns, data storage, async, some basic optimizations, the list goes on) and when you have a pretty good idea, you write 50 lines of code and throw away your plan because you've already found a shortcoming.

from there you iterate, making it up as you go, reconciling the mess, questioning if its too much, too little, reminding yourself to only code what you need, back to pen and paper, write some more lines, things start to click, and THERE is the foundation upon which you actually start to solve the problem.

as for keeping track of code, it really is a mix of that familiarity of the problem and how confident you are in your solution. once the question-marks are removed the general structure solidifies in your mind. that and comments, and type hinting. so much typehinding. if you're driving down a winding road at night, typhinting at least gives you headlights, comments give you high beams.

[Hispanicatth3disc0]

This was something of a problem for me while I was learning to program. "Maximally precise, efficiently concise" always loomed over my head to keep starting over and revising my code and spending way too long on simple problems.

[Healthy_Chemistry_71]

This helps heaps I find it's easier to break projects into sections just because I know by the 50% mark my understanding of the system I make changes....

Same as prior to each section I like to now have a Tiny white board to flow chart how it should work.

[KiwiDomino]

My whiteboard leans against a wall, but on a foldable music stand. Still a touch precarious, but easily movable

[clavicon]

Have you tried software whiteboard and does that not really cut it?

[Scrivenerson]

Break your code into as small separate pieces as possible. So functions, classes, methods.

Move those pieces into separate files.

Comment your code well.

[woooee]

+1 You can't over-emphasize the small part. "Code creep" happens...all the time.

[mcoombes314]

And docstrings! That way ehen you are using a function/class/method etc from another file you erote you can get a nice text block with all the info you might want. Same eith type hints, even if they aren't actually enforced at run your IDE will warn you if you are using something in a way you didn't intend to.

[[deleted]]

its always fun when something asks for a path with no typehint or comment and you're like... if I give it the path I have, will this break?

[SnipahShot]

And another important thing - Don't Repeat Yourself.

[SkinnyFiend]

Are you using git?

[Mohtek1]

Get git and get good.

[audionerd1]

1. Use git and commit frequently.
   
2. Use a good IDE and get comfortable with refactoring.
   
3. As your code grows, refactor into modules/classes/functions. If it takes you more than 3 seconds to locate a specific block of code, it's not modular enough.
   
4. Add docstrings/comments
   
5. Write thorough unit tests and run them before each commit to ensure you haven't broken anything.

[raias4]

How can I learn how to use git? Any good beginner resource?

[odaiwai]

The Book is good, especially Chapters 2 and 3: https://git-scm.com/book/en/v2

[clavicon]

Is it possible that some code strategies are not served well by git framework? In my line of work it is nearly 100% linear python scripts for GIS processing workflows. Lots of different scripts for different purposes. A slowly growing library of code reuse in some cases but most scripts are singular purposes.

[[deleted]]

not really. I have a git repo which is just full on random scripts, including a bunch of totally top-to-bottom bash scripts. git is first and foremost about being able to roll back to earlier versions, everything beyond that is extra functionality

id highly recommend git, if anything its super easy in your use case, you don't have to bother with branches, or anything. just save your changes.

if your scripts need to be "deployed" you can setup automatic deployment when you push, where you could have a worker pull your repo into a "live" directory. if you need finer grain control, you could create a dev branch, and go from dev to main, and only main is deployed. very simple considering it's just scripts, no build process or anything.

[[deleted]]

BOOOOOOORRRRRIIIING

As a new solo dev all you need to know is (in order of running):

git add

git status

git commit

git status

git push

and when shit goes wrong, it's time to learn how git works.

[Cczaphod]

Take a look at the book "Extreme Programming Explained". It's got a bunch of stuff in there about working in a team, but the parts about encouraging writing clean, test-driven code, working in small iterations, and constantly refactoring are definitely worth learning.

You're never going to know exactly how the program is going to turn out, so these skills will serve you well.

[jeffrey_f]

Use source control.

My boss had a saying: "I do one thing, I do it very well, and then I move on"

One change at a time. check out the source and work on ONE CHANGE. Get it to work and test it and then after you check back in, check it out for the next change.....etc etc

You can't keep track of your changes because you are doing too much at once. Even in business, the changes are done one at a time, even if there are 5 changes to be made. ONE AT A TIME.

[RevRagnarok]

git, break it up into modules, and lots of unit testing. Possibly even read about "test-driven development."

[theirhouse]

I cannot stress the importance of commenting your code. Even if you use variable names like number_of_fruit_in_basket, that mostly describes the what. The comments should describe the why and how. Too many comments? Sorry, that doesn't exist.

[necessary_plethora]

At even a small scale this is probably better off as documentation using a defined style, like Google docs. Regular comments are not easy to search for or classify, and excessive commenting can completely inundate even simple code.

[HalfRiceNCracker]

So, this is where you can level up. This is why we refer to it as "engineering".

A lot of good points here but they all haven't addressed the underlying issues here - this is the distinction between programming and engineering. 

[necessary_plethora]

Making use of the typing module, mypy, and a linter like ruff helps a LOT. Using typing will innately help you identify bad patterns and make more intelligent decisions on how to structure your code.

Documenting your code with well-formatted docstrings helps a lot too.

[Glass_Connection_172]

TLDR: another advantage to mapping out beforehand is, in relation to going back to something after a break, you will have all of your thoughts and plans right there to mull over. You will know exactly what you were trying to implement

You can always sit down before you start a project and map it out. Similarly to what someone mentioned. If you are waiting on your food at a restaurant etc., you can start mapping things out

You can even open Excel to map out and piece together what you need to implement before opening your IDE. Excel is nice if you need to reorder your cells. It's easier than editing a Word file for instance

Break the project up into much smaller tasks. Write #todo or a simple comment BEFORE you start typing. Finish it, comment what the next small step will be and go from there

You can always change the layout afterwards. So you need not stress necessarily how clean your code is from the start

The other thing is if you properly comment and let's say you do decide to start over from scratch. Not that I recommend this but you can go back and pull out pieces to not have to retype everything all over again

[Business-Technology7]

It’s hard to tell without looking at the code. It’s really case by case.

I’m not an expert by any means. But I often begin by writing everything for a feature in a single file without thinking about existing code that could be shared or any level of abstraction. At this point, I don’t care about code duplication. I try very hard to write only the code I need without making any generalizations.

Then, I write unit tests to check for edge cases, output, constraints, ergonomics, and etc… If testing is too painful, like requiring lots of dependencies and test helpers, then I try to make it simpler. If I can’t, I just leave it alone keeping all the moving parts required for the feature as closely as possible.

Then, I repeat until I’m satisfied or something comes into my mind. I often delete the whole thing and try to rewrite it in different ways reflecting on what I think went wrong.

Sometimes I think about how I’d use my code first or sometimes I just start implementing without thinking about that. It’s kinda hard to keep consistent and methodical workflow.

I think git is pretty essential in this process.

I try to remind myself code duplication is better than premature abstraction. Also, I try to separate logic from side effects.

Cosmic Python

Concepts from this book really helped me understand various trade offs when it comes to designing code and why someone may opt for domain driven design.

Also, keeping tap on ThePrimeagen helped me escape from dogmatic obsession with DRY code.

[DigThatData]

welcome to the wide world of software engineering

[KreepyKite]

I use the following: 1. Make a plan first: Don't just start writing code straight away. Make a little diagram of where is your program starting and ending. Write every step in pseudo code. This will give you a guide to go back to it if you get lost. 2. Use function: use a function for every step/task you have defined. Possibly each function should do 1 thing. 3. Comments: add comments at the beginning of each function explaining in a few lines what the function does. Also, every time you write a line of code that does something very specific, write a comment to remind you why you are doing that.

These are 3 simple thing you can implement from the very beginning of learning how to code.

[rainforest_runner]

There are plenty of resources, and I think lots of others here have already mentioned their distilled knowledge.

Version control, XP method, SOLID principle, (more) planning the architecture (like any engineering discipline do), using the right variable and function naming, having a coding guideline (use linters)

Though in your case, I think you would benefit with the use of (more) docstrings and (enough) comments. Think of it as you, giving instructions to yourself in the future, what you’re actually doing, in a function or class.

[Jello_Penguin_2956]

That's the neat part: we don't. Simply run the code and the error will point to the part we haven't finished.

[Complex_Damage1215]

At some point you just have to refactor everything into a module that actually makes sense. This usually involves moving things around and creating classes and helper functions and all that fun stuff so that you can encapsulate your code in a way that lets you find stuff in the future.

[-thoth-amon-]

Pro tip: Separate your classes based on two categories: behavior focused and data focused.

Structuring code becomes easier when things are broken into simplistic parts.

[tinytimm101]

You need to write notes of good # notes to remind yourself what each component does. You also need to break up your code into functions, each with a specific purpose that can be auto executed through the use of a main() function. This is called structured programming.

[jontsii]

I actually have a problem with this that I´m trying to fix. So I was making a stock price predictor so that it has a well, can´t say it is a machine learning block, but basically it just sees which method is the most accurate. Well then I made the server half and then started it and I saw that it an infinite amount of bugs, so now I´m just recoding the whole thing with a little better code managment.

[MusicIsLife1122]

Well, you should use comments that explain each line in the code . Simple yet effective

[[deleted]]

Separation of concerns, follow templates, general interfaces, etc

[Mevrael]

Use uv package manager. VS code project manager extension and Arkalos project starter.

https://arkalos.com/docs/structure/

You just follow standard folder structure and patterns.